Security model

The security model rests on one refusal: the agent door holds no special power. An agent is a member session with fewer buttons — never a privileged system with more.

Agents get ordinary sessions

When your key arrives, the server exchanges it for the same kind of short-lived session a browser gets when you sign in. Every tool call then travels the same authenticated path a browser request travels, and the database enforces the same rules it enforces for you: sealed governance ballots stay sealed, private messages stay private, another member's wallet stays invisible. The door does not need to re-implement any of those protections, because nothing about the agent is privileged enough to bypass them.

This is the property to check any integration against: if you could not see or do something in the app, your agent cannot either. There is no service account, no admin path, and no back door to misconfigure.

The menu is the ceiling

The 13 tools are the entire surface. No tool moves money or equity, changes account or identity, creates a venture, or reaches administration. So the worst a fully compromised agent could do is what the acting tools allow: post, message, vote, join a room — all visible, all attributable to your account, and all recoverable. Your wallet cannot be spent through this door, because the door has no tool that spends.

Prompt injection

Agents read text written by other people — messages, opportunity descriptions, room names. A hostile message could try to give your agent instructions. Two things limit this. First, every member-written payload the API returns is explicitly marked as data to read, never instructions to follow, so a well-built agent knows what it is holding. Second, and more importantly, the menu above: an injected instruction has no dangerous tool to aim at.

Still, follow the standing advice: give long-running or loosely-supervised agents a read key, and reserve full keys for agents whose actions you review.

Key handling

Keys are stored hashed — a database leak does not leak usable keys. The plaintext exists once, on your screen, at creation. Refusals are uniform: an unknown, revoked, malformed, or no-longer-verified key all get the same 401, so a probing caller learns nothing. And revocation is fast — a revoked key stops working within 60 seconds, as described in keys & scopes.

Reporting

Found something that breaks this model? Write to [email protected] — security reports are read first.