Manifesto
Four problems that compound
Each of these failures is serious on its own. Together, they make it nearly impossible to deploy AI agents into high-stakes environments with any confidence in what they'll do or any ability to explain it afterward.
Why identity isn't enough
Most teams treat agent authentication as the hard problem and stop there. If the agent proves who it is — via a signed token, a client certificate, an API key — the receiving system grants access. That works for services. It doesn't work for agents.
Agents act under instruction. The same agent identity can be directed to exfiltrate data through a prompt injection, execute a misunderstood task at 2am, or escalate privileges because a system prompt said to "do whatever it takes." Authentication tells you who is asking.It says nothing about whether the request is within the intended scope of that agent's authority — or whether the instruction driving the request is legitimate.
What's missing is authorization that travels with the agent's task context, not just its identity. A credential that encodes not just "this is Agent A" but "Agent A, acting on behalf of user X, to complete task Y, within constraints Z." Identity is a prerequisite. It's not the solution.
Why revocation breaks at scale
Authentication scales. Revocation doesn't.
Issuing a credential is a write-once operation. Revoking it — and making sure every system that might accept it knows it's been revoked — is a distributed systems problem that gets harder with every participant you add. OAuth tokens have expiry windows partly because revocation lists don't work well at scale. Certificates have the same issue: CRL and OCSP are bolted-on compromises, not clean solutions.
Agents make this worse in two ways. First, agent deployments can involve dozens of active sessions simultaneously — each carrying its own credentials, each potentially mid-task when revocation happens. "Stop what you're doing" is easy to say; it's hard to guarantee across distributed infrastructure. Second, agents often act on behalf of a user whose access has been revoked. When an employee leaves or a service account is suspended, every in-flight agent session tied to that principal needs to terminate. There's no standard mechanism for propagating that signal.
The practical result: most teams treat revocation as a cleanup step rather than a real-time control. That's an acceptable risk for a service that runs a scheduled job. It's not acceptable for an agent that can send emails, modify databases, or execute financial transactions while you're waiting for propagation to complete.
Why delegation chains become unmanageable
Single-agent deployments are already complex. But the direction the industry is moving is multi-agent: an orchestrator breaks down a task and spawns specialized sub-agents, each of which may spawn further sub-agents. This is where delegation becomes a structural problem rather than an edge case.
Each hop in the chain is an opportunity for scope creep. If Agent A can read and write customer records, and it delegates to Agent B, does Agent B inherit those permissions? All of them? A subset? Who decides, and where is that decision recorded? Currently the answer is: the code does, implicitly, with no formal model and no audit trail. In practice, sub-agents often inherit the full permissions of their parent because restricting them is extra work with no obvious enforcement mechanism.
The deeper issue is accountability. When Agent C — three hops from the human who initiated the task — takes an action that causes harm, you need to reconstruct the full chain of delegation to understand what was authorized at each step. Without a formal delegation model that propagates signed, inspectable tokens, that reconstruction is manual, incomplete, and adversarial.
Delegation chain — example
Without a formal delegation model, Agent C inherits permissions from the top of the chain with no record of what was intended at each step and no mechanism for the human to constrain or inspect what C can do.
Why auditors need decision provenance
Infrastructure logs tell you what happened. They don't tell you why. For human-operated systems, the "why" is usually recoverable — you check the ticket, the deploy log, the Slack thread, the person's memory. For agents, the reasoning that produced an action exists only in the model's context window at the moment of execution, and it's gone as soon as the session ends.
This is the decision provenance problem. Regulators, auditors, and incident responders increasingly need to answer questions like: what instruction led to this action, what policy was evaluated, what alternatives were considered, and who in the human chain bears responsibility. An S3 bucket deletion logged in CloudTrail is an observable effect. The reasoning chain from "user said clean up staging" to "delete 40GB of customer data" is not recoverable from infrastructure logs alone.
The gap grows as agents operate more autonomously. A human-in-the-loop system is at least partially self-documenting — the human's approval is a record. A fully autonomous agent that acts on a multi-step plan makes dozens of decisions with no approval checkpoint. When one of those decisions causes harm, the absence of a structured provenance record isn't just an inconvenience. In regulated industries, it is a compliance failure. In litigation, it is an evidence problem. In security incident response, it means you cannot close the investigation.
These aren't theoretical problems. They're already happening in early agent deployments.
Security teams are discovering prompt-injected agents with unconstrained API access. Compliance officers are failing audits because agent actions can't be reconstructed. Platform engineers are manually rotating credentials across dozens of agent sessions when a service account is compromised. The tooling doesn't exist yet — and without shared standards, every organization is solving the same problems independently and inconsistently.