AI Agent Permission Creep: The Authorization Debt Nobody Audits

Six months after a pilot, your customer data agent has write access to production databases it hasn't touched since week one. Nobody granted that access maliciously. Nobody revoked it either. This is AI agent permission creep, and it's now the leading cause of authorization failures in production agentic systems.

The pattern is straightforward: agents start with a minimal permission set, integrations expand ("just add read access to Salesforce for this one workflow"), and the tightening-after-deployment step gets deferred indefinitely. Unlike human IAM, where quarterly access reviews are at least nominally enforced, agent identities sit entirely outside most organizations' access review processes. The 2026 State of AI in Enterprise Infrastructure Security report (n=205 CISOs and security architects) found that 70% of organizations grant AI systems more access than a human in the same role. Organizations with over-privileged AI reported a 76% security incident rate versus 17% for teams enforcing least privilege — a 4.5x difference.

Why Drift Is Directional

Permission creep is asymmetric by nature: more access accumulates automatically; less access requires an explicit decision. Each integration adds a scope. Nobody writes a ticket to remove the scope from six months ago.

The organizational pressures that produce this are predictable:

Delivery pressure and "grant-first, tighten-later" culture. Teams under pressure to ship broad access upfront — to ensure the agent can handle all anticipated tasks — with genuine intentions to tighten afterwards. That tightening never happens because there's no forcing function.

The tooling gap. Most agent frameworks don't enforce tool-level permissions natively. Tools run with the same permissions as the agent process, inheriting all credentials. When you give an agent "access to Jira," that's the entire Jira instance with all scopes the Jira OAuth app was configured with — not "create tickets in project ABC."

Unclear ownership. Agents aren't assigned to human owners in most teams. When the person who deployed an agent changes roles or leaves, the agent continues running with standing privileges. There's no DRI transition trigger, no deprovisioning checklist.

OAuth's incremental authorization mechanics. Applications can request additional scopes at any time, presenting consent screens for expanded permissions. Users who already trust an application approve without scrutiny. Each grant expands the blast radius silently.

The result is predictable. IBM's 2025 AI security report found that 13% of organizations had already suffered breaches of AI models or applications, and 97% of those breached lacked proper AI access controls. Agent-involved breach incidents grew 340% year-over-year between 2024 and 2025.

The Authorization Bypass You Didn't Plan For

The most insidious form of permission creep isn't an agent with a bloated scope list — it's an agent being used as an authorization bypass path.

A documented 2025 incident: a marketing analytics agent at a technology company was given broad read access to customer data. A new hire with explicitly restricted permissions requested a customer churn analysis through the agent. The agent returned sensitive customer data the employee could never access directly. No misconfiguration. No policy violation. The agent's identity — not the employee's — was used for the data access decision.

This is OWASP LLM06:2025's "Excessive Agency" in practice. The agent had the right permissions for its legitimate workflows. But because those permissions exceeded what any single user should have, and because the agent didn't apply the requesting user's authorization context, it became an escalation path. Downstream systems authorized the request based on the agent's identity, which had far more access than the human asking.

The fix isn't removing agent access globally — it's enforcing authorization at the right layer. Operations should run in the user's context with minimal privileges, not under a generic high-privileged agent identity. In frameworks like LangGraph, this means binding the user identity in tool closures at creation time (not passing it as an LLM-accessible parameter) and relying on row-level security at the database layer as the final backstop.

The Audit Methodology for Orphaned Permissions

Non-human identities now outnumber human identities by 82:1 in average enterprise environments. 97% of NHIs carry excessive privileges. Only 38% of NHIs were active within the last nine months in audit data — meaning the majority of standing permissions belong to integrations nobody's actively using.

A practical audit runs in four stages:

Discovery and triage. Surface all connected applications and agent identities. Focus the inventory on autonomous agents specifically (they carry higher risk than passive OAuth integrations). Prioritize identities that are unsanctioned or have no formal governance record. In a representative enterprise environment, one discovery exercise surfaced 101 AI agents — 43 high-risk, 71 needing review, 2 with no formal record.

Permission mapping. Visualize scope risk — specifically look for read-write permissions like mail.readwrite or files.readwrite.all. Track which human user originally authorized each integration and whether that person is still at the organization. A token authorized by a departed employee with no revocation trigger is the canonical orphaned permission.

Historical usage analysis. For each agent-tool pairing, check when it was last exercised against production. Tools that haven't been called in 90 days are candidates for revocation. Tools that haven't been called since the pilot are almost certainly safe to remove. This is the same logic applied to human role certifications: "does this person still need this access for their current role?"

Review lifecycle. Implement a recurring cadence: weekly scope mapping review, bi-weekly token revocation for stale integrations, monthly inventory refresh. This isn't exotic — it's the same discipline applied to human IAM, adapted to the faster drift rate of agent identities.

Just-in-Time Capability Provisioning

Standing permissions are the problem. The structural solution is ephemeral, task-scoped credentials — provisioned at the moment of need, revoked automatically when the task completes.

The core JIT pattern for agents:

1. Agent requests elevation for a specific tool and scope
2. Authorization policy evaluates the request against context (task type, requesting user, time window)
3. Access is granted with a short TTL
4. Task executes under the scoped credential
5. Credential expires automatically; audit log captures the full interaction

A concrete example of this in a remediation workflow: a monitoring agent detects a misconfigured cloud bucket. A policy agent validates the violation. A remediation agent requests temporary write access scoped to that specific bucket. Upon approval, write access is granted for remediation only, then automatically revoked. Each agent in the chain had only what it needed for that specific operation.

For agents built on OAuth-based tool access (most production deployments), this maps directly to short-lived OAuth tokens scoped to a specific operation — tickets:create rather than jira:all, and only for the duration of the workflow. The MCP authorization specification (updated April 2026) formalized this with Resource Indicators (RFC 8707), which ensure tokens explicitly state their intended recipient, preventing token misuse across MCP servers.

The JIT model also solves the authorization bypass problem. If an agent must request a scoped, short-lived credential for each operation rather than holding standing access, the requesting user's context can be incorporated into the authorization decision at request time — not just once at agent deployment.

Agent Authorization Needs Quarterly Reviews

The access review parallel is exact: every agent identity should have a named human owner and an owning team. When the owner leaves, the agent is flagged and its permissions are reviewed — same as a DRI transition for service accounts. Agent permissions should be included in quarterly entitlement reviews alongside human roles.

ISACA's 2025 analysis identified why traditional IAM fails structurally for agents: static permissions don't reflect per-task context; legacy systems can't represent delegation chains where agents spawn sub-agents; there's no real-time revocation infrastructure for transient agent credentials. These are engineering problems, not organizational ones — they require purpose-built tooling.

But the organizational discipline is the prerequisite. Before you can implement JIT provisioning or real-time revocation, someone needs to own each agent identity and be accountable for its permission scope. Only 21% of organizations have a mature model for agent governance. 78% have no formal policies for creating or removing AI identities.

The access review template for agents mirrors the human equivalent:

• Does this agent still have an active owner?
• Are all granted tool-scopes still being exercised in production?
• Is the permission scope proportional to the current workflow — or does it reflect the pilot's requirements?
• Has the agent identity been included in security incident review processes?
• Are credentials rotated on a defined schedule?

When a reviewer decides an agent's access is no longer appropriate, it gets revoked through the same workflow as a human entitlement decision — not a separate process, not a one-off Slack request.

The Right Granularity for Tool Permissions

"Access to Jira" is not a permission. A permission is: "create tickets in project ABC, fields: {summary, description, severity}, severity constrained to {S1, S2, S3}, rate-limited to 5 tickets per minute."

This task + resource + action + constraint model is what OWASP means by "minimize functionality": extensions should contain only the specific capabilities required for legitimate functions. The blast radius of a compromised or misbehaving agent is bounded by the specificity of its tool permissions.

Practically, this means:

• Define a Tool Access Contract for every tool an agent can call: allowed actions, allowed resources, allowed scopes, required context parameters, rate limits, side-effect classification, and rollback expectations.
• Implement graduated containment rather than binary allow/deny: downgrade to read-only, disable specific high-risk tools, sandbox mode (proposal-only), quarantine (behind explicit approval gates), hard stop. A misbehaving agent doesn't need to be killed — it needs to be demoted.
• Enforce authorization in downstream systems, not the LLM itself. The model is not the security boundary. The API being called is the security boundary.

For multi-agent architectures and MCP-based deployments, the OPA (Open Policy Agent) gateway pattern provides policy-as-code enforcement: every request is validated and authorized before execution, destroy operations are explicitly blocked, and actions execute in short-lived isolated environments with mandatory cleanup.

The Compounding Risk of Agent Sprawl

The final dimension of this problem is velocity. Human identity sprawl accumulates slowly — through role changes, team transfers, project handoffs. Agent identity sprawl can compound instantly. A single OAuth authorization at the enterprise level can create multiple tokens across multiple services simultaneously, each with standing access until explicitly revoked.

The Drift-Salesforce incident (August 2025) illustrates the blast radius: stolen OAuth tokens from a single integration provided access to over 700 customer environments. The tokens operated outside standard security controls — bypassing SSO, MFA, and CASB — because they relied on delegated authorization rather than interactive login. An MCP server exposure the following year found 492 servers exposed to the internet with zero authentication, overprivileged credentials sitting in plaintext config files.

At machine-to-human identity ratios of 82:1, the attack surface from a single misconfigured agent token is categorically larger than a compromised human credential. The authorization discipline needs to match the scale.

The answer isn't to slow down agent deployment. It's to bring agent identities into the same first-class authorization treatment as human identities — quarterly reviews, JIT provisioning, named ownership, automatic revocation triggers — and to enforce the principle of least privilege at the tool level, not just the agent level.