JIT access control is for humans. What should we have for AI agents?

Just-in-time access governs whether an agent gets in, and when. It says nothing about what the agent does once inside.

Earlier this year an AI coding agent ran terraform destroy on a production environment and wiped a live database—reportedly around 1.9 million rows—because it decided that was the logical next step. Here's the part worth sitting with: the agent had valid credentials and a legitimate session. Just-in-time access would have provisioned that session on demand and revoked it the second the task ended, flawlessly—and it would not have changed the outcome.

That's the thing about just-in-time (JIT) access. It was a genuinely good idea, built for a slower actor. In the previous post I argued that adding an agent shouldn't widen your attack surface—that's about how the agent connects. This one is about the next question: once it's in, through a perfectly scoped and perfectly ephemeral session, what governs what it actually does?

Isn't just-in-time access enough for AI agents?

TL;DR: JIT fixes standing privilege—whether and when access exists. It says nothing about what an agent does inside a valid, correctly-scoped, perfectly-ephemeral session. Zero standing privilege is necessary, not sufficient.

The industry has converged on one answer for agent access: kill standing privilege. Give the agent nothing durable—provision access just in time, scope it, expire it the moment the task is done. Every PAM vendor now publishes some version of that same line, and they're right. An agent holding a standing admin credential is a standing liability.

Look again at that terraform destroy. There was no standing-privilege problem: the session was valid, the scope was legitimate, and JIT would have revoked it seconds later. It did its entire job, and the data was still gone—because JIT governs whether an agent has access and when, never what it does once inside.

Alpacon does JIT too: sessions expire, nothing persists past their window, and agent sessions carry no standing privilege. The question this post is about is the layer above that—the one that governs the action itself.

Why doesn't 'grant then trust' hold up for AI agents?

TL;DR: JIT still trusts the session once access is granted. That trust assumed a human—slow enough to review, and predictable enough to trust. Agents are neither: they act at machine speed, and their behavior is open-ended by nature.

The old model grants access, then trusts the session. That worked because the thing inside was a person, and people are roughly predictable: they act for reasons they can state, at a pace you can review, within norms they're accountable to. "Once granted, the session is trusted" was a fair bet on a human.

Agents break the bet on two axes. The first is speed: one prompt fans out into dozens of tool calls before you've finished reading this sentence, so "just review what it does" fails the moment throughput passes what a person can watch.

The second is deeper: agents are unpredictable by design. The same prompt can take different paths; a model improvises, chases a goal down a route no operator would choose, and runs the next "logical" command—terraform destroy, rm -rf on the wrong path—without the hesitation or accountability that made trusting a human reasonable. The research is landing here too: a survey of autonomy-induced risk catalogs exactly these failure modes—irreversible tool chains, behavior that drifts from intent—and a 2026 paper, 'The End of Trust', argues the fix is to stop trusting the actor and evaluate the action instead: suspect-by-default.

So the model inverts. You can't extend "grant then trust" to an actor this fast and this open-ended. Identity used to be the control plane—authenticate the human, trust what follows. For agents it has to move to runtime, to the action itself, because that's the only place you can still see what's about to happen.

What has to bind to every agent action?

TL;DR: Two things. Scope is the static ceiling—which servers, which privileges. Intent is the per-action test—of everything in scope, is this specific action the one the session was opened to do?

In Alpacon, every action an agent takes belongs to a Work Session, and there is no out-of-session path. A session declares its scope and a required purpose up front—not an afterthought. That declared purpose is the session's intent, and Alpacon judges each action against it. The scope, separately, is a hard ceiling that sits above normal role permissions: a session without sudo in scope is denied sudo before any prompt appears, even for a superuser. Nothing the agent does can lift its own ceiling.

Scope alone is still coarse, though. "You may delete log files" is a scope, and it says yes to both of these:

✅  rm -rf /var/log/nginx/old/*     intent: rotate old nginx logs
⚠️  rm -rf /var/log/*              intent: unclear, far broader than the task

Same verb. One is the cleanup the session was opened for; the other quietly widens into every log on the box. Scope can't tell them apart—intent can. Alpacon judges each action against what the session declared it was for, so the first matches and the second gets flagged as diverging from the stated intent. The decision is about the action, not just the identity that holds the session. At RSAC 2026, 63% of teams said they couldn't enforce what an agent is allowed to do—that gap is exactly what binding intent to the action is built to close.

This isn't hypothetical. Here's a real command Alpacon caught, with the names and paths anonymized:

The credential could run that rm -rf; it was in scope. But it contradicted what the session had declared it was for, so intent scored it high-risk and denied it—the delete never ran. Scope would have allowed it. Intent didn't.

There's also a hole here that access control structurally can't see. A valid, correctly-scoped agent can be hijacked—through prompt injection or a poisoned tool result—into turning its own access against you; in one documented case, attackers planted fake error messages that got coding agents to run commands under the developer's own credentials. The credential is valid and the action can be in scope, so identity and perimeter checks see nothing wrong. Judging the action against the session's declared intent is what catches it.

How do you judge an action in real time without slowing the agent down?

TL;DR: A deterministic-first cascade. Rules and a behavioral baseline settle the obvious cases instantly; a model weighs in only on the genuinely ambiguous ones. Most actions never touch an LLM.

The worry with "AI judging commands" is that it's slow and unreliable. So the judgment is layered, cheapest-first. A rules layer clears the clearly-allowed and flags the clearly-forbidden immediately. A baseline layer compares the action to what this identity normally does. Only the narrow grey zone in between—where a rule can't settle it and it doesn't look routine—goes to a model, to weigh the action against the declared intent. Fast, deterministic checks handle the bulk; the expensive judgment is spent only where it's actually needed.

This isn't only classification—Alpacon can act on the judgment in real time. A command that breaks the rules or the session's envelope is denied before it reaches the host, and a borderline, high-risk one is routed to a human and held until someone approves or rejects it. You choose the posture: run the layer in monitor mode to score and record without blocking, or in enforce mode to act on the judgment live. One scope note: this governs the agent's path to your servers, not the agent's own reasoning. A prompt-injected model is a real risk, and a different one.

Who decides when the policy isn't sure?

TL;DR: Bounded autonomy. The vast majority of actions run untouched; the ambiguous or high-risk slice is escalated to a human—and a non-human can never approve its own escalation.

The point isn't to put a human behind every command. It's the opposite: let the agent run freely on everything clearly in-bounds, and pull a person in only for the slice that's genuinely ambiguous or high-risk. The design target is that around 95% of agent actions proceed without human involvement, and the remaining ~5% reach the right human—over Slack, a webhook, a mobile push—in seconds.

Two properties keep that safe. The escalation redeems out-of-band: approval comes back over a channel the agent doesn't control, never the one it's requesting from, so a service token can't quietly approve itself no matter how many tokens it holds. And agent-mode sessions are human-approved at creation in the first place—even a superuser opening one doesn't get to auto-activate it. Regulators are converging on the same requirement: the EU AI Act obliges high-risk AI systems to keep a human who can intervene or hit a stop. Bessemer has called targeted in-flight intervention the most underdeveloped area in AI-agent security—precisely the layer JIT was never built to cover.

What this earns you

TL;DR: Scoped, intent-aware, human-bounded autonomy—an agent you can let run, because the boundary binds to the action, not just to the door.

JIT was right for humans, and it's still part of the answer: Alpacon expires sessions and agent sessions hold no standing privilege. But zero standing privilege only decides whether an agent gets in. What it does once inside—bound to a declared scope and intent, judged in real time, with the ambiguous slice routed to a human—is the layer that actually governs an agent at machine speed.

There's one question left, and it's the one you get asked after something happens: can you prove what the agent did, under what intent, and who approved it? Every allow, escalate, and deny here becomes a record. Turning those records into an audit you can actually answer with is the next post.

FAQ

Is just-in-time access enough to secure AI agents? No—it's necessary but not sufficient. JIT and zero standing privilege remove durable, stealable access, which matters. But they govern only whether and when an agent has access, not what it does inside a valid, scoped, ephemeral session. A correctly JIT-provisioned session can still run one destructive command in the seconds it's live.

What's the difference between scope and intent for an AI agent? Scope is the static ceiling—which servers and which privileges a session may use. Intent is the per-action test—of everything in scope, is this specific action the one the session was opened to do? rm -rf on an old-logs path and rm -rf on every log share a scope but not an intent.

Does real-time command judgment slow the agent down? Most actions never reach a model. A deterministic rules-and-baseline layer settles the clearly-allowed and clearly-forbidden instantly, and only the ambiguous grey zone is weighed against declared intent. The costly judgment is spent only where it's needed.

Does a human have to approve everything an AI agent does? No. The design is bounded autonomy: the target is that roughly 95% of actions run untouched, and only the ambiguous or high-risk slice reaches a human—in seconds, over a channel the agent doesn't control. An agent can't approve its own escalation.

If you're putting agents on production infrastructure, this is the layer that decides whether a valid session is also a safe one.