A CISO friend told me about an access review meeting they had a few months back where someone asked what a coding agent could reach. Nobody in the room knew the full answer. They could tell it had read access to the code repository; that part was on record. Somewhere along the way it had also picked up a connection to the ticketing system, then to a documentation tool, then to a data store nobody remembered approving. Three separate teams had each made one reasonable decision but none of them had talked to each other.
Authority drift is the term used when an AI agent’s permission footprint expands beyond what was originally approved, until nobody can account for everything it can reach. It’s the gap between what your security team thinks an agent can do, and what it actually can do.
Why authority drift doesn’t behave like overprovisioning
Security teams have a playbook for overprovisioned human users: access reviews, periodic re-certification, offboarding checklists. All of it assumes a person’s role changes slowly and predictably. But none of that maps cleanly onto agents, because an agent’s permission footprint doesn’t sit still long enough for a quarterly review to catch it.
It grows in three ways:
- Inheritance: a system inherits the access of whatever other systems it connects to
- Integration: a developer hotwires the agent into a new tool because it solves an immediate problem
- Convenience: broad access is faster to set up than scoped access, and nobody revisits the decision once the agent is working
Each expansion is understandable, and may even make sense in isolation. The trouble is that no process is designed to evaluate the aggregate, and the growth rate of each is exponential, so six months in, an agent’s actual permission footprint can bear little resemblance to whatever was approved on day one.
An example of authority drift in practice
In September 2025, state-sponsored attackers hijacked enterprise AI agent instances across 30 targets in defense, energy, and technology. The access accumulated by those agents allowed the attack to move incredibly quickly. Lateral movement that would normally take a skilled human attacker days happened in minutes, because the agents were already authorized to touch most of what the attackers needed.
A smaller-scale version of the same pattern appeared in CVE-2025-32711, a zero-click prompt injection in Microsoft 365 Copilot disclosed in June 2025. A single crafted email, ingested during routine summarization, extracted data from OneDrive, SharePoint, and Teams and exfiltrated it through a trusted Microsoft domain. No user interaction was needed, and there was no anomaly for signature-based tools to catch, because the agent used its own legitimate credentials to reach systems it had been granted access to over time.
What both incidents have in common are agents with more reach than the task justified.
AI agent permissions: The map that nobody is maintains
You can’t govern authority you can’t see, and most organizations don’t have a current picture of agent access topology: the tools, services, data sources, and accounts each agent can reach. Where that map exists at all, it’s usually a snapshot from the day the agent was approved. It doesn’t update when a developer adds an integration or when the agent’s data store gets merged into a larger one.
Gartner projects that by the end of 2026, 40% of enterprise applications will incorporate task-specific AI agents, up from under 5% in 2025. Each one of those is a live permission set that will look different in six months than it does today. Gallagher puts the share of large firms still lacking any AI risk framework at 43%. That tells me most organizations are scaling agent deployment faster than they’re building the muscle to track what those agents pick up along the way.
A static inventory taken once at deployment tells you almost nothing about an agent’s risk three months later. A more useful question at the moment is around the process: Who last checked what that agent can reach, and when?
Balancing constant management with current resources
The fix isn’t a one-time access review bolted onto agent deployment. An agent’s permission footprint needs to be treated as something that has to be re-justified on a regular cadence, in the same way a human account gets recertified, except faster, because an agent’s access can expand in weeks rather than years.
That takes three things working together:
- A current and live map of what each agent can reach, not what it was provisioned to reach
- Restricting agents to a fixed set of tools or models
- An enforcement point that can scope access without waiting for the next scheduled review
Skip that third piece and the first two just produce a more detailed report about a problem nobody can act on in time. Skip the first and the rest are impossible.
However, continuous mapping generates noise, and if every integration change triggers an alert, over-stretched security teams will not be able to keep up, and will start tuning those alerts out within a quarter. The systems that work well here are selective about what counts as authority drift worth flagging, not exhaustive about logging every change.
Securing agent permissions with Netskope
Netskope One AI Security continuously maps the access each AI agent holds across your environment, and flags when an agent’s footprint expands beyond its original task. The Netskope Zero Trust Engine enforces those access decisions at the point of the transaction, so scoping authority doesn’t depend on catching the drift during the next scheduled review.
The agent in that access review I mentioned eventually got its permissions scoped back down, but only because someone happened to ask the right question at the right meeting. Most organizations are relying on that kind of luck more than they’d like to admit.
See how Netskope One AI Security maps and governs agent permissions in your environment.
