Skip to main content
The protocol does not treat agents as a special case. 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 is authorized by a grant, and each chargeable access settles a protocol fee through the fee escrow, exactly as a builder access does.
The Personal Server’s MCP interface is read-only. To store a result in the user’s Personal Server, use the Write API.

​
How an agent reads

An agent integrates in one of two ways: 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

An app can write results back into the user’s Personal Server through the Write API, under a write: grant. Output an agent produces on the user’s behalf — a summary, an enrichment — is then stored in the user’s own Personal Server, where the user can see it (see the collection paths in Collection & apps). Writes are not available over MCP. Every read an agent performs is recorded in the Personal Server’s access log, and every record written through the Write API carries the writing app’s signature.

​
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 chargeable access is paid — fee settlement leaves an on-chain record per use