For years, enterprise security teams have been comfortable thinking about access in terms of people, devices and applications.
An employee logs in. A service account connects to an application. An administrator receives privileged access. Policies determine what each identity can see and do.
AI agents are changing that model.
Unlike traditional software, an AI agent can interpret a goal, decide which tools it needs, access information, call APIs and take actions across multiple systems. The agent may be operating on behalf of a person, but it can make decisions and execute steps at a speed and scale that are difficult for humans to supervise manually.
That creates an important question for security leaders:
What exactly should an AI agent be allowed to do?
The answer cannot simply be "whatever the user can do."
NIST's recent work on software and AI agent identity and authorization highlights the need to address agent identification, authentication, authorization, auditing, delegation and human authorization as distinct security concerns. NIST
For security leaders, this means treating AI-agent permissions as an enterprise identity and governance problem, not simply an AI implementation detail.
AI Agents Are Becoming Enterprise Identities
One of the easiest mistakes is to treat an AI agent as just another application feature.
That becomes problematic when the agent can interact with enterprise resources.
An agent might:
• Read customer records
• Search internal documents
• Access email or calendars
• Query databases
• Create or modify tickets
• Call external APIs
• Write code
• Deploy applications
• Trigger business workflows
• Make decisions on behalf of users
At that point, the agent is no longer simply producing an answer. It is operating within an environment of permissions.
ISC2 has described this as one of the important challenges of agentic AI: agents blur the boundary between technical assets and digital identities because they interact with files, databases and collaboration platforms in ways that resemble human users. ISC2
Security leaders therefore need to ask a basic question for every deployed agent:
Does this agent have its own identity, or is it borrowing someone else's?
Borrowing human credentials creates an accountability problem. If an agent uses an employee's credentials, it becomes much harder to determine whether a particular action was performed directly by the employee, automatically by the agent, or because the agent interpreted a request differently than expected.
NIST has specifically warned about credential sharing and recommends treating agents as first-class entities with unique identifiers, credentials and associated entitlements. NIST
Least Privilege Still Matters, But the Model Has to Change
Least privilege is not a new security concept.
The principle is straightforward: an identity should receive only the minimum access necessary to perform its function. NIST Computer Security Resource Center
The challenge with AI agents is that their behavior can be more dynamic than traditional software.
A conventional application may have a relatively predictable set of operations. An AI agent may receive a high-level objective and determine which tools, data sources and APIs it needs along the way.
That makes broad permissions particularly dangerous.
Imagine an agent that has access to:
• A CRM
• Internal files
• Email
• A financial system
• Customer information
• Software repositories
The agent may technically need access to several of these systems, but it should not automatically receive unrestricted access to everything simply because the user who initiated the task has that access.
NIST's current agent identity work specifically raises the question of how organizations can establish least privilege when an agent's required actions may not be completely predictable at deployment time.
For security leaders, this points toward a more granular model.
Instead of asking:
"What can this agent access?"
Ask:
"What does this agent need to do right now, and what is the minimum authority required to accomplish that task?"
Authorization Should Become More Contextual
Traditional authorization often happens around a relatively simple decision:
Identity + role + resource = access decision
Agentic systems introduce additional context.
For example:
• Who initiated the task?
• What is the agent trying to accomplish?
• Which tool is it attempting to use?
• What data will the action expose?
• Is the action read-only or does it change something?
• Is the action inside the user's original intent?
• Is the requested privilege appropriate for the current task?
• Does the action cross a security or organizational boundary?
NIST's September 2026 summary of feedback on agent identity and authorization found strong support for more dynamic, context-aware authorization. The feedback also highlighted concerns about agents accumulating permissions as tasks are chained across multiple agents and systems. NIST Pages
This is where Zero Trust principles become particularly relevant.
Instead of authorizing an agent once and trusting it throughout an entire workflow, organizations can move toward continuous evaluation of authorization at the point where an action is requested.
That does not necessarily mean building an entirely new security architecture.
It means applying existing identity and access principles more dynamically.
Human Approval Still Has a Role
There is understandable pressure to make AI agents completely autonomous.
But autonomy should not automatically mean unrestricted authority.
Some actions carry substantially more risk than others.
Reading a public document is very different from:
• Deleting production data
• Transferring money
• Changing access permissions
• Deploying production code
• Sending sensitive information externally
• Modifying security controls
Security leaders should identify actions where human approval remains appropriate.
The goal is not to put a human in the middle of every agent action. That would eliminate much of the value of automation.
Instead, organizations can establish risk-based approval thresholds.
Low-risk actions can be automated.
Medium-risk actions can require additional policy checks.
High-impact actions can require explicit human authorization.
This approach allows organizations to maintain automation while preserving accountability for consequential decisions.
Permissions Need to Follow the Task
Another important consideration is delegated authority.
An agent may be acting on behalf of a user. That does not mean it should inherit every permission available to that user.
The authority granted to the agent should be constrained by the purpose of the task.
For example, if an employee asks an agent to prepare a sales report, the agent might need permission to read specific CRM records and reporting data.
It should not automatically receive permission to:
• Delete customer records
• Change billing information
• Modify user accounts
• Export the entire customer database
The difference is subtle but important.
User authority and agent authority should not necessarily be identical.
NIST's recent agentic AI work refers to this concept through delegated rights, task-scoped authorization and authorization attenuation, where downstream agents receive narrower permissions than the authority from which they were delegated. NIST Pages
Security Leaders Also Need Better Visibility
Permissions are only useful when organizations know what has been granted.
As enterprises deploy more agents, security teams will need visibility into:
• Which agents exist
• Who owns them
• What identities they use
• Which systems they can access
• Which tools they can call
• What permissions they currently have
• Who authorized those permissions
• How often permissions are used
• What actions the agents perform
• When permissions should expire
This becomes especially important because AI agents may be created dynamically or exist only for a limited period.
NIST's recent analysis of stakeholder feedback notes that the scale and potentially ephemeral nature of agents can create significant challenges around issuing, managing and auditing identities and credentials. NIST Pages
For security teams, this suggests that an AI-agent inventory should eventually become part of normal identity governance.
Logging Should Capture More Than the Login
Traditional security logs often answer questions such as:
Who logged in?
For AI agents, that is not enough.
Security teams increasingly need to understand:
• Which agent acted?
• On whose behalf?
• What task was it performing?
• Which tool did it use?
• What information did it access?
• What authorization allowed the action?
• What did the agent actually do?
• Was human approval involved?
• Did the agent deviate from the expected workflow?
This level of visibility becomes particularly important when investigating incidents.
If an agent makes an unexpected change, security teams need enough evidence to reconstruct the decision and authorization chain.
NIST's agent identity work explicitly identifies auditing and non-repudiation as areas requiring attention, including the ability to connect agent actions back to human authorization. NCCoE
Prompt Security Is Not a Substitute for Access Control
Another important distinction is between controlling what an AI model is instructed to do and controlling what it is technically allowed to do.
Prompt instructions might tell an agent:
"Only access customer information necessary for this task."
But that instruction should not be the only security control.
If the underlying identity has unrestricted access to a database, a prompt does not create a reliable authorization boundary.
Technical permissions should enforce the boundary.
This becomes particularly important in the presence of prompt injection and other attacks that attempt to influence agent behavior. NIST's agent identity project specifically considers prompt injection alongside identification, authorization and auditing because these controls need to work together. NCCoE
A secure architecture therefore assumes that an agent's instructions can sometimes be manipulated and ensures that technical authorization controls limit the resulting impact.
A Practical Checklist for Security Leaders
Organizations preparing for broader AI-agent adoption can start with a relatively straightforward set of questions:
Inventory the agents
Identify which AI agents are already operating across the organization, including agents introduced by business teams.Give agents distinct identities
Avoid shared human credentials wherever possible. Establish accountability for agent actions.Map permissions
Document which applications, APIs, data sources and tools each agent can access.Reduce standing privileges
Use short-lived or task-specific authorization where practical instead of permanent broad access.Separate read and write capabilities
An agent that needs to read information may not need permission to modify it.Define high-risk actions
Determine which actions require additional controls or human approval.Monitor agent behavior
Compare what an agent actually does with what it was expected to do.Build rapid revocation
If an agent behaves unexpectedly or its credentials are compromised, security teams need a fast way to disable its authority.Connect agent activity to existing security operations
Agent identities, authorization events and anomalous behavior should be visible to the teams responsible for detection and response.Review permissions regularly
Agent permissions should not become permanent simply because they were appropriate when the agent was first deployed.
The Bigger Shift: From User-Centric IAM to Human and Machine Authority
AI agents are not eliminating the principles that have governed identity and access management for decades.
They are exposing where those principles need to become more granular.
Security leaders should continue to rely on established foundations such as unique identity, authentication, authorization, least privilege, separation of duties, monitoring and accountability.
But those controls need to accommodate a new type of actor: software that can interpret instructions, interact with multiple systems and take autonomous actions.
The most important question is therefore not whether organizations should allow AI agents to operate.
The question is how much authority they should receive, under what conditions, and how quickly that authority can be changed or revoked.
The organizations that answer those questions early will be in a stronger position to scale agentic AI without allowing automation to quietly become a new source of excessive privilege.
AI agents may be autonomous, but their authority should never be undefined.
Top comments (0)