Verifiable Agent Mandates: From Technical Identity to Delegated Authority

How to read this briefing

Three kinds of statement are kept apart, and each paragraph carries a label:

• Stated in the drafts what the Internet-Drafts specify or state, paraphrased closely, with short quotations;
• Institute analysis the Institute’s reading of what the drafts settle and what they leave open;
• Educational question — ARENOMICS Institute questions and positions the Institute is developing for teaching Mandate Engineering.

This briefing continues section 3 of the Institute’s analysis The 10,000-Agent Problem (12 October 2026), which found that standards work on agent identity was converging while work on mandates was not. Document statuses were checked on the IETF Datatracker on 26 October 2026.

A. Two drafts, two different questions

Document status as shown on the IETF Datatracker, 26 October 2026

Stated in the drafts AIMS opens: “This document proposes best practices for authentication and authorization of AI agent interactions.” The mandate draft names a narrower gap: “What is not yet defined is evidence that the party at the root of a mandate was entitled to grant it.”

Institute analysis The two documents answer different questions. AIMS describes how an agent proves who it is and obtains access within today’s identity infrastructure; the mandate draft asks how a stranger in another organisation can check that the agent was given the power it claims, by someone entitled to give it. The mandate draft itself describes its relation to AIMS as complementary. Neither is a standard, and the mandate draft is one of eighteen individual drafts that the Datatracker currently lists as related to WIMSE, several of them on delegation chains and authorisation evidence.

B. Agent identity and workload authentication

Stated in the drafts AIMS treats agents as workloads. “An agent participating in this framework MUST be assigned exactly one WIMSE identifier, which MAY be a SPIFFE ID”; its credentials should be short-lived and must carry an explicit expiry, and it authenticates with mutual TLS, WIMSE Workload Proof Tokens or HTTP Message Signatures. “Static API keys are an antipattern for agent identity.” The language model itself “MUST NOT have access to an agent’s credentials”.

Stated in the drafts The mandate draft states what such identity proves: a Workload Identity Token from the operator asserts an instance identifier bound to a key, and nothing about the model, its configuration or its behaviour.

Institute analysis Identity answers two questions: which running workload is this, and can it prove it? It does not say who allowed that workload to act, for whom, or within which limits. The drafts are consistent with the picture in the 10,000-agent analysis: identity is the layer on which standards work is converging.

C. Authorisation and organisational authority

Stated in the drafts For authorisation AIMS relies on OAuth 2.0 as the delegation framework. In an access token the agent appears as the client and the user or system it acts for as the subject. Users delegate through the authorisation-code grant; agents acting on their own behalf use client credentials or a JWT grant. Tokens can be exchanged for short-lived transaction tokens bound to one transaction, and forwarding an agent’s token to downstream services is called an anti-pattern. Transaction tokens, identity chaining and the identity-assertion JWT grant are themselves defined in Internet-Drafts that are still in progress. Where a person must confirm an action, the agent “MUST NOT treat local UI confirmation alone as sufficient authorization”.

Institute analysis An OAuth grant records that a user or system consented to give a client access within certain scopes. It does not record whether that person was entitled, inside their organisation, to confer that power — for example, whether the employee who connected a treasury agent to the company’s bank account had authority to commit the company to payments. Technical authorisation and organisational authority are different relations: the first can be flawless while the second is absent.

D. Mandates, authority assertions and verification

Stated in the drafts The mandate draft separates roles that are usually merged: the principal on whose behalf the agent acts; the delegator, who grants the root mandate (the principal or someone authorised to act for it); the authority source, which asserts that the delegator holds that authority; the mandate issuer, which signs the mandate on the delegator’s instruction; the agent instance; and the relying party in the other domain. Its examples are a company’s treasury agent initiating a payment at the company’s bank and a broker’s agent sending an instruction to a custodian.

Stated in the drafts It then keeps two signed statements apart. A Mandate Assertion says that a mandate was granted; an Authority Assertion, issued by an authority source such as a register of legal representatives, says that the delegator was entitled to grant it. The draft states that “a Mandate Assertion alone never establishes the delegator’s authority.” It does not prescribe which authority sources are acceptable; for the European Union it notes that assertions may be derived from electronic attestations of attributes under Regulation (EU) 2024/1183.

Stated in the drafts Validation follows thirteen ordered steps, from the structure of the chain, signatures, time and revocation status to the delegator’s authority, key binding, audience and the match between the requested action and the mandate. The validator performs every step it can and records every failure rather than stopping at the first, and “Two conforming Validators given identical inputs MUST produce identical Validation Results.” The result is valid, invalid or, when only the revocation status could not be obtained, indeterminate.

Institute analysis The proposal goes directly to the question Mandate Engineering starts from: not only what the agent may do, but whether the person who said so had the standing to say it. The draft’s contribution is to make that second question checkable by a party that does not trust the first organisation. Its dependence is equally clear: the check is only as good as the authority source and the trust framework that decides which sources count, and the draft deliberately defines neither.

E. Delegation chains and attenuation

Stated in the drafts In the mandate draft an agent may sub-delegate only while a maximum depth allows it. Each child mandate must expire no later than its parent and must be attenuated: every request matching the child must also match the parent. Cumulative budgets travel with the chain, so actions taken by sub-agents count against the same limit. The draft also states the limit of attenuation on its own: “A chain that only narrows proves that no hop exceeded its parent” — not that the root mandate was within the delegator’s own authority.

Stated in the drafts AIMS does not define a general model for multi-agent delegation chains. It covers access across trust domains through token exchange and identity chaining, asks agents to request only the minimum scopes they need, and narrows access with transaction tokens bound to a single transaction.

Institute analysis Attenuation is necessary for a legitimate chain but not sufficient. A chain can narrow correctly at every step from a root that never had the authority to begin it. The draft supplies precise technical vocabulary for a point the Foundation programme makes in organisational terms: delegation can pass on less authority than the delegator holds, never more, and the first link must itself be justified.

F. Revocation, expiry, execution limits and audit evidence

Stated in the drafts The mandate draft expresses limits as machine-checkable predicates — equality, membership, maximum, minimum and time window — and two stateful ones: a cumulative budget over a rolling period and a co-signature requirement above a threshold. Amounts are decimal strings: “JSON numbers MUST NOT be used for amounts.” Each token authorises a single execution of the action; its lifetime is capped by the earliest expiry in the chain; revocation status is checked at validation and again at authorisation. On latency the draft states that a revocation after issuance “takes effect at the latest when the token expires”. Relying parties should retain the validation result, the decision and the confirmation of execution, and records kept for disputes may need to remain verifiable for years.

Stated in the drafts AIMS requires durable audit logs of authorisation decisions and remediations, recording among other things the agent identifier, the delegated subject, the resource, the action and the decision: “Audit records MUST be tamper-evident and retained according to the security policy of the deployment.” Revocation and risk signals can be distributed through the Shared Signals Framework, and recipients “MUST ensure that revoked or downgraded authorization is enforced without undue delay.”

Institute analysis Both drafts supply raw material for an evidence trail. Neither decides who reviews it or what counts as compliance: AIMS treats compliance criteria as specific to each deployment, and the mandate draft leaves retention, liability and dispute handling to trust frameworks. A cumulative budget shared by several relying parties is listed by the draft itself as an open issue, so a limit that looks global may in practice be enforced only by each relying party separately.

G. The unresolved layer: from organisational intent to enforceable permissions

Stated in the drafts AIMS notes that an agent usually receives its mission in natural language and that “The translation of a mission into authorization requirements is expected to occur as a planning step before the Agent requests authorization.” AIMS places the translation process itself out of scope, as it does the policy model and its format.

Stated in the drafts The mandate draft does not “define a trust framework, assurance levels, or the legal effect of a mandate”, nor how a delegator is shown or consents to a mandate, nor whether the agent’s reasoning or output is correct. “The format can express narrow mandates but cannot force issuers to write them.” And on manipulation: “A valid mandate shows that an action is within delegated authority, not that the agent was not manipulated into requesting it.”

Institute analysis The drafts make the result of translation verifiable; they neither perform nor check the translation itself. Whether a mandate such as “pay approved suppliers up to a monthly budget” captures what the board meant, whether the limits are right, and who answers when a valid mandate produces a harmful action remain organisational and legal questions. This is the layer the 10,000-agent analysis called untreated. After these drafts it remains untreated, but it now has a sharper technical boundary on one side.

H. What the drafts settle for Mandate Engineering — and what they leave open

Institute analysis Strengths: the mandate draft separates the grant from the authority behind it, defines deterministic validation, makes every token single-use and treats manipulation honestly. AIMS assembles a coherent identity and access baseline from published standards and from other drafts that are themselves still in progress. Limits: the mandate draft is a single-author individual submission with no adoption, implementation reports or published test vectors; it overlaps with other individual drafts on delegation chains and says its own chain format could be replaced; both drafts may change substantially.

Educational question — ARENOMICS Institute The Institute reads these documents as evidence that the mandate question has reached technical standards discussion, not as standards to teach. In the Foundation programme they can serve as worked examples of how a bounded, revocable mandate might be expressed and checked. The programme does not require participants to use them, and its specification is unchanged.

Open research questions

1. Who should be accepted as an authority source for an organisation’s delegations, and how is that acceptance itself governed?
2. How can a mandate written as machine-checkable limits be shown to match the organisational intent it is meant to express?
3. How should limits and revocation work when one mandate is relied on by several parties at once?

Sources

1. C. Hulea (Braincap SRL), Verifiable Mandates for Agents Acting Across Administrative Domains, draft-hulea-wimse-agent-mandate-00, individual Internet-Draft, 24 October 2026, expires 27 April 2027. Datatracker · full text.
2. P. Kasselman, J.-F. Lombardo, Y. Rosomakho, B. Campbell, N. Steele and A. Parecki, AI Identity Management System, draft-ietf-wimse-aims-00, WIMSE working-group Internet-Draft, 15 September 2026, expires 19 March 2027. datatracker.ietf.org/doc/html/draft-ietf-wimse-aims-00.
3. IETF, Workload Identity in Multi System Environments (WIMSE) working group, documents page, viewed 26 October 2026. datatracker.ietf.org/group/wimse/documents.
4. ARENOMICS Institute, The 10,000-Agent Problem: Who Has the Authority to Let Machines Act?, v0.1, 12 October 2026.

Verification: titles, authors, dates, status and every quotation were checked against the documents and the Datatracker on 26 October 2026. Internet-Drafts change frequently; check the Datatracker for the current revision before relying on any detail.