Just-in-Time access for agents is the practice of granting an AI agent the permissions a specific request requires, at the moment of the request, rather than assigning standing permissions to a role the agent holds continuously. Access is evaluated against live context at the request boundary and does not persist into the next task.
- Permissions granted per request rather than assigned standing to a role
- Evaluated at the request boundary against live context, then released
- Directly addresses excessive agency, which standing roles cause by design
- Extends established privileged-access practice to non-human principals
Why is Just-in-Time access for agents important?
Just-in-Time access matters because standing permissions are what turn a manipulated agent into a serious incident. An agent holding a role continuously carries that role's full access into every task, including the task an attacker steered it toward. Reducing the blast radius is more reliable than trying to prevent every manipulation, and permission scope is the lever that does it.
The standing-access problem is worse for agents than for people. A person with broad access uses a fraction of it and applies judgment about the rest. An agent uses whatever reaching the goal appears to require, and it does not know which of its permissions were granted for a different purpose. OWASP names the result excessive agency in the Top 10 for LLM Applications, and standing roles produce it by design rather than by misconfiguration.
The practice is not new in kind. Privileged access management established the pattern for human administrators years ago: elevate for a task, expire afterward. What is new is applying it to principals making thousands of requests a day, which requires evaluation fast enough to sit in the request path.
What is Just-in-Time access for agents?
Just-in-Time access is an authorization model in which permission is decided per request rather than held in advance. When an agent attempts an action, the access layer evaluates the request against context and issues only what that action needs, for as long as it needs it.
What makes that different from a role is where and when the decision happens. Evaluation sits at the request boundary, so it uses current context rather than the state at role-assignment time. The grant attaches to the action rather than to the agent, which means two requests from the same agent can receive different access. And the grant expires, so nothing accumulates across a session for an attacker to inherit later.
The context available at that boundary is what makes the model stronger than a static role. The identity of the agent and its author, the task being executed, the sensitivity of the target, the origin and timing of the request, and the posture of the agent itself are all knowable at that moment. None of them are knowable when a role is provisioned weeks earlier.
This is distinct from least privilege, which is a principle. Just-in-Time access is a mechanism for achieving it without an access review cycle nobody has capacity for.
Types of Just-in-Time access
Approaches divide by what triggers the grant and by how narrowly it is scoped.
Request-triggered grants evaluate each action as it arrives, giving the tightest scope and demanding the fastest evaluation. Session-triggered grants elevate for a bounded period once a task begins, which is simpler to implement and leaves a window open.
Approval-gated grants route the decision to a human before elevating, appropriate for high-consequence access and unworkable at volume. Policy-gated grants evaluate automatically against defined rules, which is what makes the model viable for agents at all.
By scope, resource-scoped grants limit access to a specific target rather than a class. Action-scoped grants limit which operations are permitted on that target – read but not write, query but not export. Context-scoped grants additionally condition on request attributes such as origin, timing, or the requesting user's own entitlement.
The strongest combination for agents is request-triggered, policy-gated, and action-scoped, since it needs no human in the path and leaves no standing privilege behind.
Just-in-Time access & Onyx
Just-in-Time access is one of three differentiators of the Onyx Secure AI Control Plane. Permissions are evaluated at the request boundary against live context rather than assigned at role level and left standing, so an agent receives the access a specific task requires and carries none of it into the next one.
The reason it sits alongside Steering as a differentiator is that the two solve the problem from opposite ends. Steering handles the action an agent should not take, by redirecting or modifying it. Just-in-Time access handles the access an agent should not hold, by never granting it in advance. Together they shrink both what an agent can attempt and what any attempt could reach, which is what makes broad deployment defensible rather than a matter of trusting the agents. Agent identity and access governance is where the model is operated.
