Human-agent delegation: who authorised what your AI agents do

An agent takes an action. Something goes wrong. Someone asks who authorised it, and the answer turns out to be a service account, a token issued eight months ago, and a prompt nobody kept. This page is about the artifact that should have existed instead, why none of the current identity stack produces it, and what a delegation that survives an incident review actually looks like.

The incident review where the question has no answer

Picture a platform team three hours into an incident. An agent with repository and cloud access has done something nobody intended: dropped a table, opened a pull request that changed an IAM policy, sent four hundred emails, or spent eleven thousand dollars of inference budget. The specifics vary and the meeting does not.

Someone asks the obvious question. Who authorised this agent to do that?

The answers arrive one at a time and none of them is an answer. The agent authenticated with a service account. The service account was created during a migration in March. It has a policy attached that grants a broad set of permissions because narrowing it broke something once. The agent was started by an orchestrator. The orchestrator was configured by an engineer who has since changed teams. The instruction that produced the behaviour was in a context window that no longer exists.

Every one of those statements is true, logged, and useless. Together they describe a machine that acted, and they never once name a human who decided. The organisation has perfect records of what happened and no record of anyone permitting it.

That gap is not an oversight by a careless team. It is the default state of every agent deployment in production today, because the identity primitives available describe software and sessions, and the question being asked is about a person.

What is human-agent delegation?

Delegation, in the ordinary sense, is old and well understood. A person authorises another party to act on their behalf, within limits, for a period, and can withdraw it. Law has handled this for centuries through agency doctrine. Organisations handle it through signing authority matrices and powers of attorney.

Software delegation has been much thinner. What we deployed instead was credential sharing with extra steps. An OAuth grant lets an application act as you, with a scope that is usually far broader than the task, for a duration that is usually indefinite, with no record of what you thought you were permitting. An API key is worse: it is a bearer secret with no owner, no expiry and no scope beyond whatever the issuing system attached to it.

Those primitives were adequate when the delegate was a deterministic integration doing one job. They are not adequate when the delegate exercises discretion, can be influenced by untrusted input, and can act hundreds of times an hour across systems.

Human-agent delegation means a specific artifact with five properties, and each one exists because a specific failure happens without it:

• It names a human root. Every chain terminates at a key held by an accountable person, not at a service account.
• It is scoped. It enumerates the action classes permitted, not a role that implies them.
• It is bounded in time. It has a start and an end, and the end is not "when someone remembers".
• It is bounded in depth. It states how many further hops of sub-delegation are allowed, because agents delegate to agents.
• It is revocable at the anchor. Withdrawing the root invalidates everything beneath it in one operation.

Why does the existing identity stack not answer this?

Because every layer of it was designed to answer a different question, and each does so correctly.

Workforce identity providers establish that a principal authenticated to a tenant and that policy permits an operation. That is an access question. An agent holding a valid token satisfies it perfectly whether or not any human intended the action, which is the same structural issue described in the companion pillar on proof of human intent: authority established once is inherited by everything downstream.

Non-human identity tooling inventories the service accounts, keys and workload identities that exist. That is genuinely useful and it is a census, not an authorisation record. Knowing that four hundred service identities exist tells you nothing about which human's authority any of them is exercising.

Cloud IAM records the calling principal, which for an agent is the agent's own identity. The human is not in the log because the human was not in the call.

The Identity Failure Map catalogues three failures that show up here repeatedly. IFM-04, Approval Theater, is a human-in-the-loop control an agent can satisfy by itself. IFM-08, Authority Opacity, is the inability of anyone, including the human, to enumerate what an agent may currently do. IFM-09, Revocation Non-Propagation, is authority that survives its own withdrawal in some other system. Together they describe most of what goes wrong.

What is actually in a delegation chain?

This is the central artifact of the whole area, so it is worth showing rather than describing.

A delegation is a signed object. The human signs the first one with a device-held key. Each field exists to close a specific gap.

{
  "v": 1,
  "type": "delegation",
  "issuer": "human:pk_7f2a...9c",        // the accountable person
  "delegateKey": "agent:pk_b41e...02",   // who may act
  "scope": {
    "actions": ["invoice.read", "payment.prepare"],
    "resources": ["tenant:acme/ap/*"]
  },
  "constraints": {
    "amount_max": "25000.00",
    "currency": "USD",
    "requires_human_release": true
  },
  "notBefore": "2026-10-02T00:00:00Z",
  "notAfter":  "2026-10-09T00:00:00Z",
  "maxChainDepth": 2,
  "revocationId": "rev_01J9X4...",
  "sig": "ed25519:..."
}

A sub-delegation, issued when an orchestrator hands work to a worker agent, is the same object signed by the delegate's key rather than the human's. The rule that makes the structure safe is monotonic narrowing: a child may remove actions, tighten constraints and shorten the window, and may never add anything its parent did not hold.

Verification is a walk, not a lookup. This is the property that matters most, because it means a counterparty can check authority without calling anyone.

def verify(chain, action, now):
    assert len(chain) <= chain[0].maxChainDepth + 1
    for i, link in enumerate(chain):
        assert verify_sig(link)                       # signature valid
        assert link.notBefore <= now <= link.notAfter  # in window
        assert not revoked(link.revocationId)          # still live
        if i > 0:
            parent = chain[i-1]
            assert link.issuer == parent.delegateKey   # actually linked
            assert subset(link.scope, parent.scope)    # never widens
    assert action in chain[-1].scope.actions
    assert chain[0].issuer.startswith("human:")        # rooted in a person
    return chain[0].issuer

The last two lines are the whole argument. The function returns a human, or it fails. There is no path through it that ends at a service account.

If the concept is new, how delegation tokens work covers the token mechanics from first principles, can an agent delegate to another agent goes deep on attenuation and the confused deputy problem, and how do I prove an AI agent is authorised is the short practical answer.

The map

Why is a human-in-the-loop button not a control?

This is the highest-scoring problem in our entire research set, and the argument is short enough to state in one sentence: any approval an agent can reach, an agent can satisfy.

Computer-use agents operate screens. They click buttons, fill fields and check boxes. When the human oversight mechanism for an agent is a confirmation dialog rendered in a browser the agent is driving, the oversight exists inside the agent's action space. It is not a gate, it is a step in the workflow. Your human in the loop is a button, agents click buttons develops this properly, including the uncomfortable observation that most published human-in-the-loop architectures have this shape.

The documented consequences are not hypothetical. Public incident reporting through 2025 and 2026 describes coding agents destroying production data, in at least one widely covered case during an explicit freeze the operator had declared in the prompt. The lesson those write-ups converge on, examined in three AI agents deleted production databases, is that an instruction is not a control. A freeze declared in a prompt lives in the context window, which is precisely the place that an injection, a summarisation step, or the model's own reasoning can erase.

The same reasoning applies to the consumer case. An agentic browser operates inside every session the user has open, and any content it reads is a potential instruction channel. Your agentic browser is logged into your bank is fair to the vendors, who are shipping real mitigations, while noting that those mitigations are detection and therefore inherit the arms race.

A control lives outside the agent's reach. In practice that means a signature produced on a companion device the agent does not drive, which is the one approval a computer-use agent cannot manufacture no matter how capable it becomes.

Can anyone say what an agent is currently permitted to do?

Ask a platform team to produce, on demand, a list of every action every agent in their environment may currently take, and the honest answer is nobody can. That is Authority Opacity, and it has two halves.

The human cannot inspect their own delegations. Scopes are per application, expressed in vocabulary the granting user never sees, and scattered across providers. Nobody has a single view.

The verifier cannot check scope independently. A service receiving an agent's request can validate a token against its issuer and cannot evaluate whether that authority was ever granted by a person for this purpose. What can your AI agents do right now? argues that the fix is to make authority a verifiable object rather than a database row, at which point the graph is simply the set of live chains and answering the question becomes a query.

Scale sharpens this. When one operator fans out into dozens or hundreds of acting agents, per-agent identities produce a crowd of well-formed principals with no anchor, and attribution requires investigation rather than a lookup. When one person runs three hundred agents makes the case for thinking in trees instead of crowds: in a tree every action carries a path back to a root, so attribution is a walk.

There is a compounding version of the problem that almost nobody has written about. Agents with infrastructure access do not merely consume credentials, they create them: service accounts, API keys, IAM roles, deploy keys, webhooks. Each is a new principal with durable authority, created by a process acting under delegated authority, with nothing recording whose authority was the root. Your agent just created three service accounts traces how the authority supply expands through entirely legitimate, well-logged operations.

How do you take authority back?

Revocation is where most agent architectures quietly fail, because in modern systems it is not one operation but a set of independent local ones that nobody can prove completed.

You disable the account in the identity provider. The OAuth refresh token in a third party service still works. The personal access token in CI still works. The API key pasted into the agent's environment still works. The signed JWT with an hour of life still validates. Each of those is a separate withdrawal in a separate system, and an agent fleet multiplies every one of them.

The engineering tension underneath is real and old. Stateless verification is fast and scales and cannot be revoked before expiry. Stateful checking is revocable and requires a call to the issuer. This is the same argument the certificate ecosystem fought to a partial conclusion through certificate revocation lists, stapling and ultimately much shorter lifetimes, and the conclusion it reached is worth borrowing: the practical answer to revocation is usually expiry. You revoked the agent, somewhere it is still running works through the tradeoffs and is honest that chains only govern authority that flowed through chains, so a raw API key handed to an agent is outside the model entirely.

What a chain does add is the anchor property. Revoking the root invalidates every descendant in one operation, and a verifier walking the chain sees the revocation without needing to know about every leaf. That is a structural improvement over token sprawl, and it is not a complete answer.

For the operational side, building the kill switch covers the design of an emergency stop, and the first hour after an agent goes wrong is the incident response companion. That runbook makes the argument better than any architecture diagram: at nearly every phase of a real incident, the responder's speed is determined by whether authority was ever expressed in a verifiable form. If it was, containment is one revocation and scoping is a query. If it was not, both are archaeology.

How does an agent prove whose human it is acting for?

Agent traffic currently identifies itself with a user agent string, an IP range, and sometimes a published crawler list. Those are claims. Any actor can assert they are a well known assistant, and servers routinely grant such traffic different treatment: relaxed rate limits, paywall exemptions, cleaner content. Anyone can claim to be your agent covers why this stopped being merely a bandwidth question once agents began to transact.

Web Bot Auth is the serious answer to half of this, and it deserves credit. Using HTTP message signatures as specified in RFC 9421, an agent can cryptographically prove which software sent a request, with adoption and interest reported across major infrastructure and commerce providers. It genuinely solves agent authentication.

It does not, and does not claim to, establish that a human authorised the action the request is attempting. A correctly signed request from an entirely legitimate agent operated by an attacker who compromised the user's account produces perfect signatures. That distinction is the subject of Web Bot Auth tells you which bot, not whose human, and the two mechanisms compose cleanly: the signature says which agent, the chain says whose human.

The same halving shows up in the compliance vocabulary. Know Your Agent programmes propose that platforms verify the agent the way they verify a business customer, which is sensible and necessary. It is also half a check, because Know Your Customer exists precisely to identify the natural person behind an account, and verifying the agent identifies the tool. Nobody would accept a customer due diligence programme that verified the wire transfer software rather than the account holder. Know Your Agent is half a check develops the beneficial ownership parallel, which is exact: financial crime frameworks exist because layers of intermediation were used to obscure the natural person who benefits, and agent intermediation is a new layer with the same property arriving faster than the frameworks.

What happens when agents spend money or agree to things?

The payments industry has moved quickly here and built real infrastructure, which makes precision about the remaining gap more important rather than less.

Card networks have introduced agent-bound payment credentials so a card can be used by an agent under network rules. Google's Agent Payments Protocol, contributed toward the FIDO Alliance with a substantial partner roster, defines signed Mandates expressing what a user authorised. These are serious pieces of work by serious people.

The gap is subtle and worth stating slowly. A Mandate is a signed statement of intent, and the signature proves the mandate was issued by a particular party and was not altered in transit. It does not prove that a live, unique human was present and understood what they were authorising at the moment of issue. If the consent step is a click in a session, every attack in the companion pillar applies to it, and the mandate then faithfully records an intent that was never formed. Authenticity of a document and authenticity of consent are different properties. The token proves the agent may pay, it does not prove you agreed covers the composition, and AP2 proves the mandate, not the human is the standards-specific treatment.

Contracts raise a related question with older law behind it. Electronic transaction statutes have contemplated machine-made agreements for decades, and agency doctrine handles authority. Both were written for deterministic systems executing a principal's instructions, and a modern agent exercises discretion, can be induced by an untrusted counterparty, and may transact faster than any human reviews. Whether apparent authority extends to an agent's discretionary acts is genuinely unresolved, and your agent agreed to the terms, are you bound? reasons from the doctrine without inventing case law that does not exist. The identity contribution there is evidentiary: nearly every open question turns on what authority the principal actually conferred and whether the counterparty could verify it, and today no artifact answers either.

Recurring obligations are the worst fit of all for blanket delegation, because a single agent action creates an indefinite future liability. A delegation permitting spending up to a cap does not sensibly permit committing to spend indefinitely, which is why my agent signed me up for forty things argues for treating recurring commitments as a distinct action class requiring their own signature.

Voice is the newest surface and the thinnest on evidence, so it is treated cautiously. Businesses receiving calls now face a question they have never had to ask, which is whether the caller is a human, an agent acting for a human, or an agent acting for nobody. An AI called your restaurant separates what is documented from what is inference and is explicit that voice is a poor channel for cryptographic exchange, so the realistic design carries a reference over a parallel data channel.

What about agents that write and ship code?

The software supply chain has excellent machine provenance and almost no human provenance, and agents are widening that gap quickly.

Keyless signing and build attestation answer, with real rigour, which pipeline produced this artifact from which source. Neither answers whether a human intended to publish this version. Sigstore proves the pipeline, nothing proves the person traces the trigger chain carefully and is scrupulous about crediting what the existing tooling achieves, including volunteering the case its own proposal would not have stopped.

Registry credentials are the other half. A self-replicating worm that began with compromised maintainer credentials propagated across large numbers of packages through install scripts and continuous integration during 2025, and registry two-factor authentication protects a login rather than a publication decision. Sigstore signs the build, who signed the decision to publish? proposes gating by blast radius rather than gating everything, which is the only version of the idea that survives contact with automated release practice.

Inside the organisation, deployment approval has the same shape. A pull request approval is a click in a session, a required reviewer setting is configuration the reviewed party can often change, and the deployment log names a service account. Who approved this deploy? is particularly useful on break-glass, arguing that emergency deploys should be fast and loud rather than slow and quiet.

At the ecosystem edge, the cost of producing a plausible contribution collapsed while the cost of evaluating one rose, because a fluent but wrong submission takes longer to disprove than an obviously wrong one. Maintainers are drowning makes that as an economics argument rather than a moral one, and the bounty programme that closed covers the case where a project concluded the arithmetic no longer worked. Both are careful that identity is not the first answer and that anonymous contribution has legitimate defenders.

For tooling specifically, the Model Context Protocol handles how a server authenticates a client and deliberately leaves human authorisation of individual tool invocations to the implementer. That is a reasonable separation of concerns, and it means every server author independently decides whether a tool that moves money needs a human, and most decide by not deciding. Your MCP server can move money is the practical implementation, with the gate, the pending state and the denial path in code.

What human-agent delegation does not solve

The limits here are substantial and stating them is not modesty, it is the difference between an architecture and a sales pitch.

It does not make an agent behave well. An agent operating within a correctly scoped delegation, for a human who genuinely authorised the scope, can still do something disastrous inside that scope. Delegation bounds authority, not judgment.

It does not cover authority that never flowed through a chain. An agent handed a raw cloud credential is entirely outside the model. The realistic posture is to shrink that surface over time, not to claim it is closed.

It does not help when the human is compromised. An agent acting for an attacker who controls the human's enrolled device produces a valid chain. This establishes accountability, not good outcomes.

It does not substitute for monitoring. Knowing who authorised an action is orthogonal to noticing that the action was anomalous. Both are needed and this page is only about the first.

A signature from an inattentive human is still a signature. The rubber stamp problem is real, and the honest response is to gate few enough actions that each one still receives attention.

Much of the composition described here is not shipped. Delegation chains, offline verifiable receipts, per-action signatures and the agent authorisation inbox exist today. An MCP guard middleware, an AP2 mandate adapter, Web Bot Auth composition, card network step-up and an enterprise authority console are proposals, and this page describes them as such deliberately.

Where do the standards sit?

None of this competes with the specifications being written. It sits above them, and each is worth describing accurately.

RFC 9421, HTTP Message Signatures, underpins Web Bot Auth and establishes which software sent a request. It is the right primitive for agent authentication and is silent on human authority by design.

AP2 and payment mandate schemes express what was authorised, in a signed and tamper-evident form. They establish the content and the issuer of the authorisation, not the liveness or uniqueness of the human who formed it.

The Model Context Protocol authorization specification handles client to server authentication for tool access and explicitly leaves per-invocation human approval to implementers, which is a deliberate boundary rather than an omission.

OAuth token exchange and RFC 9396, Rich Authorization Requests, are the closest existing prior art to scoped delegation. Rich Authorization Requests solve the expressiveness problem, letting an authorisation carry structured, typed detail rather than a coarse scope string. What they do not change is how the human's agreement is captured, which remains a consent screen in a session.

Agent-to-agent interoperability work, including the A2A effort, addresses how agents discover and describe each other. Capability description is a different question from authority provenance, and the two compose.

The EU AI Act's human oversight obligations are the regulatory driver. Article 14 requires that certain high risk systems be designed so that natural persons can effectively oversee them during use. Paraphrasing rather than quoting: effective oversight implies that a person can understand the system's capabilities, monitor its operation, and intervene or interrupt it. An organisation that cannot state what its agents are permitted to do cannot credibly claim to satisfy that, which is the practical connection between an authority graph and a compliance obligation. What human-in-the-loop actually means under the EU AI Act is the fuller treatment.

What to do this quarter

1. List every agent that can cause a side effect. Not every agent, only those that write, send, spend, deploy, provision or delete.
2. For each, write down whose authority it is using. If the answer is a service account, you have found the gap.
3. Classify actions by irreversibility. Gate the irreversible ones and leave the rest alone.
4. Move approval off the surface the agent controls. If the agent can click it, it is not an approval.
5. Set an expiry on everything. If a delegation has no end date, that is a decision nobody made deliberately.
6. Test revocation before you need it. Revoke a live agent's authority and time how long until every downstream system agrees.
7. Name a person who can revoke at three in the morning, and check that they can be reached.
8. Read the runbook before the incident. The first hour is much cheaper to read in advance.

The agent demo shows a delegation issued, an action attempted, and the chain verified back to a human key. The authorisation inbox is where a person sees and signs what an agent has queued, and the developer documentation covers the chain format.

Reading paths

If you are a platform engineer shipping agents

Start with approval theater, then the production database incidents for what goes wrong without a real gate, then the MCP human gate for the implementation, then chain depth and attenuation for multi-agent systems, and finish with agents minting credentials, which is the failure most teams have not thought about.

If you review agent access from a security seat

Read the authority graph first, then identity fan-out for what scale does to attribution, then revocation, then the incident runbook, and agentic browsers for the endpoint you probably have not scoped.

If you work in payments or commerce

Begin with agentic checkout, then the AP2 human presence gap, then Know Your Agent is half a check for the compliance framing, then recurring obligations, and agent impersonation for the traffic side.

If you sit in legal or compliance

Read human oversight under the AI Act first, then agent-formed contracts, then the authority graph as the artifact that makes an oversight claim defensible, then the beneficial ownership parallel, and the Identity Failure Map for shared vocabulary with your engineers.

Frequently asked questions

What is human-agent delegation? It is a signed, scoped, time-bound and revocable grant from a specific person to an autonomous agent, structured so that every action the agent takes carries a verifiable chain back to that person's key. It differs from an API token or OAuth grant, which identify the software making a request but record nothing about which human authorised it, for what purpose, or within what limits.

Why is an API key or OAuth grant not enough? Both identify software. An API key is a bearer secret with no owner, no expiry and no purpose recorded. An OAuth grant names an application and a scope, usually broader than the task and indefinite in duration, with no record of what the granting user believed they were permitting. Neither can answer which human authorised a specific action, which is the question every incident review asks.

Can an AI agent delegate to another agent? Yes, and safely only under two rules. A sub-delegation may narrow scope and never widen it, and the chain must carry a maximum depth so authority cannot travel indefinitely. A verifier then walks every hop, checking signatures, windows, revocation and monotonic narrowing, and the walk must terminate at a human key rather than a service account.

Does a confirmation dialog count as human oversight? Not if the agent can click it. Computer-use agents operate screens, so an approval rendered in a browser the agent is driving sits inside the agent's action space and is a workflow step rather than a gate. Meaningful oversight requires an approval produced on a surface the agent does not control, such as a signature on a separate enrolled device.

How do you revoke an agent's authority everywhere at once? You cannot, in general, because revocation is a set of independent operations across systems holding separately issued credentials. What a delegation chain adds is an anchor: revoking the root invalidates every descendant in one operation for any verifier that walks the chain. Credentials issued outside the chain, such as a raw API key, remain a separate problem.

Does this satisfy the EU AI Act's human oversight requirement? No technology satisfies a legal obligation by itself, and any vendor claiming otherwise should be treated with suspicion. What an authority record does is make an oversight claim demonstrable rather than asserted, because an organisation that cannot state what its agents may currently do will struggle to show that natural persons can effectively oversee them.

What is the difference between Web Bot Auth and a delegation chain? They answer different halves of the same question and compose. Web Bot Auth, built on HTTP message signatures, proves which software sent a request. A delegation chain proves which human authorised the action that request attempts, within what scope and until when. A correctly signed request from a legitimate agent operated by an attacker satisfies the first and fails the second.

What is shipped today versus proposed? Scoped, time-bound, revocable delegation chains, per-action signatures, offline verifiable receipts and an agent authorisation inbox exist. An MCP guard middleware, an AP2 mandate adapter, Web Bot Auth composition, card network step-up, threshold signing and an enterprise authority console are proposals described as such throughout this material.

Sources

1. IETF, RFC 9421, HTTP Message Signatures, the basis for signed agent requests: rfc-editor.org RFC 9421
2. IETF, RFC 9396, OAuth 2.0 Rich Authorization Requests, for structured authorisation detail: rfc-editor.org RFC 9396
3. Model Context Protocol specification, including the authorization section and its scope: modelcontextprotocol.io
4. Agent Payments Protocol specification materials on mandate structures: ap2-protocol.org
5. Cloudflare engineering writing on Web Bot Auth and signed agent traffic: blog.cloudflare.com
6. European Union, Artificial Intelligence Act, including the human oversight provisions in Article 14: eur-lex.europa.eu
7. Sigstore project documentation on keyless signing and transparency logs: sigstore.dev
8. Microsoft Security research on prompt injection and poisoned tool descriptions affecting agent tooling: microsoft.com security blog
9. Kaspersky Securelist and Elastic Security Labs reporting on self-replicating package registry compromise during 2025: securelist.com

An agent can hold a credential, sign a request, and present a mandate. Only a chain that ends at a person can answer the question an incident review actually asks.