The Agent Is Authenticated. The Action Still Isn't Authorized.
Agent identity answers who made the call. It doesn’t tell you who authorized this action, under which delegation, or whether that authority still made sense at execution time.
TL;DR
NIST’s current agent-identity work treats identification, authorization, auditing and non-repudiation as separate questions. That separation matters.
Authenticating an agent proves which software presented a credential. It doesn’t prove that this particular action was authorized by the original principal.
I think agent systems need an explicit action grant that survives delegation and can be checked at execution time.
A service receives a request from an AI agent. The workload identity is valid. The token checks out. The signature verifies. Every green light in the identity stack says the same thing: yes, this is the software it claims to be.
Then the agent wires $48,000 to a new vendor.
Then the question arrives one layer later: who authorized that action?
Authentication can answer who presented the credential. It can’t, by itself, tell you whether the human or organization behind the agent intended this payment, whether the amount remained inside the delegated task, whether another agent widened the instruction on the way down or whether the authority had already expired when the tool executed.
That distinction is becoming harder to ignore. NIST’s current concept work on software and AI agent identity asks separately about identification, authorization, auditing and non-repudiation. The separation is doing real work. Identity is part of the control problem. It isn’t the whole control plane.
The badge and the instruction are different objects
I’ve been circling this problem for a few weeks. In The Confused Deputy, the failure was provenance: authority can cross systems until the final service sees a legitimate actor but loses the legible connection to the original principal. In The Attenuating Chain, the problem was magnitude: delegated authority should shrink as it moves downstream rather than quietly growing.
There’s still a missing object between those two ideas.
Call it the action grant.
This isn’t a NIST term and I’m not proposing that the following schema is an existing standard. It’s the object I think an action-capable agent system needs if we want authorization to survive contact with autonomy.
grant_id: g-7f21
principal: user:steve
actor: agent:procurement-17
resource: vendor-payments
operation: create_payment
constraints:
max_amount_usd: 5000
approved_vendor_ids: [v-142, v-188]
valid_until: 2026-08-13T18:00:00Z
redelegation: attenuate_only
parent_grant: g-6b04
approval_evidence: approval:9a21
policy_version: procurement-prod-42
The identity system still matters. agent:procurement-17 needs to prove that it is actually the workload making the request. But authorization now has something else to evaluate: does this requested action fit the grant?
A $4,200 payment to v-142 may pass. A $48,000 payment doesn’t. A handoff to another agent can carry a narrower grant, but the child should not be able to invent a larger one. If the grant expired twelve seconds before execution, the identity can remain perfectly valid while the action fails authorization.
That’s the distinction I want the system to preserve.
NIST is separating the questions
In February, NIST’s National Cybersecurity Center of Excellence published a concept paper on applying identity standards and best practices to software and AI agents. The project page is currently in a comment-review stage. NIST is not announcing a completed agent-authorization standard here, and the concept paper should not be read as one.
What it does do is frame the problem usefully. NIST explicitly asks about identification, authorization, auditing and non-repudiation of AI agents, along with prompt-injection controls. Its AI Agent Standards Initiative separately lists agent authentication and identity infrastructure as research areas for secure human-agent and multi-agent interaction.
Then the May CAISI report on responses to NIST’s AI-agent-security RFI adds another useful constraint. The report says commenters broadly agreed that familiar cybersecurity principles remain relevant, but need adaptation for agent systems. That report summarizes stakeholder responses. It’s evidence of where the security community is converging, not a normative NIST requirement.I think the architectural implication is fairly direct: importing IAM unchanged gives us names and credentials. Autonomous systems force us to make delegated intent more machine-readable too.
A valid credential can carry a bad decision
OWASP’s 2026 Top 10 for Agentic Applications makes the practical side difficult to miss. Its agent-specific risks include tool misuse and identity and privilege abuse. The framework is concerned with agents that possess real tools, real privileges and enough autonomy to combine them in ways their operators did not intend.
Prompt injection makes the separation even clearer. OpenAI describes effective real-world prompt injection as increasingly resembling social engineering. That framing matters because a socially engineered employee can authenticate correctly while making a transaction they should never have approved. An agent can fail the same way, except the manipulated instruction may arrive through a webpage, email, document or tool result that entered its context.
If the defense is only “make sure the agent has a strong identity,” the attacker gets to use your identity system correctly.
The better question is what the receiving tool can prove about the action itself. Which principal created the authority? What operation was permitted? On which resource? Under what constraints? Could the agent redelegate it? What policy version evaluated it? What evidence tied the grant to an approval?
A log written afterward can help reconstruct some of that. An action grant makes the receiving system evaluate it before the irreversible thing happens.
The control plane is the binding
Traditional IAM often treats authentication and authorization as neighbors. The actor authenticates, policy looks at roles or scopes and the resource decides whether to allow the request. That model still works surprisingly well when the actor is a person clicking through a relatively short interaction.
Agents stretch the distance between intention and execution. One instruction can produce dozens of tool calls. A planner can create a subtask that another agent interprets. A downstream agent can operate in a different security domain. Persistent memory can alter later behavior. The credential at the final hop may say exactly who called while saying very little about the human decision that started the chain.
So I think the missing control plane is not another directory of agent identities. It is the binding between principal, actor, action and delegated limits, carried far enough down the chain that the system performing the action can still inspect it.
That binding also gives audit something better to work with. Instead of asking only “which agent called the payment API?” an incident reviewer can compare the executed action with the grant that was valid at that moment. Non-repudiation becomes more meaningful because the evidence is attached to a bounded authorization decision, not merely a signed identity event.
There are ugly implementation questions here. Grants can become too verbose. Policies can drift between issuance and execution. Cross-company systems may not agree on semantics. Revocation can race an agent already in flight. A cryptographically clean chain can still encode a terrible policy. None of this disappears because we gave the object a name.
But those are better problems than pretending a service account answers the whole question.
Identity is necessary. Authority is contextual.
The security industry spent years learning not to confuse authentication with authorization for humans. Agents make the distinction stranger because the software can plan, delegate and reinterpret a task after the original human interaction has ended.
That means the final authorization decision needs more than a trustworthy name. It needs a trustworthy account of what that name is allowed to do here, now, for this principal, under this grant.
An agent can be exactly who it says it is and still have no business taking the action in front of it.
That’s the control plane I think we are still missing.
Resources
NIST NCCoE, “Accelerating the Adoption of Software and Artificial Intelligence Agent Identity and Authorization” concept paper and project page: https://www.nccoe.nist.gov/projects/software-and-ai-agent-identity-and-authorization
NIST, “New Concept Paper on Identity and Authority of Software Agents,” February 5, 2026: https://www.nist.gov/news-events/news/2026/02/new-concept-paper-identity-and-authority-software-agents
NIST, “AI Agent Standards Initiative”: https://www.nist.gov/artificial-intelligence/ai-agent-standards-initiative
NIST, Riggs et al., “Summary Analysis of Responses to the Request for Information Regarding Security Considerations for AI Agents,” May 18, 2026: https://www.nist.gov/publications/summary-analysis-responses-request-information-regarding-security-considerations-ai
OWASP GenAI Security Project, “OWASP Top 10 for Agentic Applications for 2026”: https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/
OpenAI, “Designing AI agents to resist prompt injection,” March 11, 2026: https://openai.com/index/designing-agents-to-resist-prompt-injection/
Previously in this series: The Confused Deputy: AI Agents and Delegated Authority and The Attenuating Chain.