Just-in-Time Consent is not Just-in-Time Access

A user approving an agent to act on their behalf is not the same as granting that agent least-privilege, task-scoped access to enterprise data.

“Just-in-time” has become common language in discussions about AI agents. Often, it describes an OAuth consent flow: a user approves an agent, the agent receives permission to act on the user’s behalf, and the agent authenticates downstream as that user.

That is useful. But it is not the same as just-in-time data access.

Consent can establish delegation. It does not necessarily establish the organization’s data-level authorization boundary.

Two different meanings of just-in-time

There are two separate questions:

May this agent act on behalf of this user?

And:

What may this agent access while acting on behalf of this user?

OAuth consent primarily addresses the first question. Just-in-time data access addresses the second.

In a consent-based impersonation flow:

The first flow is just-in-time consent. The second is just-in-time data access.

The problem with borrowing a human identity

It is tempting to let an agent authenticate as the user because the pattern is familiar. The user already has access, the target already understands the user’s permissions, and the agent can start working immediately.

But the agent is not actually the user. It is a separate software system that interprets instructions, selects tools, retrieves content, and takes actions at machine speed.

When the agent impersonates the user, it inherits the user’s authority rather than receiving only the authority required for the task. If the user has broad or administrative access, the agent may inherit all of it.

That is exactly the risk Anthropic calls out in its Zero Trust for AI Agents framework:

“If a human user has broad clearance, the agent impersonating them inherits that full data power.”

Anthropic describes this as a failure of the Least Agency principle and connects it to the confused deputy problem. A lower-privilege system, such as an email or web-scraping agent, can be manipulated into supplying instructions or content to a higher-privilege agent. The higher-privilege agent then uses the human’s valid authority to perform an action the organization never intended.

The credential is valid. The access is still wrong.

The problem is not necessarily that the agent bypassed authentication. The problem is that authentication and user consent were treated as sufficient authorization for every action available through the user’s identity. If you are interested in digging into this anti-pattern more, we have a deeper dive into both the Anthropic and OpenAI papers.

Consent opens the door. Policy defines the boundary.

A user can authorize an agent to act on their behalf. That authorization should not automatically give the agent everything the user could access.

Consent establishes delegation, but it does not define the organization’s data-level access policy. The organization still needs rules that determine what the delegation can unlock, such as:

• An agent may access approved analytical data for users in a specific group.
• Customer names may be unmasked only for an approved investigation.
• Sensitive data requests longer than one hour may require additional approval.

Those rules can determine whether a request should be:

• Approved within defined guardrails
• Granted temporarily
• Escalated for additional approval
• Denied

The user’s consent initiates the delegation. Policy defines its scope, duration, and data boundary.

This means the organization does not have to ask each user to evaluate every possible risk at the moment they authorize an agent. Instead, it defines the boundaries in advance and applies them consistently across users, agents, data, and tasks.

That gives the organization a stronger answer than:

“The user consented, so the agent can do whatever the user can do.”

The stronger answer is:

“The user consented to delegation, and policy determines what that delegation can unlock.”

The data plane is the critical enforcement point

Agent security requires controls in the runtime and at the resource being accessed.

The agent runtime may control:

• Which tools the agent can invoke
• Whether SQL or terminal access is available
• Which APIs it can call
• Whether human approval is required before a consequential action

Those controls are important. But they are not enough.

The final boundary must exist where the data is accessed. If a prompt is manipulated, a document contains malicious instructions, or the agent selects the wrong table, the data platform still needs to enforce what the agent is allowed to see.

That enforcement should apply to:

• Permissions
• Data objects
• Rows
• Columns
• User and agent context
• Temporary roles and grants

The query can come from a chat interface, a Python script, a terminal, an MCP server, a notebook, or an application. The enforcement should happen below the data connection, as close to the data as possible, using the native tools’ primitives.

A permitted tool call does not imply unrestricted data access.

This aligns with the guidance in both Anthropic’s Zero Trust for AI Agents and OpenAI’s Agent Security in the Enterprise. Both emphasize that a valid credential or tool connection does not authorize every action available through it. Agent actions need task-specific boundaries, independent enforcement, and auditability.

Questions to ask when evaluating an agentic JIT model

When a vendor describes its approach as just-in-time, ask:

1. What is just in time?
   Is it the user’s consent, the OAuth token, the tool invocation, or the actual data access?
2. Does the agent keep its own identity?
   Or does it become indistinguishable from the human user?
3. What happens if the user has broad or administrative access?
   Does the agent inherit all of it?
4. Can the organization constrain access to specific data objects?
   Can it apply row filtering, column masking, or intent-based restrictions?
5. Is access temporary at the data platform?
   Does the target receive a short-lived role or grant?
6. What happens when the task ends?
   Is the access automatically removed?
7. Can policy approve some requests automatically while routing others to review?
8. Does the audit trail identify both the human and the agent?
9. Can the organization enforce controls even when the agent is manipulated or selects the wrong tool?

If the answer to these questions is only “the user consented,” the system may provide delegated identity without providing governed, least-privilege data access.

What this means for Immuta

Immuta extends data provisioning to AI agents as first-class data consumers.

The model includes:

• Delegated authorization
• Separate human and agent identities
• Role vending
• Ephemeral provisioning
• Zero standing privileges
• Policy-driven data access
• Native enforcement in the target data platform
• Dual-identity audit

When an agent acts on behalf of a user, Immuta evaluates the relevant user, agent, data, and policy context, and then provisions the access. The agent does not receive a permanent copy of the user’s privileges, and it does not need to impersonate the user to access governed data.

Dynamic Review Flows

Immuta’s new Dynamic Review Flows provide a way to turn organizational rules into request-time decisions.

A flow can evaluate factors such as:

• The user and agent requesting access
• The data object and its sensitivity
• The intent of the action
• The duration
• Whether the request is delegated
• Other attributes or request details

Based on those conditions, the flow can:

• Approve access automatically
• Grant temporary access
• Route the request to a reviewer
• Deny the request

This allows governance teams to define what is automatically consentable at the company level, rather than relying only on the individual user’s OAuth consent.

The goal is not to replace OAuth consent, agent runtime security, or tool authorization. The goal is to connect those controls to a deterministic data-plane boundary.

Consent enables delegation. Dynamic Review Flows apply company policy to determine what that delegation can unlock.

That is why just-in-time consent is not the same thing as just-in-time access.