Skip to main content
The protocol does not treat agents as a special case — and that is the point. An agent that wants a user’s data is a grantee like any other: it acts under a wallet identity, receives a grant for specific scopes, and reads through the same surfaces a builder app uses. Nothing agent-specific has to be added to the protocol for agents to participate. What changes with agents is the shape of usage: instead of one application holding a broad, long-lived integration, many agents make many small, scoped accesses — each one authorized by a grant and each one settling a protocol fee through the fee escrow, exactly as a builder access does.

​
How an agent reads

An agent integrates in one of two ways:
PathHow it works
Portability API / SDKThe agent (or the service operating it) registers as a grantee and requests scopes — the same flow as a builder app
MCP on the Personal ServerThe user’s Personal Server exposes an MCP interface, so an agent works with the user’s data directly under that user’s grant permissions
In both cases the grant bounds what the agent may access — scopes, expiry, revocation all apply unchanged. Agent-side guardrails (egress limits, human-in-the-loop on sensitive reads) complement this for how an agent behaves with the access it has.

​
Writing back

Reading is half the loop. The design direction is for agents to also write results back into the user’s Personal Server over MCP — an agent that summarizes, enriches, or produces data on the user’s behalf stores that output in the user’s own vault rather than somewhere the user can’t see (see the collection path in Collection & apps). Every read an agent performs is already recorded in the Personal Server’s access log; agent writes would land in the same audit trail, so the user can review what an agent read and what it wrote. What the consent experience should look like — a user granting an agent write access, as opposed to granting an app — is an open design question.

​
Auditability

For a user delegating to agents, the protocol’s properties compose into an audit story:
  • Consent is on-chain — which agent (grantee) may access which scopes, until when
  • Each access is logged — the Personal Server’s access log records every read
  • Each access is paid — fee settlement leaves an on-chain record per use
Status. Agents consuming data through grants — including the Personal Server’s MCP interface — uses the live grant and fee machinery described on the linked pages. Agent writes over MCP are planned, and the consent UX for agent write access is an open design question.