Ask most agent architectures a simple question: which agent is allowed to call which tool, on whose behalf, with what scope? Nobody can answer it, because nobody designed the system to be able to. That's not a hypothetical gap. It's the default shape of almost every agent deployment running today.
This is not the prompt injection problem, which DAD covered in July. Prompt injection asks whether an attacker can trick a model into doing something it shouldn't. Identity and authorization is the layer underneath that question: even a model that perfectly resists every injected instruction can still hold a credential with far more reach than the task in front of it requires. Kodathala's aiAuthZ study tested exactly this gap empirically. Across 15 LLMs, refusal rates against forged-authority attacks (an attacker impersonating a user or system with elevated privileges) ranged from 38% to 100%. Even the most expensive models in the test refused only about half the time. The model was the last line of defense, and the last line of defense held about as often as a coin flip.
NIST noticed. In February 2026, the agency launched its AI Agent Standards Initiative and, within the same window, published a concept paper specifically on accelerating agent identity and authorization. Identity wasn't an afterthought bolted onto a broader agent-safety initiative. It was one of the first named workstreams out the door. That's a signal worth sitting with: the federal government's standards body looked at the agent landscape and decided authorization was urgent enough to fast-track, months before most engineering teams had scoped it as a project at all.
Prompt injection and authorization are different bugs
It's tempting to file "an agent did something it shouldn't have" under one bucket and patch it with better prompt hardening. That's a mistake, and the research literature is explicit about why.
Tallam's paper on authorization propagation in multi-agent systems draws the line precisely:
"Prompt injection is the novel attack vector. But there is a distinct novel architectural problem that persists even under the assumption that prompt injection is fully solved: the problem of maintaining authorization invariants as non-human principals make chains of autonomous decisions."
Read that twice. Even if you solved prompt injection completely today, tomorrow, with a model immune to every jailbreak and every adversarial document, you would still have agents inheriting credentials they didn't earn, still have sub-agents invoking tools with permissions nobody explicitly granted them, and still have no answer to "who authorized this specific action." Prompt injection is about what goes into the model. Authorization propagation is about what the system does with the output, regardless of how trustworthy that output is.
For engineering leaders this distinction has a direct budget consequence: money spent hardening prompts against injection does nothing to fix identity. An injection-resistant model sitting inside a container that hands it a database service account with full read/write access is still one bad tool call away from an incident. The two problems get solved with different tools, by different teams, and conflating them is how identity work keeps losing the roadmap argument to "we already shipped a prompt filter."
Implicit identity is the default, and it's a design bug
Here's the failure mode, named independently by two separate research groups. Uchibeke's paper on deterministic pre-action authorization describes agents on shared infrastructure that execute requests using inherited API keys, "conflating agent identity with system identity rather than establishing distinct authorization contexts." Tallam's paper describes the same pattern from the multi-agent side: agents relying on broad, service-account-style credentials instead of scoped, per-hop identity.
Translate that out of academic language. An orchestration layer spins up five sub-agents to handle a task. All five get the same API key, because that key was already sitting in the container's environment variables and nobody wrote a step to mint anything more specific. One of those sub-agents only needs read access to a knowledge base. It gets write access to a production database instead, because that's what the shared key can do. Nobody decided this. It's just what "inherit the environment" defaults to.
That's the exact pattern NIST's concept paper is now writing standards against, describing the core problem as ensuring agent productivity gains don't come at the cost of skipping "appropriate identification and authorization controls" over what an agent can touch. Tallam's paper proposes a counter-architecture built on two structural requirements worth naming directly:
- R1: agents as first-class authorization subjects. Every agent gets its own scoped identity, not a service account borrowed from its host process. The identity is bound to that agent, not to the infrastructure it happens to be running on.
- R2: delegation is explicit, bounded, and auditable at every hop. When Agent A invokes Agent B, that's a delegation event with its own record, not an implicit credential handoff nobody logs.
Zhu and Wang's paper on intent-governed tool authorization pushes this one step further, describing agents that "can access tools broadly without fine-grained permission checking tied to the specific purpose or intent of a task." Their proposed fix scopes tool access not just to which agent is calling, but to what the agent is currently trying to do. A finance agent authorized to read expense reports for reconciliation shouldn't be able to use that same session to export the full ledger, even if the underlying credential technically permits it. Scope tracks intent, not just identity. That's a more advanced end state than most teams need to hit this quarter, but it's the direction the architecture points once identity is solved.
NIST made this a named, funded problem in February 2026
The AI Agent Standards Initiative was framed around agents that "can now work autonomously for hours, write and debug code, manage emails and calendars, and shop for goods." NIST's stated goal is to make sure agents can be "widely adopted with confidence" and "function securely on behalf of its users." The initiative rests on three pillars: industry-led standards and U.S. leadership, open-source agent protocols, and security and identity research. Identity and authorization wasn't a subsection of the third pillar. It shipped as its own concept paper within days of the initiative's launch.
That companion paper, Accelerating the Adoption of Software and AI Agent Identity and Authorization, states the stakes plainly: realizing the productivity gains agents promise "requires understanding the potential risks from giving AI agents access to diverse data sets, tools, and applications, and applying appropriate identification and authorization controls to mitigate these risks." That's a federal standards body saying, in writing, that access control is the gating factor on whether agent adoption is safe to scale, not model capability.
The paper's public-comment period closed in the spring, which means by now NIST has moved past the open-comment stage into whatever comes next in its standards pipeline. What matters for engineering leaders isn't the exact procedural stage. It's the shape of the questions NIST asked commenters to answer, because that shape is a self-audit checklist you can run against your own stack today:
- What are your current and planned agent use cases, and what does each one actually touch?
- What challenges does agent identity present that traditional software identity doesn't?
- Which existing IAM standards (OAuth, SPIFFE, OIDC, mTLS) already cover part of the gap, and which parts do they leave open?
- What controls exist for prompt injection specifically, and separately, for non-repudiation, the ability to prove after the fact which agent took which action?
If you can't answer the fourth question for your own systems today, that's the gap this post is about.
What a production-grade answer looks like
The research above converges on the same shape from three independent angles. Kodathala's aiAuthZ work argues for moving authorization off-host: don't trust the model's in-context judgment about who it's talking to, verify identity through a gateway the model can't talk its way around. Tallam's R2 argues for explicit, per-hop delegation: every agent-to-agent call is a logged authorization event, not an inherited credential. Uchibeke's pre-action authorization argues for a checkpoint before the tool call executes, not an access-control decision baked into the environment weeks earlier.
Put those three principles together and you get a recognizable architecture: cryptographic, workload-level identity (not a shared static secret) issued per agent; a standards-based delegation protocol that makes each hop an explicit, auditable event instead of an implicit credential handoff; and scoped, short-lived authorization grants issued per action rather than broad standing access. That combination maps closely onto existing workload-identity standards, cryptographic identity frameworks like SPIFFE paired with delegated, scoped authorization protocols like OAuth, extended for machine-to-machine and agent-to-agent contexts the way the IETF's WIMSE work aims to do.
The point isn't that any one company has fully solved this. It's that the pieces already exist as mature, standards-track technology. Nobody has to invent cryptographic workload identity from scratch to fix agent authorization. The gap isn't that the tools don't exist. It's that most agent orchestration layers were built fast, on shared credentials, before anyone asked the identity question at all. Teams are starting to reach for these standards specifically because they were designed for exactly this problem: proving what a piece of software is, and what it's allowed to do, without a human in the loop to vouch for it.
The diagram names the actual delta: not "more security," but a credential issuer that hands out different scopes to different agents, instead of one key that opens every door.
The adoption ladder for Monday morning
You don't need to stand up a full workload-identity platform this quarter. You need to stop the bleeding in the order that matters most.
- Audit first. Does every agent in your stack hold its own credential, or does it share one with its orchestrator or host container? If you can't answer this in an afternoon, that's your actual finding. (Tallam's R1.)
- Add one checkpoint. Pick the single highest-risk tool call in your system, the one that writes to production, sends money, or exposes PII, and move it behind an explicit pre-action authorization decision instead of relying on inferred context or environment-level access. (Uchibeke.)
- Make delegation explicit. Every time one agent invokes another, log it as its own event: which agent, which scope, which parent request. Implicit credential handoffs between agents are the exact pattern Tallam's R2 rules out.
- Track NIST's identity and authorization workstream as a procurement forcing function. When you evaluate an agent platform vendor, ask them directly which of NIST's feedback categories, current use cases, unique agent challenges, relevant IAM standards, prompt-injection and non-repudiation controls, they can answer in writing. A vendor with no answer has no architecture yet, only a demo.
- Pair identity with the audit trail you already owe yourself. Identity answers who was allowed to act. The audit log answers what actually happened. Neither is complete without the other: a perfectly scoped credential that leaves no record of how it was used is just a quieter version of the same blind spot.
The 38-to-100% refusal-rate spread from the aiAuthZ study is the number to keep in front of your team when this work loses a prioritization fight. That range is not a model-quality problem you'll patch with the next release. It's what happens when authorization is a judgment call the model makes in-context instead of a decision made by infrastructure the model can't argue with. Fix the architecture, and the refusal rate stops being the question that matters.
References
- Kodathala — aiAuthZ: Off-Host, Identity-Bound Authorization for AI Agents (arXiv 2607.05518)
- Tallam — Authorization Propagation in Multi-Agent AI Systems: Identity Governance as Infrastructure (arXiv 2605.05440)
- Uchibeke — Before the Tool Call: Deterministic Pre-Action Authorization for Autonomous AI Agents (arXiv 2603.20953)
- Zhu & Wang — Intent-Governed Tool Authorization for AI Agents (arXiv 2606.22916)
- NIST — Announcing the AI Agent Standards Initiative for Interoperable and Secure Innovation (Feb 2026)
- NIST NCCoE — Accelerating the Adoption of Software and AI Agent Identity and Authorization (Feb 2026, initial public draft)