The mission has no field

On 29 September the IETF's workload identity working group merged a batch of changes into its identifier draft. They specify that two workload identifiers are equivalent only if their normalised URIs match byte for byte; that a percent-encoded slash must stay encoded through that comparison, because inconsistent processing lets authorization checks be bypassed; and that an identifier arriving as a plaintext string in a request must never be treated as authenticated at all. Someone sat down and thought hard about %2F. This is what careful standards work looks like, and there is not much of it about.

Two weeks earlier, in the same working group, a file was renamed. draft-klrc-aiagent-auth.md became draft-ietf-wimse-aims.md, which is the mechanical signature of a working group adopting an individual submission as its own. The document is titled "AI Identity Management System". Its authors are drawn from Defakto Security, AWS, Zscaler, Ping Identity, Okta and OpenAI — which is to say, from the part of the industry that has spent twenty years learning how hard this is. It declines to invent anything. SPIFFE supplies identifiers, WIMSE supplies credentials, OAuth 2.0 supplies delegation, OpenID's Shared Signals supplies revocation. Read it end to end and it is difficult to name a component it leaves out. These are working-group drafts, read as they stand in the group's own repositories rather than as finished RFCs, and the sentence this piece turns on could be rewritten next month.

Except one. In the authorization section there is a short subsection called Agent Mission, and it contains the sentence on which the whole structure turns. An agent receives a mission — a task, expressed in natural language, from a user, a system or another agent. That mission has to be decomposed into specific resource requirements and the access requests that correspond to them, and the draft says plainly that this happens as a planning step before the agent asks for anything. Then: the process by which a mission becomes authorization requirements is "out of scope of this specification."

I want to be precise about what that is and is not. It is not an oversight; the draft is explicit, and it is explicit in the same register it uses for the policy format and the compliance criteria, both of which it also hands back to the deployment. What it is, is the point where a stack that has been rigorous about who is asking stops short of what is being asked for — and in agent systems those are no longer the same problem wearing different hats.

Look at the care taken everywhere else. An agent must be assigned exactly one WIMSE identifier. It must hold credentials that cryptographically bind a key to that identifier, with an explicit expiry, and those credentials should be short-lived; static API keys are named as an antipattern, in writing, which is a small act of courage. Credentials are issued at run time only after posture assessment — attestation evidence, integrity measurements, supply-chain provenance, orchestration metadata, whatever the risk justifies. Authentication happens at the transport layer, or at the application layer when a proxy terminates TLS and breaks identity continuity, with proof tokens bound to the specific request so a captured one cannot be replayed elsewhere. Audit records must be tamper-evident.

And then this, which is the most interesting sentence in the document: the large language model must not have access to the agent's credentials, or to the credentials needed to reach tools and services, and the stated reason is to prevent the model being manipulated by prompt injection into disclosing them.

The draft, in other words, knows exactly what the model is. It treats it as a component that an adversary may be speaking through, and it builds a wall between that component and the keys. That is the correct instinct. But put the wall next to the mission sentence and the shape of the problem appears. The model cannot take the key. The model's planning loop is what decides which doors the key will be asked to open.

That is the whole argument, and it is worth stating without ornament. Least privilege used to be a design-time property. A developer decided that the calendar integration needed read access to events and not write access to contacts; the decision was made once, by a person, and it shipped inside a reviewable artefact. The grant was a static property of a client version. You could diff it. In an agent system the request is computed per task, at run time, from a sentence — and the only normative guidance the framework offers on how much to ask for is a single SHOULD, tucked into the privacy considerations, saying that agents ought to request the minimum scopes necessary to complete a task. Necessary according to whom? According to the planning step that is out of scope.

Now go and look at the audit requirements, because this is where it becomes operational rather than philosophical. The draft is good here. It says observability is a security control and not merely an operational feature, and it mandates what every audit event must record. The list runs to seven entries: the authenticated agent identifier, the delegated subject, the resource or tool reached, the action requested and the decision, the timestamp and correlation identifier, the posture or risk state that influenced the decision, and any remediation. The draft then says that end-to-end audit lets an auditor trace which entity did what, using which authorization context, and why access changed over time.

The mission is not on the list. Nothing on that list is the sentence a human typed, or the sentence another agent passed along, from which the scope request was derived. "Why access changed over time" is a question about revocation and risk signals; it is not the question "why did this agent believe it needed to delete that bucket". After the incident you will be able to prove, to a cryptographic standard, which agent made the call, under which identifier, with what posture, against which policy, at what millisecond. The one thing you will not be able to reconstruct from the record the standard requires is what it was trying to do.

The companion architecture draft makes the gap sharper rather than smaller. It treats AI intermediaries as a special case of delegated workloads, and it is appropriately nervous about them: an agent should propagate the upstream security context unless it has been explicitly authorized to translate or reduce its scope, and in agent-to-agent chains each hop must explicitly scope and re-bind the context, because without that a chain of AI-to-AI interactions could extend authority far beyond what was originally granted. Every hop carries a normative obligation to scope. The procedure that produces a scope is specified nowhere. The obligation is real and the method is a planning step.

The strongest objection is that this is simply correct jurisdiction, and it deserves a fair hearing. Standards bodies specify wire formats, credentials and verification rules; they do not specify application semantics. Nobody asked the OAuth working group to decide which scopes a mail client needs, and a framework that tried to standardise prompt-to-scope translation in 2026 would freeze the worst version of a technique that is eighteen months old. The draft is honest about being a profile that identifies gaps for future work, and it names its own weak points — including a frank note that the backchannel authentication flow it recommends for human approval only models client initiation, and maps poorly onto the case where a human needs to confirm something mid-execution. A document that tells you where it does not reach is behaving well.

I accept nearly all of that. The planning algorithm should not be standardised. But the objection answers a demand nobody is making. The analogy to the mail client breaks on timing, not on jurisdiction: that scope set was chosen by a human, once, in code, and the artefact was reviewable before anything ran. The agent's is chosen per task, by software, at run time, and then thrown away. What a framework cannot reasonably decline — not if its own audit section is to mean what it says — is to carry the input to that computation in the record as a first-class, bound artefact. The draft already owns the machinery. Transaction tokens exist precisely to bind a downscoped authority to a specific transaction's context; proof tokens already hash the other tokens they relate to. A mission identifier, bound into the request and recorded beside the decision, is the same move applied one layer earlier. It does not standardise the planner. It makes the planner's output attributable to its input.

The deeper pattern is worth naming, because it will repeat. When we automate a judgement that used to be made by a person at design time, the machinery we build to govern it tends to inherit the mechanisms of the old world and lose its artefacts. Identity, credentials and revocation all survived the transition, and they came through strengthened: short-lived, attested, cryptographically bound. The design review did not survive. The commit did not survive. The sentence in the ticket that explained why a system was being granted this access rather than that did not survive, because there is no longer a ticket — there is a prompt, and prompts are not kept.

So we are building systems that will answer, perfectly, the only question an incident review never has to ask. Who did this? We will know. We will know the trust domain, the key, the posture at issuance, the millisecond. And when the auditor asks the question they always ask — what did it think it was doing — the correct answer, under the standard as written, will be that the process is out of scope.