pki.sgit.ai / mandate

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

StatementSaysSigned byRevoked by
IdentityThis key belongs to this agentThe key itselfA signed append from that key
MandateThis agent may do these things, until this date, on whose authorityThe authority granting itA signed append from that authority — independently of the identity

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.

Why this is materially different from a token

A bearer tokenIdentity + mandate
What it provesPossessionPossession, and a separately signed grant
Who can check itThe issuerAnybody, offline, against a published record
Scope is visible toThe issuer's consoleAnybody reading the mandate
Narrowing what it may doReissue the tokenAppend a new mandate; the identity is untouched
ExpiryWhatever the issuer setStated 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. 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.

And the limit underneath all of it. A registry can say this key claims to be this agent. It cannot say this key is currently in the hands of that agent and nobody else — that is attestation, and neither keys nor vaults supply it. Whoever holds the key is the identity. Where our approach loses, in full.

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