Your personal agent is the new walled garden

The answer is not a better platform. It is an agent that holds none of your keys. It acts as your delegate, under permissions you sign and can revoke one at a time. Your credentials prove facts without ever being shown. Every receipt is yours to carry away. We built this. Today an organization's own agent issues the credential, and a member proves it at a live door and pays her dues without the organization learning which member she is.

In September 2025 Coin Center published Tear Down this Walled Garden: American Values and Digital Identity. Its argument is simple and, I think, right: identity infrastructure that one intermediary controls — a platform, a bank consortium, a government agency — centralizes surveillance, limits what anyone else can build on it, and lets the gatekeeper privilege its own services. The alternative the report calls an Open Commons: credentials a person holds and carries, facts proved rather than documents shown, open standards that no one captures. The report ends with a line worth keeping: a state-run walled garden is no better than a private park.

A year later the walled gardens are being built, and they are not identity wallets. They are personal agents.

In the space of seven weeks this autumn, three of the largest companies on earth shipped a program that acts for you. Meta's Muse (September 8) books travel, fills forms and checks out purchases; it runs on what Meta calls a Muse Secure VM, a private machine that holds both the agent and your personal data. OpenAI's dots (DevDay, September 29) are always-on agents, each on its own cloud computer with its own browser, connected to four thousand apps, working after you log off. xAI and Cursor's Grok Bot, in beta since August, is reported to sign in to your mail and your CRM from a dedicated computer of its own and keep going while you are away. These are remarkable products. They are also, every one of them, a private park: the agent and your data and the record of what it did live on the platform's machine, under the platform's account, governed by the platform's trust in you.

This essay is about what identity, authority and privacy have to look like when the holder of a credential is a program rather than a person. That is not a premise about the future. Programs hold credentials today, everywhere: every API key, service-account file, bot token and long-lived session cookie is a credential held by software with nobody at the keyboard. What they hold is a secret, and whoever has the secret is the identity — it cannot say who authorized the act, cannot be narrowed to one task, cannot be revoked per call, and leaks as easily as it is copied. The personal-agent platforms do not introduce the program as holder; they put your whole life behind that kind of holder. So the question is not whether programs should hold credentials, but what a credential has to be when they do — and what we have built, in the open, so that a person's agent can act for her without becoming a new gatekeeper's property. I will respond to Coin Center's principles directly, because they are the best checklist anyone has written, and I will be honest about where we fail them today.

The holder is no longer a human with a phone

Everything in the digital-identity literature, Coin Center's report included, carries one quiet assumption: the holder of a credential is a person, holding a device, present at the moment of use. Prove you are over 21 — tap the phone. Prove you are a U.S. person — tap the phone. The zero-knowledge proof is generated by a key the person holds, and the privacy guarantees follow from that.

The personal-agent platforms break the assumption on day one. Muse pays for things while you are in a meeting. A dot files your expense report at 3 a.m. For an agent to present a credential on your behalf, something has to hold the key the credential is bound to, and there are only two obvious answers.

Give the agent the key. Now the agent is the holder, cryptographically. This is how every program holds a credential today — the API key in the environment, the service account's JSON file, the bot's token — and the personal agent inherits the pattern whole. Every principle in Coin Center's list is defeated by construction: whoever controls the agent's machine controls every credential it holds, can present any of them to anyone, forever, and the person can only revoke by asking the platform nicely. This is the walled-garden answer, and it is the one the platforms will take by default, because it is the one that works tonight.

Keep the key on the person's phone. Now the agent cannot act while she sleeps, which is the entire point of an agent. This is the answer the identity literature implicitly gives, and it is why that literature has nothing to say about agents.

There is a third answer, and it is the one piece of this design that no current standard has written down. We call it delegated presentation.

The credential is bound at issuance to a device key that is custodied for the person — a P-256 key held by the estate's key service inside a confidential machine, under her custody root. It is never the agent's key, never a secret the agent's runtime holds, and never a key on her account: it cannot sign a transaction or an operation for her, only a presentation. The person then signs one standing wire: a scoped, revocable delegation from her agent to her runtime that says, in effect, you may cause my device key to sign presentations — but only to these verifiers, only for these predicate programs, only under these issuer keys, and only for this long. When a verifier challenges her agent, the agent runs the proof and, inside the one callback where a signature is needed, a presentation release judges the wire against the exact statement being proved — audience, predicate program, issuer facet — and signs only if it holds. A wire for another venue signs nothing. The key service checks the same thing a second time: it signs only when the request carries evidence naming the digest, the venue and the predicate the release judged, so a runtime holding the service's credential cannot make a signature no wire covers. The proving system never sees the key; it sees a callback that may refuse.

What this buys is best stated as the differences:

It is the rule the whole substrate is built on — the key is a delegate, never the identity — applied to a credential's device key. Programs stay credential holders; what changes is that the program holds a delegation it can only exercise, never a secret it owns. And it is what we would contribute to Coin Center's proposed standards body, the John Hancock Project, if it existed tomorrow.

What we built, and what it looks like at a door

This is not a position paper. It is implemented, end to end, in the published packages and the product repositories that run on them, and a live gate holds it against a real door: a nameless visitor proves "over 18, and I am a member of your organization" at another estate's boundary, in zero knowledge, and is admitted. The membership is a claim in a credential the organization's own agent issued — an act of the organization, under a mandate its steward signed — proven the same way as the age, naming nobody: the door learns that the organization issued her a membership, and not which member. On that admission she pays her dues, from her own treasury, and the organization learns that a member paid.

The pieces, in the order a visit uses them:

• The issuer publishes a facet, not a trust relationship. An issuing agent — an organization or a service, never a person — signs a key facet and anchors it as an attestation on its own chain. A verifier anywhere resolves the facet by key id and re-verifies it through the chain: the signature answers under the issuer's account, the attestation is live. The issuer is never asked. That is Coin Center's "no phone home," made structural.
• The credential is proved about, not shown. We use OpenAC, the Ethereum Foundation's zkID work: predicates over a selectively disclosable credential, proven in zero knowledge, with the issuer's key and the holder's device key hidden inside the proof. A verifier learns that a predicate held. It learns no claim value, no credential, and no key.
• The verifier asks its own question. A door builds the proof request from its policy and its single-use challenge, never from anything the presenter sent. The predicate program is compiled to a canonical form and digested; that digest is what the person's wire names and what the receipt cites.
• The visitor is nameless, but not actor-less. The agent knocks as a pairwise account — one derived from the person's secret and the door's origin, different at every door, underivable without the secret. The door's admission rules still see a signed actor, which is what an audit needs; they never see the person.
• One visit per audience, by a window. Each presentation carries a nullifier, deterministic per device key and audience, which the door's own store consumes atomically. The same person cannot be admitted twice in the window; two doors cannot link her. The door's policy says how long the window is.
• Revocation lives on neutral ground. The issuer anchors the root of its live credential set on a registry no estate controls — the same registry our estates use for their authority projections. A holder presents a membership proof against the root the verifier reads from the chain; a credential the issuer has retired is simply absent from the next root, and every old status proof is stale. Nobody phones a status list.
• The receipt names the evidence and nothing else. The door's record of a predicate admission carries the facet, the predicate digest, the nullifier's grade, the status sequence it read, where the proof was verified, and the pairwise account. Never a claim. Never the person's agent. The holder's own receipt, in her vault, adds the one thing the door cannot know: the mandate the presentation was made under.

Two kinds of anonymous credential, and a message between two agents

The packages carry two presentation suites over the same credential. Both keep the person's account off the wire; they differ in what the verifier learns and in whether two verifiers can compare notes.

Selective disclosure (sd-jwt). The holder reveals the claims the verifier asked for — the claim values — and withholds the rest as digests. She presents under a pairwise pseudonym, so the same verifier recognizes her next time and a different verifier gets a different name. But the issuer's signature travels with every presentation, and it is the same bytes each time, so two verifiers who pool their logs can tell they saw one credential. This is the suite for a verifier that is entitled to the values: the organization's own agent, which needs the membership number to post dues against the right ledger.

Zero-knowledge predicates (openac-sd-jwt-p256). The holder proves that a statement over the claims holds — over 18 and a member — and reveals no value, no credential, no issuer signature and no device key. The verifier learns that the statement is true and which issuer stands behind it. Nothing in the proof links two presentations. This is the suite for a verifier that is entitled to a fact, which is most verifiers.

A request names one suite and gets that suite or a refusal. There is no ladder from the second down to the first; a verifier that asked for predicates never finds itself holding a birth date.

Proof of membership, dues paid, and the organization never learns her name

Here is the whole Open Commons in one everyday transaction, running today. A member of an organization has her agent obtain a membership credential from the organization, prove with it that she is an adult member, and pay her dues from her own account — and at no point does the organization learn which member she is. Three parties act: the member, the organization's steward, and the organization's own agent. No one runs a script holding a key; every step is an agent acting under a permission a person signed, and every record ends up in the vault of whoever it belongs to. This is what a personal agent looks like when it is a delegate and not a gatekeeper.

1. The member asks for her credential through her own agent. She tells her agent to ask the organization for a membership credential. Her agent confirms with the organization's agent that she is on the roster, takes the public half of her signing key from her vault, and leaves a request with the organization. The request carries that public key and nothing else; the private half is never touched.
2. The organization issues it, as the organization. The steward asks the organization's agent to issue, vouching for one extra fact — that the member is over eighteen. The act belongs to the organization, not the steward: it runs under a permission the steward signs on the organization's behalf, with a second approval in between. The agent checks the roster (someone not on it is refused in plain words, and this act never adds anyone), reads the organization's published issuing key, and builds the credential bound to the key the member named. The issuing key lives in a key service with exactly one job: it signs credentials, only when told exactly what it is signing, and it can never present one. The organization records what it issued — which credential, under which key, to which member — and never the facts inside it. The steward's own transcript holds a reference, not her details.
3. The organization stands behind it, automatically. Issuing also writes an entry into the organization's own list of credentials it still vouches for. An automated job reads that list and publishes its fingerprint to a public ledger that no organization controls. Nobody runs a command; the published fingerprint updated within the minute. Revoking a credential later is just taking it off the list.
4. The credential lands in her vault, under her own control. The organization has no access to her vault and needs none: the credential is written into her own record by her own permission, the way a receipt is handed to a payer. Her agent can use it; the organization can revoke it; neither can read the other's copy.
5. She proves she is an adult member, and is handed a bill. Her agent approaches the organization's online door under a one-time alias and proves two yes-or-no facts — over eighteen and a member — in zero knowledge: no birth date, no membership number, no credential, no key. The door checks the proof, confirms the issuing key is genuinely the organization's, confirms the credential is still on the organization's vouched-for list, and makes sure this same credential cannot present twice in the window. Then it issues a payment ticket: the organization's account, the amount, and a reference tied to that admission. Which organization's terms apply, the door reads from its own record of the admission, never from the visitor.
6. She pays from her own account, under a permission she signed once. Her agent pays the ticket from her own account to the organization's account. Her account is listed only in her private records — it has no public name — and her agent finds it anyway, because what is hers is in her own tier. The authority is a standing permission she signed once at her Home: this organization, up to this amount per payment, up to this much over thirty days. Each payment derives a single-use permission from it and her agent signs that; every link is verified before money moves. Paying the same bill twice moves nothing.
7. The organization accepts, and learns only that a member paid. The door confirms the payment arrived, settles the ticket once, and records the acceptance next to the admission that earned it. A forged ticket is refused; a settled one cannot settle again. The organization's books say an adult member paid dues. Which member is in her receipt, in her vault, together with the permission it was made under.

Two automated checks run this against the live system on a schedule: the visit itself (twenty-five checks, five of them deliberate refusals: a reused one-time token, a proof meant for another organization, a revoked credential, a replayed challenge, a credential from an issuer the door does not trust) and the payment (fifteen checks, four refusals: no bill without an admission, one settlement per bill, a forged reference, a repeated payment). The issuing step has refusals of its own: a non-member, an organization that has published no issuing key, a vault that will not accept the delivery — each said in words, none silently worked around.

The same path carries a message instead of a visit. An organization's agent that reads mail only from adult members, without learning which member wrote, asks the same two questions, verifies before it reads, and hands the steward a message from a one-time alias. That variant uses nothing the door does not; the proving half of it is what the door demonstrates every night. It is drawn out beat by beat, with who learns what at the end, in A message between two agents.

The seven "nos," scored honestly

Coin Center's principles are a checklist we can be graded against. Here is the grade today, failures included.

The policy half of the report — standards, certification of issuers, safe harbors for reliance, developer protection, credential minimization — maps onto things we already ship as evidence: issuer certification is an anchored facet; safe-harbor reliance is a verification receipt the institution can show; minimization is a per-grant setting on the person's agent, a ladder from plaintext down to predicate only that she chooses.

Identity for agents: an address, not a name, and never a score

Coin Center writes about the identity of people. The agentic web needs an answer for the identity of agents, and here the field is converging on exactly the mistake the report warns against: a registry that is also the authority, a name that is also the identity, and a reputation score that is also a permission.

Our answer has three parts.

Every agent is a smart account. A person's agent, an organization's, a service's — each is an on-chain account address, and that address is the canonical identifier. Names, agent cards, registry entries, DNS records and discovery listings are projections of it: delete a listing and you have lost a listing, not an identity. Credentials rotate; the address does not. When a credential is lost, the person replaces the key and keeps the address, through a recovery her trustees can see and she can cancel.

Resolution is not authority. Finding an agent — its endpoint, its card, its current keys — answers only "may this party discover how to reach it," never "may this party use it." A nameless agent is not an unresolvable one; a person's agent can be reachable by exactly the parties she granted, under grants bound to the recipient, and invisible to everyone else. The public graph that any town publishes holds nothing a stranger could not reproduce from the chain.

Reputation is six signals, never one number. When one agent resolves another in a context, the resolver returns the subject, the context, the relationship, the bindings, the authority and the evidence as separate signals. No gate anywhere reads a score. Attestations — endorsements, standing in a town, a steward's charter — are opt-in, signed by both parties, revocable by either, and read as evidence. Where the field's new registries publish reputation feedback, we treat the registry entry as one more facet of the address and the feedback as a discovery signal, never a permission. Coin Center's own example of a reputation threshold proof fits this exactly: the subject proves, in zero knowledge, that attestations she chooses to cite cross a line — the verifier learns that they do, and nothing about which.

Three scales, one rule

The products that run on these packages are organized by scale, because the privacy argument changes at each one.

Home (ap-home) is where a person, an organization or a service governs its own agent: the runtime that turns an ask into an intent, a mandate, a plan, per-step verification and a receipt; the vault that is the record; the admission edge in front of them; and a Home MCP that lets Claude.ai or any other client reach the person's agent as the person, under a delegation she can revoke, never under a bearer token. The rule on every screen: being a participant does not authorize an action; the requested effect must be within the acting principal's current, scoped delegation.

Town (ap-town) is one chain, every estate on it, and the services they share — a registry, a public graph, naming, chain access, a portal. Nothing in a town grants anything. A name resolves, a registry lists, the graph holds what the chain can prove, and an estate's authority stays in the estate.

Federation (ap-federation) is where two towns interoperate over proof rather than trust: a registry on neutral ground that no estate controls, where estates anchor the roots of what they vouch for and issuers anchor the roots of what they still stand behind; doors that admit a visitor on a leaf proved against a root read from that registry; and now the predicate grade, where the visitor proves a fact about a credential and the door learns the fact, not the visitor.

This is the Open Commons the report asks for, built from the agent's side rather than the wallet's. Muse, dots and Grok Bot could stand at any of these doors tomorrow. The question is whether they would present as the person's delegate, under a wire she holds, or as the person — holding her keys, speaking in her name, keeping her receipts on a machine she cannot carry away.

What a personal-agent platform should do

If I could put five sentences in front of the teams shipping Muse, dots and Grok Bot, they would be these.

1. Hold the agent as a delegate, never as the identity. The person's agent is an account she controls; your service holds a revocable delegation to act through it. When she leaves, she takes the account, the receipts and the credentials with her.
2. Approval is a signature, never an assertion. The emerging Personal Agent Protocol lets a company be told approved_by: user, and says itself that this works on trust. Let the confirmation be the signature over the specific act, bound to its intent, so the company holds proof rather than a claim.
3. The person is never the `client_id`. Your service is the client at the company's door; the person is a pairwise subject there, and nameless by default. She should be able to prove she is over 21, or a resident, or in good standing, without the door learning which person's agent asked.
4. Publish facets, accept predicates. If you issue anything — a membership, a verified-account status — anchor the issuing key where a stranger can check it, and accept a zero-knowledge predicate at your own doors so that the next platform's users can prove things to yours.
5. Let her revoke one wire. Not "sign out everywhere." One permission, for one venue and one kind of statement, gone in one transaction, with the agent otherwise unchanged.

None of this requires a chain the public cannot read, a registry one company runs, or a wallet one company ships. It requires the keys to be delegates, the proofs to be evidence, and the receipts to belong to the person. The walled garden is not the agent. It is the decision to make the agent the holder.

The open items, sorted by what they are

Three kinds of item, and the kind is said on each. A gap is something the design or the protocol does not yet do. Infrastructure means the design is done and what remains is to deploy or configure more of it. Carried otherwise means we do not close the gap as stated, because another mechanism gives the property and we say which. Each item also says whether the limit is OpenAC's or ours, and what it would add to the bill. The pilot today runs on one confidential VM (about $280–330 a month), Key Vault Premium (about $40–60), a burstable database, and Cloudflare Workers whose cost at this volume rounds to nothing.

Nullifier. Kind: a gap in OpenAC, carried otherwise. The value a door consumes is asserted by the holder — a signature over a fixed string with the device key, hashed. An honest holder produces the same value every time; a dishonest one running a different stack is not bound to it. The core specification lists nullifiers among the things it does not define, and the Show circuit emits no value derived from the device key; the sibling proof-of-personhood specification does it in-circuit, which is the shape OpenAC could adopt. How we carry it: the receipt records the grade as asserted so no reader mistakes it; in our own estates the device key sits in the key service and signs only under bound evidence, which narrows the dishonest-holder case to someone outside our stack; and the derivation uses a signature rather than the private scalar, so the in-circuit form can arrive without the key ever leaving custody. When the circuit ships, the switch is a policy flip. Cost to close: none to us; new verifying keys upstream.

Status proof. Kind: a gap in OpenAC, carried otherwise. The membership proof against the issuer's live-credential root reveals which leaf, so it links to the credential; a door asks for it only where the alternative is phoning a status list. Revocation is not in the profile and the circuit takes no status input. How we carry it: the root is anchored on neutral ground and read from the chain, so the issuer still learns nothing, and the row is shaped for the zero-knowledge form. Cost to close: none to us; upstream circuit work.

Key custody. Kind: infrastructure. The design is done and enforced: the key service's platform root is released only through attestation — Key Vault hands the key that seals it only to a genuine, Azure-compliant, non-debuggable AMD SEV-SNP confidential VM with our VM's id, wrapped to a fresh key inside that machine's TPM. A copy of the sealed root anywhere else releases nothing. The issuing key and the device key are the service's, each with one role, each signing only under evidence of what was judged. What remains to deploy: the release binds the machine, not the software on its disk, so proving which binary runs needs a measured, immutable OS image whose boot measurements enter the policy; then a second node in a second zone; then a quorum of two operators for the commands that change who may ask. Every restart today is a short boot ceremony that opens egress to the attestation service for a minute. Cost so far: one HSM key, about a dollar a month, and cents of network per boot.

Network privacy. Kind: a gap, ours and everyone's. Edge workers see the sender's address and timing; it is outside what any credential protocol can fix. We say so. The design candidates are a relay in front of the door that strips the origin, or onion routing for the knock. Cost to close: a relay is one more Worker and a small VM for the exit, perhaps $20–50 a month; an onion layer is a design project before it is a cost.

Offline. Kind: a gap, by our choice. The expensive half of the proof is prepared offline; the showing half needs the runtime, because that is where the release judges the wire. OpenAC's Show is cheap enough to run on a phone. A local judge evaluating a cached mandate on the device would let the agent present without the runtime; it moves the judge off the custodied side, which is a real trade we have not made. Cost to close: none in infrastructure; the cost is the security argument.

A door's receipts. Kind: closed. A receipt keeps its parties only for the window in which a dispute could need them (thirty days at the live door), then collapses to the kind of decision, its effect, its codes and the decision it belongs to. The row's hash in the chain never changes, so the chain still vouches for a record the door no longer holds. The payment ticket binds the admission receipt, never the person.

Issuer. Kind: closed. A door names the issuers it accepts and the verifier is handed only their facets; a presentation under any other facet is refused before a byte of proof is read. The organization's own agent issues to its members, keeps the record, vouches on its own row, and a scheduled projector keeps that row fresh without an operator. The issuing playbook is its own archetype, assigned only to an organization that has published a facet, so turning issuing on for one organization changes no other.

Transport. Kind: closed. A zero-knowledge proof bundle is tens of kilobytes and the edge of the public internet caps an HTTP header at sixteen, so a knock has two steps by specification: the presentation is posted first and held under a reference the door derives, unverified, for ten minutes, and the knock cites that reference. Nothing is verified until the knock, and the receipt keeps the digest, never the bundle.

The signer patch. Kind: a gap in OpenAC's API, carried otherwise. The published openac-sdk takes the device private key as a value in the prover's process; we run a forty-line patch that lets present() take a signer callback instead, so the key can stay in the key service. The patch is applied on every install, refuses a high-S or malformed signature, and is written up for upstream. Cost to close: a review upstream.

The four-pattern limit. Kind: infrastructure. The 1k circuit matches at most four claim-or-predicate patterns, so a membership credential that proves two predicates carries two claims. The 2k keys lift it at the cost of larger proving keys and a slower Prepare; we take them when the prover's time budget allows. Cost to close: storage for the keys and seconds per proof.

Ten items. Three are closed. Three are OpenAC's, and we carry the property another way until its circuits land. Two are infrastructure — things to deploy, with the design already in place. One is a gap we share with every network protocol, and one is a trade we have chosen not to make.

Sources: Coin Center, [Tear Down this Walled Garden: American Values and Digital Identity](https://coincenter.org/tear-down-this-walled-garden/) (September 2025); Meta's Muse launch coverage ([TechRepublic](https://www.techrepublic.com/article/news-meta-muse-ai-agent-us-launch/)); OpenAI's dots launch coverage ([Al Jazeera](https://www.aljazeera.com/economy/2026/9/30/openai-launches-dots-personal-ai-assistant-built-to-handle-everything)); Grok Bot beta coverage ([bleap](https://www.bleap.finance/en-us/blog/grok-bot-guide-how-it-works-pricing-uses)); the Ethereum Foundation's zkID and OpenAC work (the `1/OPENAC` specification and the `2/ZK-PROOF-OF-PERSONHOOD` specification, for what is and is not in-circuit); the key service's decision records on the second curve and on releasing its root only to an attested machine. The three product repositories: [ap-home](https://github.com/agentictrustlabs/ap-home), [ap-town](https://github.com/agentictrustlabs/ap-town), [ap-federation](https://github.com/agentictrustlabs/ap-federation). The architecture pages on this site: [chains and estates](/architecture/chains-and-estates), [the four scales](/architecture/scales), [operating](/architecture/operating).