AI Agent Permission Creep: Detection and Quarterly Review Guide

What AI Agent Permission Creep Is

AI agent permission creep is the gradual expansion of an agent's tool access, API scopes, and system permissions beyond what its current task requires. It differs from human identity drift in a specific way: agent permissions are typically granted at integration time, when a developer registers a tool, connects an API, or configures an OAuth scope, and are rarely revisited as the agent's capabilities change.

OWASP's Top 10 for LLM Applications names this pattern Excessive Agency, describing it as excessive functionality, excessive permissions, or excessive autonomy relative to what a task actually requires. Unlike human accounts, which accumulate access through role changes and manager approvals that leave an audit trail, agent permissions often expand through code commits, tool additions, and quick integration fixes that are never logged as access events at all. This makes the drift harder to see using traditional identity and access management review cycles, which are built around human role assignments rather than machine tool invocations.

Why Traditional IAM Review Cycles Miss It

Standard entitlement review processes, including Microsoft Entra Access Reviews and similar recertification tools, are designed around human role assignments and typically exclude or deprioritize service principals and application identities. NIST SP 800-207 establishes least privilege and continuous verification as core zero trust principles that apply to non-human identities as well, but does not define agent-specific review mechanics.

The result is a structural gap: agent identities exist in IAM systems, but the review cadence and criteria applied to them are often copied from human processes without adaptation. Agent permissions are also frequently issued as a single shared API key or service account used across multiple agent instances or tasks, which collapses the granularity needed to determine which specific agent or workflow actually needs which scope. Without per-agent identity separation, a review can confirm that a credential exists and has broad access, but cannot determine whether any single agent function actually uses that access.

Detection Signals: Comparing Granted Scope to Actual Use

The most reliable detection method is not reviewing configuration alone, but comparing granted permissions against observed usage. This mirrors the approach AWS IAM Access Advisor takes for human and service roles: using last-accessed data to identify permissions that exist but are never invoked. Applied to AI agents, this means correlating each granted tool, scope, or API permission against tool-call logs over a defined observation window, typically the length of one review cycle.

Three categories of signal are useful:

• Unused scopes: permissions granted but never invoked in the observation period, indicating candidates for removal.
• Tool-call anomalies: invocations that fall outside expected parameters, frequency, or context for a given agent's defined task, which can indicate scope misuse or a misconfigured integration rather than legitimate need.
• Over-provisioned identities: agents or shared credentials whose granted permission set is broader than the union of all tools actually called across every task the identity supports.

None of these signals are visible from a static permissions list; all require runtime tool-call telemetry.

MCP and the Visibility Gap

The Model Context Protocol standardizes how AI models discover and invoke tools and resources through a client-server architecture with capability negotiation at connection time. This is a meaningful step toward structured tool exposure, but the base specification leaves fine-grained, auditable scope enforcement to individual server implementers rather than mandating it.

MCP's authorization guidance recommends OAuth 2.1 patterns, but whether a given MCP server implementation logs per-session tool exposure and historical invocation data varies by implementer and is not guaranteed by the protocol itself. In practice, this means teams adopting MCP cannot assume built-in usage analytics; they need to verify, for each server they connect to, whether tool-call history is captured in a form usable for a quarterly audit, and instrument logging externally where it is not.

Governance Considerations and Tradeoffs

No regulatory standard currently mandates a specific review cadence for AI agent permissions. Quarterly review is a common pattern borrowed from human IAM entitlement review practice, not an interval independently validated for agent identities in the sources reviewed here. Teams should treat quarterly as a reasonable starting cadence, adjustable based on how quickly agent tooling changes in their environment: agents under active development may need monthly review, while stable production agents may tolerate longer intervals.

A practical tradeoff exists between per-agent identity separation and operational overhead: splitting shared credentials into distinct per-workflow identities improves review granularity but increases the number of identities to manage. OWASP's Excessive Agency guidance also recommends human-approval checkpoints for high-impact or irreversible actions as an interim control, since static scope restriction alone cannot fully prevent misuse within a granted scope.