Identity and mandate are separate statements
A key answers who is this. It does not answer what may this one do — and for agents the second question is the one that matters, because the current answer everywhere is "everything you can do". The registry separates the two into signed statements that revoke independently.
What today's answer actually is
Survey the available ways to give an agent a shared working area and one finding comes back from all of them: every option runs on your identity. The agent authenticates as you, holds your permissions, and is indistinguishable from you in whatever audit trail exists. So a rogue session reaches everything every other session can reach, and nothing can be attributed to the agent rather than to you. Nothing surveyed supports per-agent keys at all — three requirement rows come back empty across the whole market. That evidence is published on nhi.sgit.ai, and per-agent keys in a registry are what would fill those rows.
The two statements
| Statement | Says | Signed by | Revoked when |
|---|---|---|---|
| Identity | This key belongs to this agent | The key itself | The key is compromised |
| Mandate | This agent may do these things, until this date, on whose authority | The authority granting it | The permission changes |
The when column is the whole argument for paying the cost of two statements. Those are different events that happen at different times for different reasons — and a system with one statement has to treat them as the same event.
Both are entries in a record, so both obey the four rules: appended, signed, size-bounded, owner-written. Both are checkable by a third party who trusts neither the agent nor the operator — which is the property a bearer token cannot have.
Two principles, stated exactly
Both are one-liners, both are precise, and both stop a reader building the wrong thing — which is what this page is for.
Encryption restricts who can read a mandate. The signature and subject binding establish who may exercise it.
The two get conflated constantly, and conflating them produces somebody believing a mandate is safe because it is encrypted — when what makes it safe is that exercising it requires a private key the reader does not hold.
A signature over an enrolment request proves the submitter controls the corresponding private key. It does not prove that the project should trust the agent. Trust is a policy decision made afterwards.
A signature proves possession and proves nothing about trustworthiness. Recognition is a decision, not a computation — which is a feature, because it means the issuer retains judgement.
What a mandate carries
The authorisation object, as the execution work specifies it — listed because "a signed permission" is too vague to implement or to check:
| Group | Fields |
|---|---|
| Who | Subject · issuer |
| Where | Service and instance · resource · environment |
| What | Capability · constraints (for example an allowed path set, or a maximum changed-file count) |
| When | Workflow and stage · validity window · usage limit |
| Proof | Signature |
Verification checks the issuer signature, the subject, the requester's proof of possession, the requested action, and validity including revocation. Note that constraints like an allowed path set cannot be checked by forwarding a request — enforcing them requires interpreting it, which is where the engineering cost sits.
Why this is materially different from a token
| A bearer token | Identity + mandate | |
|---|---|---|
| What it proves | Possession | Possession, and a separately signed grant |
| Who can check it | The issuer | Anybody, offline, against a published record |
| Scope is visible to | The issuer's console | Anybody reading the mandate |
| Narrowing what it may do | Reissue the token | Append a new mandate; the identity is untouched |
| Expiry | Whatever the issuer set | Stated in the mandate, and readable by the relying party |
The load-bearing difference is the third row. A token's scope is knowable only to whoever issued it; a mandate's scope is a published statement, so the party relying on it can see the limits of what it was given — and refuse work outside them.
The caution that has to travel with this
A signed mandate constrains what an agent may be authorised to do, not what it does within that authority.
That distinction is easy to lose and expensive to lose. A mandate narrows the grant; it does not observe the agent, bound its spend, cap its time, or tell you where it reached. It is one control among several and composes with them — it does not replace them. The execution layer is what closes it, and it closes it by holding the credential rather than by writing a better policy. A registry that is sold as solving agent security would be repeating, in a new register, exactly the overclaim this project spends its time arguing against.
So the obvious next question — if a mandate does not observe the agent, how does anybody know who is using one? The answer is not the one the question expects, and it is worth stating here rather than leaving the caution above sounding like a shrug. Nobody can tell you who is using a mandate. What is capturable is verification, and verification and use come apart in both directions: a relying party that uses a mandate without bothering to check it generates nothing at all, while a resolver walking the chain past one generates an event with no usage behind it. The error runs in the worst direction, because the party that never checks is the party whose relying process is weakest. What is answerable — and it turns out to be the more useful question — is the inverse: which parties hold a mandate you issued and have never once checked it. The issuer knows who it issued to, and its own append lane records who checked, so the difference is computable. The observability design is that argument in full, including why the check events belong in the issuer’s own lane rather than a central log, and why the interval between a party’s checks is its revocation latency — measurable before anything is ever revoked. The sentence above stays true. This measures around the edge of the hole; it does not fill it.
Who may vouch, and the fractal problem
A mandate issued by somebody other than the agent is a third-party attestation — the exact mechanism that made the old network valuable and made it attackable. So the mandate concept cannot be adopted without answering the attestation question, and it cannot be nested without answering the trust-root question: in a structure of registries within registries, each store must declare which roots it accepts, or the graph is unevaluable. Who may claim to be a root is a privileged decision needing a stated answer, even a simple one.
This is also why the private registry comes first. Inside one organisation, the trust root is not an open question — it is the organisation. That is the version of the problem worth solving before the version with strangers in it.
Open, and deliberately so
- Is a mandate a separate object from an identity, or a field on it? It should be separate, since they revoke independently — but that is a design position, not a settled implementation.
- How is the binding between an agent and its key verified in the first place? The replacement keyserver used email. Agents have no equivalent, and this needs an answer.
- What does an agent's identity actually attest to — which agent, running where, on whose authority, checked how?