Agent Permission Drift: Find and Remove Excess Access

AI agents accumulate access far faster than human users, because every new tool, connector, data source and debugging session tends to add a permission that nobody takes away. Permission drift is the growing gap between what an agent needs for its approved purpose and what it can actually do. It turns a prompt injection or a confused agent from a nuisance into a data breach, because the damage is bounded by effective access, not by intent. This guide gives platform, identity and AI security teams a repeatable process: define the purpose baseline, collect effective permissions from every layer, compare against observed use, triage and correct, then stop drift returning.

Key takeaways

Drift happens on several layers at once. Cloud IAM roles, OAuth scopes and consents, tool and MCP server lists, data source connections and reachable secrets each drift independently, and reviews that check only one layer miss the rest.
The baseline is the purpose, not the current state. Write down what the agent is for and what it must touch; compare effective access to that, not to last quarter's snapshot.
Usage data shows what can be cut. AWS IAM Access Analyzer unused access findings and Google Cloud role recommendations (90-day lookback) identify unused roles and permissions, but neither covers OAuth grants or tools.
Tool lists change at runtime. The MCP specification lets servers announce changed tool lists, so the agent's capability can grow without any IAM change.
Make correction cheap and expiry the default. Time-bound assignments, pipeline-managed permissions and a standard right-sizing change turn drift review from an audit project into routine hygiene.

What permission drift looks like in agents

OWASP's Top 10 for LLM Applications 2025 names the root causes of Excessive Agency (LLM06) as excessive functionality, excessive permissions and excessive autonomy. Drift is how agents arrive there over time. OWASP's own examples are drift stories: an extension trialled during development and dropped in favour of a better one but still available to the agent, and a read-only extension connecting with an identity that also holds update, insert and delete rights. For the risk itself, see the OWASP LLM Top 10 LLM06 Excessive Agency Guide; for the agent governance lifecycle, see the Identity Governance for AI Agents Guide.

Drift type	How it happens	Where to look	Example signal
Role and policy drift	Broad roles added to unblock a test, never removed; policies edited directly on the platform	Cloud IAM bindings, Kubernetes RBAC, database grants	Agent role has write or delete actions it never calls
Scope and consent drift	Incremental OAuth consent adds scopes; admin consent granted to speed a pilot	Entra oAuth2PermissionGrants and appRoleAssignments; Google Workspace and SaaS app grants	Mail.Send or Files.ReadWrite.All on an agent that summarises documents
Tool drift	New MCP servers or tools added; server-side tool lists change	Agent configuration, MCP client config, tool call logs	Tool calls to names absent from the approved toolset
Data source drift	New indexes, folders or tables connected for retrieval	RAG connectors, vector store sources, data platform grants	Retrieval from repositories outside the agent's business unit
Identity drift	Agent starts using a developer token, shared key or second service account	Secrets stores, runtime environment, sign-in logs	Two credentials authenticating for one agent
Reachability drift	Runtime can reach credentials it was never granted: metadata endpoints, mounted tokens, environment variables	Runtime network policy, pod specs, container images	Agent workload able to call the instance metadata service

Reachability drift is the one teams most often leave out of a permissions review, yet it can matter most. In the OpenAI and Hugging Face agent breach, evaluation agents reached Kubernetes service account tokens, instance role credentials from the metadata endpoint and a shared cluster-admin credential, none of which formed part of their intended access.

Step 1: define the purpose baseline

A drift review needs something to measure against. For each agent, record a short, reviewable baseline in the agent registry:

Purpose statement: one or two sentences on what the agent does and for whom.
Actions: the verbs it needs (read, draft, create ticket, send) and the ones it must never perform.
Resources: named data sources, accounts, projects and SaaS tenants, with sensitivity.
Execution context: whether it acts as itself (application permissions) or on behalf of a user (delegated permissions). OWASP LLM06 recommends executing extensions in the user's context with minimum scope where actions are taken for a user.
Approved tools: the tool and MCP server names, pinned versions where possible.
Sponsor and review date: who decides whether new access is justified.

Keep it short. A baseline that takes a day to write will not be updated when the agent changes, and an out-of-date baseline produces false drift alerts that teams learn to ignore.

Step 2: collect effective permissions from every layer

Layer	Source of truth	Usage data available	Gaps to plan for
AWS IAM	Role policies and trust policies for the agent's role	IAM Access Analyzer unused access findings: unused roles, unused access keys and passwords, unused service-level and action-level permissions	Action-level findings only cover services listed in IAM action last accessed information; unused access analysis is charged per role and user analysed
Google Cloud IAM	Allow policies granting roles to the agent's service account or agent principal	Role recommendations to remove or replace roles, based on up to 90 days of usage	Roles with conditions get no insights; ACLs and Kubernetes RBAC are not considered; new grants can take up to 15 days to produce insights
Microsoft Entra	Delegated grants (oAuth2PermissionGrants) and application permissions (appRoleAssignments) on the agent's service principal or agent identity	Sign-in and audit logs; Graph activity where collected	Exchange RBAC and Teams resource-specific consent are granted elsewhere and must be reviewed separately
SaaS and OAuth apps	Each platform's connected app and token inventory	Varies widely; often last-used date only	Many platforms do not show scope usage at all
Tools and MCP	Agent and MCP client configuration; tools/list responses	Tool call logs from the agent runtime or gateway	Server-side tool list changes, announced through notifications/tools/list_changed
Data sources	Retrieval connector configuration and data platform grants	Retrieval logs, query logs	Index-level permissions may not match source permissions; see the Permission-Aware RAG Guide
Runtime reachability	Network policy, pod and container specs, environment variables, mounted secrets	Egress logs, metadata service access logs	Usually not covered by any permission tool; needs configuration review

For AWS detail, see the IAM Access Analyzer Guide. On Google Cloud agent runtimes, note that Google documents that redeploying an Agent Engine agent creates a new principal, so grants made to the previous principal remain as residual access unless removed.

Step 3: compare granted, used and needed

Classify every permission into one of four buckets. The comparison works best as a simple table per agent, generated automatically where the data allows.

Granted	Used in window	In purpose baseline	Verdict	Action
Yes	Yes	Yes	Justified	Keep; confirm at next review
Yes	No	Yes	Dormant but expected (seasonal or rare action)	Keep with sponsor confirmation, or convert to just-in-time
Yes	No	No	Drift	Remove
Yes	Yes	No	Scope creep in use	Investigate first: either update the baseline with sponsor approval or remove and fix the workflow

The fourth row needs the most care. Use of an unapproved permission may be a legitimate feature the baseline missed, or it may be the agent being steered by injected instructions. Check the tool call and prompt logs around the first use before deciding.

Choose the usage window to match the agent's cycle. Google's recommender uses 90 days by default and allows 30 or 60 days at project level for faster results at some cost in accuracy. Agents that run month-end or quarter-end tasks need at least a full cycle in the window, or the review will remove access they genuinely need.

Step 4: triage and correct

Prioritise by blast radius: write, send, delete and privilege-granting permissions first; tenant-wide application permissions before delegated ones; production before non-production.
Right-size in a test path first: apply the reduced policy in a staging copy of the agent or run its evaluation suite against it. Where the platform supports a replacement role, as Google's recommender does, prefer replacing over hand-editing.
Apply through the pipeline: make the change in infrastructure as code or the access package, not directly on the platform, so the next deployment does not reintroduce the old permission.
Revoke consents completely: Microsoft documents that user consent grants cannot be revoked in the portal and need Graph or PowerShell, and that revoking does not stop the app from asking again; adjust consent settings or the app's requested permissions so drift does not return.
Remove tools and data sources: drop unapproved tools from the agent configuration and pin MCP servers or tool lists where the client supports it.
Close reachability gaps: block metadata endpoints from agent workloads, remove unneeded mounted tokens and keep secrets out of environment variables.
Keep a rollback: retain the previous policy version for a defined period so a removed permission can be restored quickly if a genuine use appears, and record the restore as a baseline update.

Step 5: stop drift returning

Expiring grants by default: in Microsoft Entra entitlement management, agent identities can receive access packages with an expiry date, and the sponsor is notified before expiry; with no action the assignment ends. Apply the same pattern with time-bound role bindings elsewhere.
Guardrails that cap the ceiling: Google Cloud's Principal Access Boundary can cap which resources an agent principal can reach regardless of its roles. Use equivalent organisation-level controls (service control policies, conditional access for workload identities) so drift has an upper bound.
Change control on tool lists: treat a new tool or MCP server like a new permission. The MCP specification says clients should log tool usage for audit and should treat tool annotations as untrusted unless they come from trusted servers.
Drift alerts: alert on new role bindings, new consent grants and new tool names for High-risk agents, routed to the sponsor.
Scheduled reconciliation: run steps 2 and 3 monthly for High-risk agents and quarterly for the rest.

For authorisation design that limits drift from the start, see the AI Agent Authorisation Guide.

A worked example

Consider a support triage agent approved six months ago to read new tickets, search the knowledge base and draft replies for a human to send. A drift review finds the following:

Role drift: its cloud role gained write access to the ticket database during a bulk re-tagging task in month two. Unused access findings show no writes since. Verdict: drift, remove.
Scope drift: its service principal holds an application permission to send mail as any user, added when a developer tested auto-replies. It has been used twice, both in testing. Verdict: drift; remove, and change the consent settings so the request cannot be re-approved informally.
Tool drift: a CRM MCP server was connected for a pilot, and its tool list has since grown from two read tools to nine, including record updates. Verdict: scope creep in use for the read tools; the sponsor approves two read tools into the baseline and the rest are removed and pinned.
Data source drift: the retrieval index now includes an engineering wiki space with internal incident write-ups. Verdict: outside purpose; remove the source and rebuild the index.
Reachability: the container can reach the instance metadata service. Verdict: block it and use the platform's workload identity instead.

None of these changes was malicious, and each made sense to the person who made it. Together they turned a drafting assistant into an agent that could alter records, email customers as anyone and read incident reports, which is exactly the excessive functionality, permissions and autonomy pattern OWASP describes.

Decision guidance

Application or delegated permissions: delegated permissions bound to the calling user drift less in impact, because the agent can never exceed the user. Use application permissions only for genuinely unattended tasks, and scope them to named resources.
Remove or convert to just-in-time: remove anything unused and outside the baseline. Convert rarely used but legitimate high-impact permissions to just-in-time elevation with approval, rather than leaving them standing.
Small estates: a quarterly manual review using the cloud providers' built-in unused access tools and a list of consented apps covers most risk.
Large estates: automate the collection into one dataset per agent, generate the comparison table, and send right-sizing changes as pull requests for the owning team to approve.

Measuring drift

Percentage of granted permissions unused in the review window, per agent and in aggregate.
Number of agents holding write, send or delete permissions outside their baseline.
Median time from drift detection to correction.
Percentage of agent access granted with an expiry date.
Count of tool calls to tools not in the approved list per month.

Common failure patterns

Reviewing cloud IAM only: OAuth scopes, tool lists and data connectors hold much of an agent's real capability and are missed.
Using the current state as the baseline: comparing this quarter to last quarter normalises drift that already happened.
Too short a usage window: removing month-end permissions after a 30-day window breaks the agent and teaches teams to resist reviews.
Fixing on the platform, not in code: the next deployment restores the removed permission.
Revoking consent without changing consent settings: the app asks again and a user approves it.
Ignoring what the runtime can reach: as the OpenAI and Hugging Face agent breach showed, credentials reachable from the runtime can exceed anything in the agent's role.

Framework mapping

Framework	Reference	Relevance
OWASP Top 10 for LLM Applications 2025	LLM06:2025 Excessive Agency	Excessive functionality, permissions and autonomy
NIST SP 800-53 Rev. 5	AC-6 Least Privilege; AC-6(7) Review of User Privileges; CM-2 Baseline Configuration; CM-3 Configuration Change Control	Least privilege, periodic privilege review, baselines and change control
NIST CSF 2.0	PR.AA-05; PR.PS-01	Reviewed least-privilege entitlements; configuration management
MITRE ATT&CK	T1098 Account Manipulation	Unauthorised permission additions look the same as drift; alert on both

Practitioner checklist

Write a purpose baseline for every High-risk agent: actions, resources, execution context, tools, sponsor.
Collect effective permissions from IAM, OAuth grants, tools, data sources and runtime reachability.
Enable AWS IAM Access Analyzer unused access and review Google Cloud role recommendations for agent identities.
Generate a granted, used and needed comparison per agent and act on every drift row.
Apply right-sizing through infrastructure as code or access packages, with a retained rollback version.
Revoke unneeded consent grants via Graph or PowerShell and tighten consent settings.
Pin approved tool lists and alert on calls to unknown tools.
Default new agent access to expiring assignments and cap the ceiling with organisation-level boundaries.

Agent Permission Drift: A Repeatable Process to Find and Remove Excess Access