Just-in-Time Access for AI Agents: How to Implement It

What just-in-time access means for an AI agent

Just-in-time access for an AI agent is permission granted at the moment the agent needs it, scoped to one integration and one kind of action, for a bounded window, and revoked without anyone having to remember to do it. The agent asks at runtime, a policy decides, every tool call is checked against the result, and the grant ends at its deadline or after a single call.

We covered the general case in Just-in-Time Access for Employees and AI Agents: why standing access keeps showing up in breach reports, how durations and approvals work, and what happens at the deadline. This article does not repeat that. It is about what changes when the requester is software: where the decision is taken, what an agent access policy has to contain, and how revocation works when there is no account to deprovision.

Why standing access is worse for an agent

The usual way an agent gets access is an API key pasted into its configuration. We described that pattern in MCP Governance: the key carries whatever its creator could do, it rarely expires, and nothing records what the agent did with it.

A person with standing access still has to decide to use it. An agent uses whatever it holds whenever its instructions, or the text it reads along the way, point it there. Its owner changes teams and the key keeps working. The project ends and the agent keeps running. Standing access on an agent is not a dormant permission. It is a permission attached to something that acts on it continuously, at machine speed, on inputs nobody reviews one by one.

Replacing standing access with runtime access decisions

The shift is about where the decision sits. With standing access, the decision is taken once, at setup, by whoever configured the agent, and every later call inherits it. With runtime access decisions, the decision is taken when the agent actually needs the access, against the policy as it stands at that moment, and each call is checked against the result.

In Lutril that decision happens in the MCP proxy. Agents connect to one MCP endpoint. When a tool call fails for lack of permission, the agent calls a tool named request_access with the integration, the scope (read or write), a reason, and optionally a duration in hours or a single-use flag. Here is what happens next.

When the policy says require approval, the request goes to an approver in Slack or Teams, and the agent is told to call request_access again once the request is decided. The approver picks the window on the card. For hour-scale windows, put the duration in the policy: auto-approved grants take the policy maximum or less, and single-use grants last one call.

Until a policy exists for an integration, just-in-time access is off for it and the default path applies: a read can auto-approve when the requester already holds the app with an eligible role, and every write goes to a human. Nothing changes until you author a policy, which is what makes it safe to roll out one integration at a time.

What an AI agent access policy contains

Policies are configured per application on the Policies page, and each one targets a single audience: employees or AI agents. An agent policy has the same shape as the employee version described in the general article. What differs is how each setting behaves when the requester is an agent.

Two settings on the agent itself complete the picture. Bindings in the Agent Registry are the agent's standing baseline: the integrations it holds without asking, optionally narrowed to a list of tools, and never beyond what its owner holds. The Single-use only switch makes every grant the agent obtains a one-call grant, unless the integration's policy allows standing access. A workable pattern is a short binding list, single-use only for agents that act rarely, and everything else behind request_access.

Four rules that only apply to agents

Agent policies run on the same engine as employee policies. Four rules exist on top, and each one closes a gap that would not exist for a person.

• An agent can never exceed its owner's access. The check runs before any grant lookup, so it covers auto-approval, pending requests, and the reuse of an existing grant. The same check applies when a binding is created. A denial is logged with the reason owner_no_access.
• The subject is the human driving the agent. Conditions such as department, HR status or outstanding training evaluate against that person, not against a service account with no attributes. A condition like "department is Engineering" therefore stops holding for the agent when it stops holding for the person.
• Read does not become write. Scope is matched exactly, so a policy for read never answers a request for write. Without a policy, every write request goes to a human approver.
• A grant can last exactly one call. A single-use grant is consumed by the first successful tool call. A failed call does not consume it. A safety expiry, ten minutes by default, removes it if the call never comes.

Worked example: an SRE agent during an incident

A common case: an on-call agent needs to read the runbook and update the incident ticket while an incident is open, and nothing should remain afterwards. The setup takes three decisions. The agent is registered with the on-call engineer as its owner, who holds Notion and Redmine. The AI agents policy on Notion auto-approves for the engineering department, with a four-hour maximum. The AI agents policy on Redmine auto-approves under the same condition, with a one-hour maximum, and the agent asks for single-use when it writes.

Read the log as a post-mortem would. The agent got read access to the runbook in two seconds, without paging anyone at two in the morning. It tried to reach an integration its owner does not hold and was refused, with the reason recorded. It got write access for exactly one ticket update, and that access was gone three seconds later. The Notion grant stopped working at its deadline, and the background job marked it expired on its next pass. Nobody filed a ticket to remove anything, and nobody had to remember.

This is the answer to the question security teams ask about SRE agents in production: time-limited authorization and automatic revocation are not two features to bolt together. They are one grant with an end built in.

How revocation works when there is no account to remove

For an employee, expiry means deprovisioning at the source: the seat, the group membership, the role. For an agent working through the proxy, there is often no seat to remove. The proxy makes the call with the connector your admin installed, and the grant is a record the proxy reads on each call. Revocation is the grant ceasing to be valid, which can happen four ways.

• Expiry. A grant past its deadline is not honoured on the next call. A background job then marks it expired and logs mcp.access.expired.
• Consumption. A single-use grant is marked consumed, with a timestamp, by its first successful call.
• Manual revoke. The agent's page in the registry lists its live grants with their expiry and a Revoke button. The next tool call under a revoked grant is denied.
• Suspension. Suspending or revoking the agent revokes all of its active grants and blocks its credentials. The kill switch takes effect on the agent's next call, within seconds.

What to ask any product that claims time-limited agent access

If you are comparing AI agent access control products, these questions separate runtime authorization from an expiry column in a database.

Just-in-time access for agents is not a separate discipline from just-in-time access for people. It is the same policy engine, with the subject swapped and four rules added, enforced at the point where an agent actually acts. If you want the employee side and the deadline mechanics, read the general article. If you want the proxy layer itself, read MCP Governance. The goal in both is the same: access that nobody renewed stops existing, on its own.