Security model

An agent uses your member permissions. A full key can take real actions in your name, so give it only to an agent you trust.

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 rule to check any integration against: if you could not see or do something in the app, your agent cannot either. The key exchange uses a server credential, but member-data calls run as the member. The agent door does not grant network administrator access.

The menu is the ceiling

A read key cannot call acting tools. A fullkey can use the current acting menu within your permissions. That menu includes public posts and messages, venture drafts and equity changes, votes, majlis actions, and some personal settings. A call through the agent door is the action; the website does not add a confirmation step to every call. Some results cannot be undone. Review the tool reference before issuing a full key, and use a read key when action is not needed.

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 marked as data to read, not instructions to follow. The door also screens member-written text it returns for planted instructions. These checks reduce risk; they do not make a full key safe to leave without oversight. An agent could still misuse an acting tool if it follows hostile text.

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.