Just-in-time access
Just-in-time access is a security practice that grants privileges only at the moment they're needed, for a specific task and a limited time, and then removes them automatically. It replaces standing access, where an account holds elevated permissions all the time whether or not anyone is using them.
The idea comes from managing administrator and service accounts, but it fits AI agents well. Agents act at machine speed, and what they do next can be steered by text nobody fully controls. An agent with a permanent key to a billing system brings that power into every conversation, including the one where a prompt injection tries to use it.
How just-in-time access works
IBM's overview of just-in-time access describes three common models, which are often combined. In the first, access is brokered through a locked-down privileged account. The requester passes a check, uses the account for a set window, and the credential is usually rotated afterward.
The second model uses ephemeral accounts. A credential is created for one task and destroyed when the task ends, so there's no dormant account sitting around before or after. IBM notes this approach is increasingly used for service accounts and other non-human identities.
The third is temporary elevation. A normal account keeps its baseline permissions and gets specific extra privileges for a short period when it asks. That narrows each grant in scope as well as time.
Why standing access is risky for AI agents
The goal behind all three models is zero standing privileges: no identity holds elevated access except while it's actually using it. Least privilege limits what an identity can reach. Just-in-time access adds a second limit on when.
Agents make standing access worse in two ways. Permissions tend to pile up as new tools are added, and nobody goes back to remove the old ones. And because an agent's next step depends on what it reads, a credential that's always valid is always available to whatever input talks the agent into using it.
The Cloud Security Alliance argues that standing agent credentials make the damage from a compromise as large as it can be. They also make it hard to link any single action to an approved purpose.
How just-in-time access applies to agents
For an agent, the unit of access is the task. In the Cloud Security Alliance's Agentic Identity Governance Framework, an agent starts with a minimal identity and no working privileges. Before using a sensitive tool, it declares the task, the resources and tools it needs, and how long it needs them.
A policy engine checks that request against what the agent is approved to do and then issues a time-limited grant scoped to the task. Requests above a risk threshold go to a person for approval.
The model also leaves better evidence. The framework records three things for each significant action: the intent declared, the privilege granted and the privilege actually used. Comparing what an agent said it would do with what it did is the kind of check AI intent validation performs.
Common trade-offs with just-in-time access
Every grant is a round trip. Policy checks and token issuance add delay to the first sensitive call in a task. In voice, where any pause is audible, issuance has to be fast or fetched early once the customer's intent is clear.
Human approval has its own cost. Requests can sit waiting for hours, and approvers without business context often approve anyway so they don't block work. Requesters then ask for access before they need it, or for longer than the task requires.
The usual fix is proportionality. Auto-approve low-risk requests that are well understood and save human review for actions where it changes the outcome. Emergency break-glass paths need watching too, since routine use can quietly turn them into standing access.
Short lifetimes aren't a complete control on their own. A credential that lasts five minutes but reaches every system in a role can still do plenty of damage. Just-in-time access works best when grants are narrow as well as brief.
What just-in-time access means for customer service
Picture an agent handling a refund request. With just-in-time access, it gets a short-lived credential to read that customer's orders and, if policy allows, to refund up to a set limit. It doesn't hold a standing key to the whole payments system. When the conversation ends or the credential expires, the authority goes with it.
When the agent acts for a specific customer, the grant usually comes through delegated authorization. That way the temporary credential is limited by the customer's own rights as well as by the task.
For CX and ops teams, the practical shift is in how new capabilities get added. Each one becomes a rule for when a grant can be issued, rather than another permanent permission on a service account that nobody remembers to remove.
For a deeper dive, download Decagon's guide to agentic AI for customer experience.

