AI agents don’t behave like human users. They’re non-deterministic programs that plan, call tools, and change behavior run-to-run. Treat them as “just another identity in IAM” and you get overpermissioned, opaque systems where a single prompt or bug can wipe a database or exfiltrate a tenant in seconds.

In this article we lay out:

• What the data says about adoption and use cases
• How agent authorization actually differs from human authorization
• Why non-determinism is the core challenge
• What good authorization principles still hold
• A blueprint for agent-safe authorization
  
  

How Quickly Are Agents Moving To Production?

Agents are no longer a niche experiment. McKinsey’s 2025 State of AI survey found 23% of organizations are scaling agentic AI systems in at least one function, and another 39% are experimenting.

We see even higher adoption in PwC’s 2025 AI Agent Survey: 79% of senior executives say AI agents are already in use, and 88% plan to increase AI budgets. Gartner expects up to 40% of enterprise applications to embed task-specific agents in 2026, up from 5% today. 

Where are early adopters putting agents to work?

• Knowledge work: research, summarization, competitive intel, report drafting
  
• Software engineering: code generation, refactors, test authoring, migration scripts
  
• Customer operations: support triage, agent-assist, self-service workflows
  
• Back-office operations: ticket routing, data extraction from documents, simple approvals

What Are The Risks Of Agents In Production?

We’re past “toy demos.” Authorization has to catch up as the risk surface grows with adoption. A recent synthesis of enterprise agent stats reports: 80% of organizations have seen applications act outside intended boundaries; 39% report unauthorized access incidents; 33% saw inappropriate handling of restricted data. 

Research from HBR found that only 6% of enterprises “fully trust” AI agents. Recent examples demonstrating why we should be cautious:

• Google’s Antigravity agentic development platform exfiltrated data via a prompt injection. A “poisoned” web page tricked Antigravity’s agent into harvesting credentials and code from a user’s local workspace, then exfiltrating them to a public logging site.
• Replit’s AI coding assistant ignored the user’s instruction not to change any code eleven times, fabricated test data, and deleted a live production database before admitting what it had done.
• The Shadow Escape “zero-click” exploit targeted major AI-agent platforms via their MCP connections. Malicious actors abused agent integrations to access organizational systems, extracting highly sensitive data including Social Security numbers and medical records, without user interaction or detection by traditional security tools.

None of these are edge cases. They’re what happens when non-deterministic systems get broad, static permissions.

What Makes Agent Authorization Different?

Agents break familiar permission assumptions: behavior, speed, reach, and how models hold together under autonomy. Non-determinism is the fault line.

Table 1: Summarizing the differences between human and agent authorization.

1. Non-Deterministic Behavior Breaks Static Permission Models

Permissions were already a problem: humans are routinely overpermissioned. Oso data shows more than 90% of users have permissions they never use. Even then, a human user is (relatively) predictable. You can map “support engineer” or “claims adjuster” to a stable set of actions and data scopes, then assign roles and review access periodically. But agents don’t work that way:

• Each run is effectively a new workflow synthesized on the fly.
  
• The same prompt can produce different tool plans and queries.
  
• Agents chain tools: today they call a ticket system and CRM; tomorrow, they also discover a file store and an internal API.

Static, manually curated roles assume you can enumerate behaviors in advance. With agents, you can’t. That’s the non-determinism problem: you can’t know exactly what the agent will try next, only the space of what it could do.

OWASP’s LLM Top 10 calls this out directly as “Excessive Agency”. This is where LLM-based systems are granted too much autonomy to act on external tools and data without tight guardrails. 

2. Machine-Speed Execution Turns Minor Mistakes Into Major Incidents

Humans operate on human time. A user clicking around the UI will trip some alerts before they download every S3 bucket.

Agents operate at machine speed:

• They can enumerate and read thousands of records in seconds.
  
• A bad plan like deleting “test” data that is actually production can execute before a human reviewer is able to react.
  
• When integrated via MCP, plugins, or internal tools, a single compromised agent can traverse multiple systems in one chain of calls.

3. Traditional OAuth-Based Authorization Fails Agents

OAuth’s assumptions break when agents act autonomously at scale:

• Scopes are too coarse. They can’t express task-level or resource-level constraints. Agents need dynamic, conditional access such as “read this record for this user for this task”, not blanket permissions.
• Tokens are too static. Once issued, tokens rarely adjust to behavior or context. If leaked or misused, an agent can operate unchecked until revocation, which is often manual and slow.
• No action-level audit. OAuth stops at token issuance. Security teams have no visibility into which tools the agent called, which data it touched, or how behavior changed over time.

The result: over-broad access, minimal oversight, and no way to impose real-time guardrails on non-deterministic systems.

What Stays The Same In Good Authorization Design?

Even as agents introduce non-determinism and machine-speed risk, the fundamentals of authorization still hold. Getting the basics right is more important than ever.

Least privilege remains the anchor: every actor, whether human or agent, should receive only the access required for the task at hand. What changes is enforcement. Instead of static, pre-provisioned roles, least privilege must apply at runtime, driven by context and the agent’s intended action.

Centralized policy also retains its value. A single, coherent model for “who can do what on which resource” is still the only way to maintain consistency and auditability across applications. Agents simply raise the stakes: policies must now account for tool use, workflows, and the user or process the agent represents.

Identity binding still matters. An agent’s actions must map back to a clear principal whether that is a user, a workflow, or a bounded service identity, so audit trails make sense. Those audit trails need to be complete. You need end-to-end traces of agent decisions and tool calls, plus the ability to replay and analyze incidents.

Separation of duties still applies. High-risk operations such as bulk writes, exports, policy changes should continue to require explicit checks or gated workflows, even when executed by an autonomous system.

How Do We Build Agent-Safe Authorization?

To safely run agents in production, InfoSec and engineering leaders need to design for behavior, not static permissions and pre-defined roles.

‍

Where Do We Go From Here?

AI agents are already in the critical path. They act faster than humans, behave in ways you can’t fully predict, and operate with privileges that can reshape entire systems in seconds. The window for “let’s see how this evolves” is closed. Teams need to redesign authorization for agents before incidents force the change.

If you’re building agents for production and need an authorization model that can keep up, talk to us about Oso for Agents. 

‍