Intent? What Intent? Why JIT Falls Apart for AI Agents

One proposal keeps surfacing whenever teams work out how to give AI agents access to systems. It goes something like this:

• AI agents need access
• Standing access is dangerous, so we will give agents just-in-time access instead.
• An "engine" will reads the agent's intent, grant a scoped, short-lived credential for exactly that task, then revoke it when the task is done.
• No standing privilege. No long-lived keys. Problem solved.

It is a good idea on paper. It borrows the credibility of a control that genuinely works for humans, dresses it in the language of intent and autonomy, and lands in the part of a CISO's brain that has been burned by static credentials for twenty years.

It also does not survive contact with how agents actually run. Let me walk through why.

JIT Works for Humans for Reasons That Do Not Transfer

Just-in-time access earns its keep with human users. Let's take a look at a simple scenario:

• A developer needs production access to debug an incident.
• They request it.
• Someone approves it, or a policy does.
• They get an elevated role for two hours. It expires. The audit trail is clean.

Look at why that works, because none of the reasons hold for an agent.

• A human request is rare. A few times a day, not a few times a second.
• A human request is deliberate, the product of a person deciding they need something.
• A human request is reviewable, because there is time and a human in the chain who can be asked.
• A human request is accountable, because a named person owns the request and the consequences.

An agent's access pattern has none of those properties.

• It is not rare, it is constant.
• It is not deliberate, it is generated.
• It is not reviewable in any window that matters.
• And, it is accountable to a model, which is to say accountable to nothing.

JIT was designed around the human request. Take the human out, and you have kept the ceremony and lost the thing the ceremony was protecting.

Intent Is a String an Attacker Can Write

The whole model rests on one word: intent. Grant access based on what the agent intends to do.

But an agent's intent is not a fact. It is the probabilistic output of a language model. It is a sentence the model generated, shaped by the prompt, the context window, and whatever text the agent happened to read along the way.

So in effect, you are not authorizing a verified plan, you are authorizing a string. And strings can be written by attackers.

This is the entire mechanism of prompt injection.A coding agent reads a poisoned README. A research agent summarizes a malicious webpage. A support agent ingests a crafted ticket. The injected text becomes part of the agent's reasoning, and the agent's stated intent becomes whatever the attacker wanted it to be.

Now your intent-based engine does its job perfectly. It reads the manufactured intent, sees a coherent task, and issues a scoped credential for it. The control did not fail. The control worked exactly as designed, on behalf of the attacker.

This is the confused deputy problem with a fresh coat of paint. You have built a system whose explicit purpose is to grant access based on an input that the threat actor controls. Speeding that up and calling it intelligent does not make it a control. It makes it an automated door opener that asks the intruder where they would like to go.

You Did Not Shrink the Blast Radius. You Set a Timer.

Let's set the trust problem aside and grant, for a moment, that the intent is genuine. This idea still confuses two different things: time and reach.

JIT shrinks the window a credential exists. It does nothing to the reach of that credential while it exists. During the grant, the identity is fully live, with full permissions, with full blast radius. Everything an attacker could do with a standing credential, they can do with the just-in-time one. They just have to do it inside the window.

However, the window is built around an agent, and the agent operates in milliseconds. A human needs the two-hour grant because humans are slow, but an agent will read, decide, call ten tools, exfiltrate a dataset, and finish before the credential's short life is anywhere near over. Ephemeral access only reduces risk if the actor is slower than the expiry. Agents are the fastest actors you have ever put in front of your data.

So you have not reduced the blast radius. You have put a timer on a bomb that detonates faster than the timer counts down. The non-human identity problem is not removed by JIT. It is scheduled. The identity, the permissions, the reach, all still exist. They just exist on a clock the agent easily beats.

Who Is Approving? A Model Vouching for a Model.

Every JIT system needs an approver. For humans, that is a person or a policy with a person behind it. For an agent operating thousands of times an hour, chaining tools and spawning sub-agents, ask the simple question the pitch skips: who approves each grant?

If the answer is a human, it does not scale, and you know it does not scale. Nobody is going to sit in a microsecond approval loop clicking yes. Within a day every team will have rubber-stamped a blanket auto-approve, and you are back to standing access with extra steps and a worse audit trail.

If the answer is another model, look closely at what you have actually built. One LLM generates an intent. Another LLM evaluates that intent and decides whether to grant. Your access control is now a model vouching for a model. That is not a control. It is a quorum of guesses, both of them susceptible to the same injection, the same hallucination, the same confident wrongness. You have automated the approval and removed the only part of the human flow that was doing real work.

And the action tree makes it worse. Intent declared at the start of a task does not predict what the task becomes. Agents branch. They call tools that call other tools. They hand work to sub-agents you never see in the original request. The intent you approved was for step one. Steps two through forty wrote themselves.

When You Need the Audit Trail, It Is Already Gone

The cruelest part is what JIT does to investigation.

Something goes wrong. An agent did something it should not have, a dataset moved, a token reached a system it had no business reaching. You go to reconstruct it. What does an intent-based JIT system give you? A grant record. Agent requested access for stated intent, access granted, access revoked. Clean. Tidy. Almost useless.

It does not give you the chain that matters: which person deployed this agent, which agent made the call, which tool it invoked, which identity it borrowed, which action it took, which resource it touched. The grant log is not lineage. And the system's own design works against you, because ephemerality erases evidence as enthusiastically as it erases credentials. You revoked the token. Congratulations. You also revoked your ability to prove what it did.

You are left holding exactly what you were trying to avoid: an alert, a vanished credential, and no story.

The Real Answer Is Governing Identity, Not Trusting a Sentence

The instinct behind JIT is correct. Standing access for agents is dangerous, and long-lived static credentials are technical debt with a pulse. The error is the mechanism. You do not solve an identity problem by asking a model what it intends and metering the keys accordingly.

You solve it by governing the identity itself.

That means knowing every non-human identity an agent can use, who owns it, where its credentials live, and exactly what it can reach, before anything runs. It means full lineage from person to agent to tool to identity to action to resource, so an investigation is a query and not an archaeology dig. It means baselining what an identity actually does, in normal operation, and enforcing to that baseline, because behavior is verifiable in a way that declared intent never will be. A model can lie about what it intends. It cannot easily hide what it did, if you are watching the identity layer where the doing happens.

And it means progressing toward access that is ephemeral by architecture, not ephemeral by request. There is a real difference.

Workload identity federation binds short-lived credentials to a verified workload, with no key to steal and no engine to fool. That is ephemerality you can trust because it is enforced by the platform. "A robot mints itself a short-lived secret after explaining its plans" is ephemerality you are choosing to believe.

What to Do This Week

• Do not let a self-declared intent become an authorization decision. Anything an attacker can write through the prompt is not a control input.
• Map your agents to real identities first. Before you meter access, know what the agent can reach today and tie every credential to a human owner.
• Baseline behavior, then enforce to it. What an identity normally does is a defensible signal. What an agent says it will do is not.
• Demand lineage from anything you buy. If a tool cannot reconstruct person to agent to tool to identity to action to resource, it cannot help you during the incident, which is the only time it matters.
• Move toward ephemeral by design. Workload-bound, federated, short-lived credentials beat any system that issues keys on the strength of a sentence.

Just-in-time for agents looks right because it pattern-matches to a control that works. It is the right answer to a problem agents do not have, and the wrong answer to the one they do. The agentic identity problem is not solved by timing the credential. It is solved by governing the identity behind it.