An AI agent is given a token so it can pull records from a CRM for a one-hour task. The task finishes. The token does not. Nobody revokes it, because nobody is assigned to, and the next access review is scheduled for next quarter. For the weeks in between, that access is live, unused by the agent and unexamined by anyone.
This is not a failure of the review process. It is a mismatch between how access reviews were designed and how agents actually work.
Why periodic reviews fall behind with agents
Traditional access audits address a straightforward concern: does this user still require permission? When applied to human workers, this premise remains effective. Staff generally remain in defined roles over extended periods, meaning permission creep unfolds gradually enough that a scheduled audit captures most discrepancies.
Automated systems operate under an entirely different timeline. A developer might deploy an agent to handle a quick single-hour assignment, provision necessary permissions, and immediately shift focus elsewhere. The unrevoked CRM credentials mentioned earlier represent a standard occurrence rather than an exception. When an audit finally inspects those rights, the window of activity has long passed, leaving the audit to record historical data rather than prevent exposure.
Most organizations cannot even tell what their agents did: 68% cannot reliably separate agent activity from human activity in their logs, according to the Cloud Security Alliance.
This does not render periodic audits useless; regulatory bodies still demand them, and they serve as an important safeguard. Yet when applied to automated systems, an audit merely logs past permissions rather than actively governing real-time execution.
The case for deciding at the moment of use
The OpenID Foundation made a version of this argument in a paper published on October 12, A Protocol-Agnostic Threat Classification for Cross-Boundary AI Agent Authorization. Among the core threats it lists is access that outlives the task it was granted for. Its recommendations favor "authorization-time controls" such as scope discipline, preserving the intent of a request and automated cleanup, over detection after the fact. The paper also argues that treating an agent as if it were a human user is the common root of the failures it describes.
Federal guidance points in the same direction. NIST and CISA's report on protecting tokens and assertions, IR 8587, published in September, tells organizations to define and document token lifetimes, validation and revocation practices, and says those guidelines should apply when AI agents use signed tokens to reach systems, data, tools or APIs.
The risk of standing access is not theoretical. On October 8, incident response firm Asymmetric Security described a case in which an attacker stole the client secret of an OAuth application and used the app's own permissions to take data, read mail across dozens of mailboxes and leave ransom notes. Because the attacker signed in as the application rather than a user, the firm says the activity bypassed MFA, conditional access and risk detection. That case involved an automation app, not an AI agent, but the lesson carries over: a credential that holds broad, long-lived access is valuable to whoever holds it.
What controlling access at use looks like
In practice, the shift comes down to four habits:
- 1.Grant access for a task, not by default. An agent requests the access a specific task needs, and receives it only for that task.
- 2.Make credentials short-lived. Tokens expire when the task ends, so forgotten access closes on its own instead of waiting for someone to notice.
- 3.Check policy on every request. The decision to allow an action happens when the action is attempted, not only when the agent first authenticates.
- 4.Log every action against the agent and its owner. Each record should say which agent acted and which person or team is accountable for it, so the trail does not end at an anonymous machine identity.
Where to start
Trying to change every agent at once is unrealistic. A practical sequence:
- Start with the agents that carry the most risk. Prioritize those that touch customer data, production systems, payments or source code.
- Replace long-lived secrets first. Swap static keys and client secrets for short-lived, task-scoped tokens wherever the platform supports them.
- Assign an owner to every agent. Ownership is what makes attribution and cleanup possible.
- Keep reviews, but change their job. Use periodic reviews to confirm the real-time controls are working, not as the primary way access gets removed.
Takeaway
A review tells you what access existed. A decision at the moment of use determines what access happens. For human identities, the gap between the two was tolerable. For agents, it is where the risk lives. Put the control where the access is used, and let the review confirm it worked.
Sources
- OIDF publishes threat model for cross-boundary AI agents, OpenID Foundation, October 12, 2026
- A Protocol-Agnostic Threat Classification for Cross-Boundary AI Agent Authorization (full paper, PDF), OpenID Foundation, October 2026
- Protecting Tokens and Assertions from Forgery, Theft, and Misuse (NIST IR 8587), NIST and CISA, September 2026
- CISA and NIST Release Guidelines to Protect Federal Cloud Identity Systems from Token Theft, Forgery, and Misuse, CISA, September 15, 2026
- Extortion via OAuth Application, Asymmetric Security, October 8, 2026
- Cloud Security Alliance, Detecting Shadow AI Agents at the Non-Human Identity Perimeter