Modern privileged access management solved a hard problem for humans: how to grant administrative power without the person carrying it all day. The answer was JIT — request, use, return, with an audit trail. For agents, that answer has not been applied yet.
What it looks like in practice
The design has three states, not one:
- At rest. The agent holds read permission within its operating scope, and nothing else. This is where it spends most of its time.
- Elevated. For a specific operation it requests write access — with a named resource, a reason derived from the task, and a short TTL measured in minutes.
- Revoked. The permission expires on its own when the task ends. Nobody has to remember to remove it.
The difference from simply granting permanent write access is that the exposure window stops being the service account's lifetime and becomes the operation's duration.
Who decides the elevation
This is where most implementations stall. If the agent itself decides when to elevate, the control is decorative — a poisoned context simply requests elevation along with everything else.
The decision has to live outside the model: in a policy evaluated by the orchestration layer, based on attributes the model does not control — which task, which user delegated it, which resource, what time. Policy as code in the tool-call path.
If the agent can self-elevate on instruction, you do not have JIT. You have standing permission with extra steps.
Where this is already possible
It is not theoretical. Cloud providers offer temporary elevation with approval and TTL, and a policy engine at the gateway can deny or allow by attribute before the call leaves. What is usually missing is not technology — it is the decision that the agent starts read-only, which is the part requiring discipline on day one of the project.
