AI agents are moving from identity problems to authority problems
Enterprise identity systems have spent decades answering foundational questions:
Who are you?
Can you prove it?
What resources are you permitted to access?
What roles or entitlements have been assigned to you?
Those questions remain essential for AI agents. NIST's recent work explicitly argues for building agentic systems on established identity and access-management foundations rather than abandoning them for entirely new security models. Its August guidance emphasizes unique identities for agents, appropriate credentials and entitlements, modern authorization standards, tighter scopes, and better token management.
But agentic systems change the operational context.
Traditional software usually follows execution paths designed in advance. Agents can reason about goals, acquire context, choose tools and take actions with limited human supervision. NIST's concept paper specifically focuses on architectures in which systems can dynamically acquire information and potentially take actions rather than merely generate responses.
That creates a question beyond simply recognizing the actor:
"What authority does this agent have for the action it is now attempting to perform?"
NIST does not present a finalized answer. It explicitly asks the question.
Among the authorization questions in its February concept paper is:
"What are the mechanisms for an agent to prove its authority to perform a specific action?"
The paper separately asks how organizations should handle delegation in "on behalf of" scenarios and how agent identity should be bound to human identity for human-in-the-loop authorization.
Those are not merely identity questions.
They are questions about authority.
Identity can be established while authority remains contextual
Consider an enterprise agent with a legitimate identity.
The agent may have:
- its own cryptographic credentials
- an established relationship to a user or service
- OAuth scopes
- assigned entitlements
- access to an approved API
- authorization to operate within a defined workflow
All of those controls can be legitimate and necessary.
Yet the consequential action may still require more context.
A healthcare scheduling agent might legitimately have access to appointment systems. But whether it may view, reschedule, cancel, or override a particular appointment may depend on the patient, workflow, delegated authority, organizational policy, current state, and the consequence of the requested change.
A financial-services agent might legitimately reach a payments interface. That does not mean every technically reachable payment is authorized merely because the agent possesses the credential needed to submit it.
This is not an argument against IAM.
It is an argument for preserving the difference between the inputs to an authorization decision and the specific decision being made.
NIST's current work makes that distinction increasingly visible. Its August analysis notes that modern authorization protocols do not automatically eliminate overly broad access and discusses mechanisms for more dynamic, granular authorization and for propagating authorization context through human and agentic call chains.
Delegation is where the problem becomes harder
Agentic systems frequently operate on behalf of someone else.
That may be:
a person,
a service account,
a department,
an organization,
or another agent.
Delegation therefore becomes central.
NIST's draft project identifies access delegation as a distinct area of interest, including linking specific user identities to agents so that organizations can maintain accountability for automated actions. It also explicitly asks how authority should be delegated in "on behalf of" scenarios.
The important question is not simply:
"Who owns this agent?"
It is:
"What did that principal actually authorize the agent to do?"
Those are different claims.
A user may authorize an agent to help manage travel.
That does not necessarily establish unrestricted authority to:
- book any flight
- spend any amount
- change an existing reservation
- accept contractual terms
- delegate the task to another agent
Likewise, an organization may authorize an AI system to assist with patient scheduling without authorizing every possible mutation of a patient's record.
Delegated authority therefore needs boundaries.
Those boundaries may include:
- permitted actions
- permitted targets
- permitted data
- monetary or operational thresholds
- time constraints
- workflow state
- required approvals
- conditions under which the authority no longer applies
The agent's identity tells the system which agent is acting.
Delegation helps establish whose authority the agent is exercising.
The remaining question is whether that authority covers the proposed action now.
Strong IAM remains the foundation
There is a temptation in emerging AI-security discussions to frame identity and authorization as competing approaches.
That would be a mistake.
NIST's August analysis is explicit that existing IAM practices remain foundational. It warns against credential sharing, static tokens, overly broad permissions and poorly designed human approval. It also points to OAuth, SPIFFE, short-lived credentials, Rich Authorization Requests and emerging mechanisms for carrying authorization context across call chains.
That matters because authorization assurance should not be understood as replacing identity.
It depends on it.
A high-quality authorization decision may need to consider:
Identity: Which agent is requesting the action?
Principal: On whose behalf is it acting?
Credential: What authenticated evidence supports those identities?
Entitlements: What access has already been granted?
Delegation: What authority was transferred to the agent?
Policy: What organizational rules apply?
Context: What is happening now?
Target: What system, record or resource will be affected?
Action: What consequence is actually being proposed?
Identity, credentials, roles, scopes and approvals are therefore not discarded.
They become inputs into a decision about the proposed consequence.
Human approval is not a complete substitute
One obvious response to uncertainty is to ask a person.
For some actions, that is entirely appropriate.
But NIST also identifies a limitation: excessive human-in-the-loop approval can create consent fatigue. Its August analysis compares repetitive approval requests to authentication fatigue, where users become conditioned to approve prompts simply to keep work moving.
This matters for agentic systems because a human click does not automatically answer every authority question.
What did the user see?
What exact action was approved?
Did execution change after approval?
Did the agent switch tools?
Was the approval for one transaction or an entire workflow?
Was another agent subsequently involved?
The design challenge is therefore not merely to put a person somewhere in the loop.
It is to determine what requires human authority, what can be delegated, and how that authority remains meaningful as the workflow proceeds.
Authority also needs evidence
NIST's questions do not end with execution.
Its concept paper asks how agent actions and intent can be logged in a tamper-proof and verifiable manner and how non-repudiation can bind agent actions back to human authorization. The proposed project's areas of interest also include linking actions to non-human identities and improving visibility into automated outcomes.
That creates a second enterprise problem.
It is not enough to ask:
"Was the action allowed?"
Organizations may later need to establish:
- which agent requested it
- who or what delegated authority
- what policy applied
- what relevant context was evaluated
- what decision was returned
- what system executed the action
- whether the resulting record can be trusted
An ordinary activity log may show that something happened.
Authorization evidence should help explain why the system permitted it to happen.
That distinction becomes particularly important in regulated workflows, where an organization may have to reconstruct a consequential decision after the model, policy, workflow state or surrounding systems have changed.
What NIST has not said
Precision matters here.
The February document is a draft concept paper, not a final standard or mandate. It was published to solicit stakeholder input and inform the scope and feasibility of a potential NCCoE demonstration effort. The project is currently listed as reviewing comments.
NIST has not endorsed BeaconGuard.
It has not mandated a specific authorization gateway.
It has not prescribed a single architecture for resolving agent authority.
And its exploration of agent identity and authorization should not be represented as proof that one commercial implementation is the required answer.
What NIST has done is frame a set of questions that enterprises will increasingly have to answer as AI agents take consequential actions.
Among them:
How does the agent prove authority for the specific action?
How is authority delegated when the agent acts on someone else's behalf?
How does that authority remain accountable to a human or organization?
How can actions and intent later be verified?
Those questions are significant on their own.
What enterprises should ask now
Organizations deploying agents into operational workflows do not need to wait for standards activity to finish before examining their architecture.
They can ask:
- Does each agent have a distinct identity, or is it borrowing a user's credentials?
- Can we identify the principal on whose behalf the agent is acting?
- Can we state exactly what authority was delegated?
- Does that authority apply to the particular action being proposed?
- Can policy and runtime context narrow or revoke that authority?
- Where is the authorization decision actually enforced?
- Can the agent bypass that enforcement path through another tool or interface?
- When human approval is required, is the approval tied to a meaningful action rather than a vague continuation prompt?
- Can we reconstruct the authorization decision independently after execution?
These questions move the conversation beyond whether an agent simply has credentials.
They ask whether the enterprise can explain and defend why the resulting action was authorized.
From agent identity to authorization assurance
BeaconGuard's interpretation of this emerging problem is authorization assurance.
The premise is straightforward:
An AI system may propose an action.
Identity, credentials, roles, entitlements, approvals, delegated authority, policy and context can all contribute to the decision.
But before a consequential action changes a real system, that action should be independently evaluated against the authority and policy that actually apply.
The resulting decision should then be enforced at the relevant execution boundary, with evidence sufficient to reconstruct what occurred.
That is not a replacement for IAM.
It is an architectural extension of the control problem that emerges once authenticated agents begin acting.
NIST's current work does not settle what that architecture will ultimately look like.
But the questions it is asking are increasingly difficult for enterprises to avoid.
Once an AI agent can act, identifying it is only the beginning.
The enterprise still has to answer:
"Who authorized this action?"
Sources and further reading
- NIST National Cybersecurity Center of Excellence - Accelerating the Adoption of Software and AI Agent Identity and Authorization Concept Paper - February 5, 2026. Draft concept paper examining identification, authentication, authorization, delegation, auditing, non-repudiation and related controls for software and AI agents.
- NIST Cybersecurity Insights - Back to the Future: Why Agentic AI Needs a Strong Identity Foundation - August 27, 2026 (Bill Fisher and Ryan Galluzzo). Discussion of credential sharing, static credentials, broad authorization, delegated rights, human-in-the-loop limitations and emerging authorization mechanisms for agentic systems.
- NIST - AI Agent Standards Initiative. NIST initiative covering agent security, authentication, identity infrastructure, interoperability and standards activity.
