Short answer: Yes, and in a typical deployment today it happens by default. When an agent receives broad API credentials at setup, those permissions persist indefinitely. Each new task may add scopes; nothing routinely removes them. The result is an agent that holds the union of everything it was ever granted, with no user-facing way to see, audit, or reverse what accumulated.
What does “accumulating permissions” actually look like?
Most AI agents get their access at setup: an API key or OAuth token is configured once, and the agent uses it for every subsequent task. The scope reflects what the first use case needed. Then the agent gets a second job. A third. Each one might require a slightly wider permission. The developer adds the new scope to unblock the pilot. Nobody goes back to remove the old one.
Microsoft’s security guidance from July 2026 names this exactly: “The fastest way to create long-term risk is granting broad Owner/Admin roles to unblock a pilot, then never coming back to refactor permissions once the workflow ‘works.’” The problem is not malice. It is inertia. Broad access is easier than precise access, and there is no forcing function that makes teams revisit what an agent holds once it is running.
Kovrr, a cyber risk firm writing about agent access patterns in September 2026, put it plainly: “Permissions are requested per task and granted per lifetime, and the difference between those two is where the exposure accumulates.” An agent that has run six different jobs over a year holds the union of what all six needed. A compromise at job six inherits the blast radius of jobs one through five as well.
Why do scopes grow but never shrink?
The standard authorization model was not designed for agents. SpruceID, writing on agent authorization in September 2026, explained the gap: “OAuth 2.0 grants access at the scope and API level. A token proves that a user authorized an application to act on their behalf, and it defines a broad category of permitted actions. What it does not support is saying: this agent may access exactly these three files, for exactly this purpose, for the next 72 hours, and only on behalf of this named principal.”
That granularity does not exist in the token. So developers approximate. They pick the closest available scope, often a superset of what the task actually requires, and move on. The agent now holds a permission that covers more than the task needed. Multiply that across a deployment with dozens of tasks, and the effective access surface is far wider than any single workflow ever justified.
The service account pattern makes it worse. SpruceID again: service accounts have permissions that “accrete over time as teams add scopes without removing old ones, so the average enterprise service account has far broader access than any single workflow requires. When an AI agent inherits a service account or uses an API key, it inherits both the access and the lack of attribution.”
There is also no widely adopted mechanism to trigger a permission review. Nobody asks the user whether the agent still needs what it held six months ago. The user often does not know what the agent holds at all.
Is token expiry the answer?
Short-lived tokens help with some attack scenarios, but they do not solve accumulation. Kovrr made this point clearly: “The identity industry has settled on an answer to agent permissions. Zero standing privileges, credentials issued at the moment of need, scoped to the task, expiring when it completes. The reasoning is sound and the architecture is coherent. Almost nobody has deployed it for non-human principals.”
The practical reason is that long-running tasks break short token windows. An agent mid-workflow either renews its credential repeatedly, which is standing access with extra machinery, or it fails halfway through. Most teams choose standing access and tell themselves the token scope is narrow enough.
There is also a more fundamental issue. Refresh tokens undo expiry. If a token automatically refreshes on use, it does not expire in any meaningful sense. The user never re-enters the decision. The agent just keeps going. The “expiry” becomes a detail in a spec, not a real boundary that makes the user look again at what the agent holds.
That is why AgentAdmit issues no refresh tokens at all: when a grant expires, the agent comes back to the person.
What actually tells you what an agent currently holds?
In the typical deployment, nothing. The API key is in an environment variable. The OAuth token is stored in a secrets manager. Neither surfaces to the user in a readable form. If the user wants to know what the agent can do, they have to find the original configuration and remember whether it has been updated since.
Kovrr’s advice on this is worth quoting directly: “Whether the grant is observable and whether revocation has been tested” matters more than theoretical duration. “A standing grant somebody can see and withdraw in minutes is a better position than an ephemeral system nobody has exercised.”
Observability is the precondition for any other control. You cannot scope what you cannot see. You cannot revoke what you cannot enumerate. The technical solutions, just-in-time credentials, ephemeral tokens, minimal scopes, are all inaccessible until you have a list of what an agent actually holds and under whose authority.
What does user-controlled authorization change?
User-mediated authorization addresses permission accumulation at the architecture level, not the policy level. Several design choices work together to make it structural rather than aspirational.
First, there is no expand-scope API. If an agent needs an additional permission, a new connection flow is required. The user goes back through the consent surface, selects the new scope alongside the existing ones, and approves explicitly. The agent cannot quietly acquire more access between user interactions.
Second, there are no refresh tokens. When the connection expires, it expires. The agent brings it back to the user for renewal. That renewal is also an opportunity to review: the user sees the current scope and either reauthorizes it or adjusts it. Expiry becomes a forcing function for a real review, not a box that gets ticked automatically.
Third, the existing-grants review step makes accumulation visible before a new grant lands. When a user tries to create a new connection to an app where they already have active grants, the consent surface blocks the flow with a review step. Every existing grant is listed. The user can revoke any of them, or acknowledge and continue. A new grant cannot be added without confirming what is already there.
Fourth, the user sets usage limits at the consent ceremony, recorded in the grant itself. An agent that bumps against a usage ceiling stops and comes back to the user. The user decides whether to increase the limit. The agent cannot raise its own ceiling.
Every request made with a valid token is logged against the connection: what the agent accessed, when, and whether the call was refused. The user sees the live signals on their own connection: when it was last used, how many calls it has made against the ceilings they set, and any recent alerts on it. The app owner holds the full per-call trail in the AgentAdmit dashboard, can export it at any time, and can surface it to the user inside the app, instead of leaving it buried in a server log nobody reads.
This is also where the question of self-approval matters. An architecture that lets an agent initiate its own authorization flow can also let it expand its own access. User-mediated delivery closes that path structurally: the credential is delivered to the human and the agent has no programmatic route to request more without going through the user.
FAQ
Can an AI agent request additional permissions without the user knowing?
In the typical deployment today, yes. API keys and OAuth tokens are configured once and the agent uses whatever they grant indefinitely. There is no widely adopted mechanism that alerts the user when a task requires a wider scope, or that blocks access until the user approves an expansion. User-mediated authorization changes this by requiring a new connection flow for any scope expansion. The agent cannot add permissions between user interactions.
How do you find out what permissions an AI agent currently holds?
In a typical deployment, you have to trace it manually: locate the credential, find the original grant, and check whether anything was changed since configuration. Most users have no access to that information. A user-controlled authorization layer addresses this by surfacing active connections and their exact scope in a dashboard the user can access directly. Revocation is self-serve inside the app, not a ticket to an IT team.
Is there a way to set a ceiling on what an agent can do before it even starts?
Yes, if the authorization architecture supports it. Usage limits authored at the consent ceremony and recorded in the grant mean the agent’s reach is bounded from day one. The user sets the ceiling; the agent cannot raise it. A call past the ceiling is refused and logged. The user then decides whether to authorize more, not the agent.
Does token expiry prevent permission accumulation?
Not by itself. Expiry limits how long a specific token is valid, but it does not narrow the scope or remove permissions that were added over time. If the token refreshes automatically, expiry does not meaningfully interrupt access either. What expiry can do, when combined with user-mediated re-authorization, is create a real review moment: the user sees the current scope and reauthorizes it or adjusts it. Expiry as a forcing function for review is different from expiry as a security control in isolation.
Learn more about the industry and research consensus on what AI agents should and should not hold, or read about how prompt injection turns wide access into an immediate attack surface.
AgentAdmit gives app owners and their users the tools to issue scoped, time-limited, user-revocable agent access and see exactly what each agent holds. Learn more at agentadmit.com.