When someone changes roles inside the same company, the usual outcome is leaving with two stacked sets of access instead of one swapped for the other: the old permissions stay valid and the new ones pile on top. A role change comes with a process, an approval, and a date. Losing the old access, in most companies, comes with none of the three.
CyberArk's 2025 Identity Security Landscape report, built on responses from 2,600 security decision-makers at mid-size and large organizations, measured the same imbalance at a different scale: machine identities already outnumber human ones by more than 80 to 1 inside companies, and artificial intelligence is expected to be the single biggest source of new privileged identities in 2025. Even so, 68% of respondents admitted their organization lacks adequate identity controls for these technologies.
The link between the two facts is direct: an AI agent is born inheriting most of the access of whoever configured it. If that person already carries the usual excess of someone who has changed teams a few times, the agent inherits the same excess — except it now operates with it constantly, with nobody reviewing it afterward. For anyone deciding on security and AI adoption, that is the detail that tends to slip by: accumulated access is not a new problem created by AI, but AI reproduces it at a larger, faster scale.
The Access That Snowballs Over Time
The practice has a name in the identity security market: privilege creep. It happens because granting access solves a problem with a date and an owner attached — someone needs into a system today — while removing access solves no problem in the moment; it only reduces a risk that may never turn into an incident. The result, in any growing company, is the same asymmetry: organizations get good at granting and bad at revoking.
A Beyond Identity survey of 1,121 people in the United States, the United Kingdom, and Ireland, published in 2022, found that 83% of former employees could still log into accounts from a previous employer after leaving — not because anyone had decided to keep the access open, but because nobody had the explicit task of closing it. If that happens when someone leaves for good, it is reasonable to expect it happens even more often when someone simply switches teams, a situation where, to whoever administers access, nothing appears to have changed.
Varonis's 2025 State of Data Security Report measured the same residue from a different angle: 88% of organizations have accounts that are active but stalled — profiles that keep working access long after they stopped being used day to day. Each of those accounts corresponds to a permission someone granted for a specific reason, at a specific moment, and that keeps holding even after the reason is gone.
With AI agents, the same pattern repeats at higher speed. An agent built to support the finance team, for instance, usually inherits the profile of whoever configured it — including whatever that person accumulated from previous roles. Once other people on the team start using that same agent, or once its creator moves on to a different role, hardly anyone revisits what the agent can still see and do.
The result is an excess of privilege nobody deliberately granted: it simply was never taken away. And the longer an unnecessary permission stays active, the wider the window for someone to misuse it — a leaked credential, a misconfigured agent, or a bad actor all reach for exactly the access that was already sitting there, accumulated, waiting.
Machine identities already outnumber human identities by more than 80 to 1 inside organizations.
Reviews That Turn Into a Rubber Stamp
The most common answer is a periodic access review: once a year, the security team sends managers a spreadsheet to confirm whether each person still needs what they have. In practice, most managers approve everything without checking line by line — the list is long, the deadline is short, and nobody wants to be the manager who blocked a colleague's work by mistake.
Another common fix is group-based access: instead of configuring permissions person by person, a group gets created — "finance," "sales" — and everyone in that area inherits the same bundle. That solves the speed of onboarding new people, but it turns the group into an archive of everything that was ever granted to someone in it, for some reason, at some point. Leaving the area rarely removes the person from the group.
The third attempt is to log everything and review it later: monitor every action, keep every record, and trust that a future audit will catch whatever went too far. That works to reconstruct an incident after it already happened — not to prevent it from happening. A detailed log of what an AI agent did with access it should not have had is, at best, a late explanation.
None of these three fixes addresses the cause: they treat the symptom — too much access floating around — without touching the reason, which is the lack of a trigger to remove it. As long as the only action with a deadline and an owner is granting access, accumulation will keep being the path of least resistance.
What Has to Be in Place
An environment that actually solves privilege creep — for people and for the AI agents they create — depends on verifiable mechanisms, not good intentions.
Access defined by the current role, not by the sum of history. The permission profile comes from the job a person holds today and gets recalculated with every change: whoever switches roles gains the new bundle and loses the old one in the same move, instead of simply stacking both.
Layered scope for every AI agent. An agent does not automatically inherit everything its creator can access. It gets its own profile, defined by the task it performs — company, agent, personal, and session act as separate layers, and what holds in one does not leak into another without an explicit decision.
Human approval before any more sensitive access is granted. Requesting new access — for a person or for an agent — goes through someone who evaluates whether it fits the role in question, with the decision on record, rather than through a form any manager rubber-stamps without a look.
Reviews triggered by events, not by the calendar. A role change, someone leaving the company, or a shift in an agent's responsibility triggers an access review right away, instead of waiting for the next annual round, by which point the excess has already sat there for months.
An audit trail of who granted what, and when. Every grant, every revocation, and every approval get logged in a way anyone can query — for a person or for an agent, it takes minutes to answer where a given piece of access came from.
This is how Skyller was designed: access based on each person's role, layered scope for the agents a team creates, and approval with an audit trail as the default, not as an optional setting.
Less Idle Access, More Confidence
An environment where access reflects the current role, not the sum of everything someone ever had, shrinks what security teams call the exposure surface: if a credential leaks or an agent is misconfigured, the possible damage is the size of the role actually performed, not the size of everything accumulated over time.
The IT team also gets a fast answer to the question any audit asks: who can access what, today. Without a mechanism like this, that answer requires a project — pulling spreadsheets, cross-referencing systems, interviewing managers from every area. With an event-triggered audit trail, it becomes a query that takes minutes.
For people changing roles, the gain is speed without the side effect: new access arrives just as fast as it would otherwise, without needing to keep the old one "just in case" while the formal process catches up. And for the AI agents a team builds, the same logic applies: an agent with a well-defined scope can be reused by other people more safely, because what it can do is visible and bounded — not a pile of permissions nobody can trace back anymore.
Questions for the Next Access Review
- How many people today hold access from a role they already left behind? If answering that requires manually pulling records, the problem is not discipline — it is process: there is no trigger that automatically links a role change to an access change.
- When an AI agent is created, does it get its own profile, or does it inherit its creator's? If the answer is "inherits," every bit of excess that person already carries passes straight to the agent — and to whoever reuses it afterward.
- Does access review happen when something changes, or only once a year? A fixed calendar guarantees that wrong access stays active, on average, for half the interval between reviews.
- Does the audit trail show who granted each permission and when — or just that one exists? A trail that cannot answer "who authorized this" within minutes is not doing the job of a trail.
