Why Agent Permissions Drift After You Ship

You provisioned the agent’s access carefully. A scoped API key, a specific database read role, maybe write access to one queue. Three months and forty tool integrations later, that same agent can touch six systems nobody explicitly granted it, because each new capability got bolted onto the same identity instead of provisioned as its own scoped grant. Nobody approved that expansion. It just accumulated, one PR at a time, the same way a human employee’s access accretes over years of role changes — except the agent’s access can widen in a single sprint, and nobody is running the quarterly access review that would have caught it on the human side.

This is permission drift, and it is quickly becoming the defining operational risk of agentic AI in the enterprise — not because anyone is being reckless, but because the tooling that manages human identity was never built for identities that provision themselves, multiply on demand, and change their own effective scope by picking up a new MCP tool. Recent survey data puts numbers on what most platform teams already sense: over 80% of organizations report their AI agents have already performed actions beyond their intended scope — accessing unauthorized systems, sharing data they shouldn’t have touched, or exposing credentials — and only 7% of organizations believe their existing controls could actually stop a compromised agent from acting maliciously. Non-human identities, agents included, now outnumber human identities by more than 80 to 1 inside a typical enterprise, and 78% of organizations have no documented policy for how those identities get created or retired. That’s not a compliance footnote. It’s an architecture gap.

Why Static Provisioning Breaks for Agents

Human identity and access management assumes a slow-moving world: an employee joins, gets a role, that role maps to a permission set, and access review happens on a quarterly or annual cadence. The model works because humans don’t spin up new instances of themselves, and their job function changes at the speed of an HR system, not a deploy pipeline.

Agents violate every one of those assumptions. A single orchestration framework can spawn dozens of ephemeral agent instances for a single workflow, each needing tool access for the duration of one task. A coding agent that starts with repo-read access picks up a deployment tool three sprints later because someone needed it for one release and never scoped it back down. A customer-support agent connected through an MCP gateway inherits every tool exposed by that gateway server, not just the three it actually calls — because most MCP implementations don’t do per-tool authorization, they authorize at the connection level. None of this is a single bad decision. It’s the compounding effect of provisioning agents like static service accounts in a system where the actual attack surface is dynamic and per-task.

The industry’s proposed answer is a shift from grant-time approval to continuous enforcement, sometimes framed as the AGENT model: Attest the agent’s identity and purpose, Grant only the named systems and actions required, Enclose that access to a time window and task scope, Notarize every action in an audit trail, and Terminate the grant when the task ends rather than letting it persist as a standing credential. The pattern that matters architecturally is default-deny: an agent is provisioned with zero effective access, and every capability is an explicit, time-boxed, task-scoped grant rather than a broad role assigned once and forgotten.

The MCP Gateway as the Enforcement Point

This is where MCP’s rapid enterprise adoption is forcing a governance layer that didn’t exist a year ago. Snowflake’s Cortex AI Gateway, launched in July 2026 by folding in its Natoma acquisition and partnering with seven identity vendors — 1Password, Aembit, Cyera, Linx Security, Okta, SailPoint, and Saviynt — is one of several signals that MCP gateways are crystallizing into infrastructure, not just protocol plumbing. The gateway enforces identity, policy, and audit at the individual tool-call level across more than 100 supported MCP servers, which is the granularity that actually matters: not “this agent can talk to this MCP server,” but “this agent can call this specific tool, with these parameters, in this time window.”

That distinction is the whole architectural point. A connection-level authorization model treats an MCP server as a single trust boundary — if the agent can reach the server, it can call anything the server exposes. A tool-call-level model treats each tool as its own boundary, so an agent scoped to “read customer order status” genuinely cannot call “issue refund” even though both live behind the same gateway. Most teams that deployed MCP servers in 2025 built the former by default, because it’s what the reference implementations made easy. Retrofitting the latter after agents are already in production is a much harder migration than building it in from the start.

Architecture Impact

What changes in system design? Agent identity moves from a static credential issued once to a dynamic, per-task grant issued and revoked by a policy enforcement point sitting in front of every tool call — typically an MCP gateway or equivalent proxy layer. Tool authorization moves from connection-level (can this agent reach this server) to call-level (can this agent invoke this specific tool with these arguments), which requires the gateway to understand tool schemas, not just network routes. Identity providers need a non-human identity lifecycle that mirrors human onboarding/offboarding but runs at deploy-pipeline speed rather than HR speed.

What new failure mode appears? Permission drift: an agent’s effective access silently exceeds its intended scope because capabilities accumulate through incremental changes (new tool added to a shared gateway config, a broader role reused for convenience) rather than through any single reviewed grant. Unlike a misconfigured firewall rule, this failure mode has no single point-in-time cause to audit — it’s the accumulated residue of many individually reasonable-looking changes, which is exactly why point-in-time access reviews miss it and continuous drift monitoring is required instead.

What enterprise teams should evaluate:

• Platform/infra teams: whether the MCP gateway enforces authorization at the tool-call level or only the connection level, and whether it logs every call with enough context to reconstruct intent, not just the API hit
• Security/IAM teams: whether the non-human identity lifecycle (provision, scope, rotate, retire) is automated and tied to the agent’s actual task lifecycle, or whether agent credentials are being issued like long-lived service accounts
• Application/agent teams: whether each agent’s tool grants are scoped to the narrowest set the current workflow needs, and whether there’s an automated process that flags grants unused for N days as candidates for revocation

Cost / latency / governance / reliability implications: A tool-call-level gateway adds a policy-check hop to every agent action — budget 5-20ms per call for a well-implemented in-memory policy engine, more if it’s a network round trip to a separate authorization service, which matters when a single agent task fans out into dozens of tool calls. The governance payoff is asymmetric to that cost: continuous audit trails at the tool-call level are what let a security team answer “what did this agent actually do” during an incident in minutes instead of days of log correlation, and that capability is increasingly what auditors and regulators are asking enterprises to demonstrate for agentic systems handling regulated data.

Implementation Guide

Start with an inventory, not a tool purchase. Before evaluating any gateway or identity platform, enumerate every agent currently running in production, what credentials each one holds, and what those credentials can actually reach — not what you intended them to reach, but what the underlying API keys, database roles, or service accounts permit today. Most teams are surprised by this exercise; the gap between intended and actual scope is usually the first concrete evidence of drift, and it’s the baseline you’ll measure improvement against.

The high-leverage starting point is putting a policy enforcement point in front of tool calls before you scale agent count, not after. If you’re early in MCP adoption, build or adopt a gateway that authorizes at the tool-call level from day one — retrofitting call-level authorization onto a fleet of agents that have been running with connection-level trust for a year is a much larger project, both technically and organizationally, because you have to first discover what each agent actually uses before you can safely narrow it. If you’re already past that point, treat the retrofit as its own initiative with its own timeline rather than a checkbox on a broader security project.

The common mistake is treating this as purely a security team problem and bolting on an approval workflow that adds friction without changing the underlying architecture. A human clicking “approve” on a broad standing grant doesn’t fix drift; it just adds a signature to the same over-permissioned model. The fix has to be architectural: default-deny provisioning, time-boxed grants tied to task lifecycle, and automated revocation — not a human in the loop rubber-stamping the status quo. Human approval belongs at the policy-definition layer (what categories of action require review) not at the per-grant layer (approving each individual agent’s access), which doesn’t scale past a handful of agents anyway.

You’ll know it’s working when you can answer two questions quickly and accurately: for any agent, exactly what it can currently do, and for any sensitive action, exactly which agents could have performed it. If either question requires manually cross-referencing multiple systems, the architecture isn’t there yet. A useful interim signal is tracking the ratio of granted permissions to permissions actually exercised over a rolling 30-day window — a large and growing gap between the two is drift accumulating in real time, and it’s visible well before it becomes an incident.

The 6-12 month maturity path for teams that get this right looks like: quarter one, inventory and instrument (know what agents have, log every tool call with intent context); quarter two, migrate to a call-level gateway and start issuing new agent access as time-boxed, task-scoped grants by default; by month six to nine, retire standing credentials for existing agents in favor of the same model, with automated revocation for unused grants; by month twelve, the non-human identity lifecycle is boring — provisioning and deprovisioning agent access is as automated and unremarkable as spinning up a container, and access reviews are continuous drift alerts rather than a quarterly spreadsheet exercise. Teams that stall usually stall at the retrofit step, because narrowing existing agents’ access requires confidence about what they actually use, and that confidence only comes from the instrumentation work in quarter one.

Sources

• AI agent over-permissioning: is your access model drifting too far?
• Research Shows AI Agents Are Outpacing Identity Security
• AI Agents Are Becoming Authorization Bypass Paths
• Authorization Propagation in Multi-Agent AI Systems: Identity Governance as Infrastructure
• Snowflake Launches Cortex AI Gateway and Advanced AI Security
• Snowflake’s Cortex AI Gateway Signals MCP Gateways Are Crystallizing as Infrastructure
• AI Agent Identity Management: A 2026 CISO Playbook