Who Decided the Agent Needed That Access?

Your buyer's AI agents are running on service accounts that were configured when someone got the demo working. The permissions haven't been revisited since. Three approaches to scoping agent access are circulating in buyer conversations right now: static role assignment(the current default), dynamic attribute-based scoping(policy evaluation at runtime), and JIT per-task elevation(short-lived credentials minted per task and expired when it ends). You'll encounter static roles in every existing deployment, ABAC in AWS-heavy environments where Cedar is gaining traction, and JIT in conversations with security teams who've already been briefed by CyberArk or HashiCorp. The sentence that earns you credibility in any of these conversations: "Who decided the agent needed this level of access for this specific task, and is that decision auditable?" Each approach answers that question. Two of them answer it well.

Static Role Assignment

What it is. The agent authenticates with a fixed set of permissions assigned at setup time and rarely changed.

What it does. The agent presents the same credential to every API call regardless of what it's actually doing. A billing agent that needs to read one invoice authenticates with Files.Read.All because that's the scope someone configured six months ago. People in the security community have started calling this "God Mode": an over-permissioned autonomous agent with de facto root access. The permission decision happened once, at configuration time, by whoever got the integration running. It's auditable only in the sense that you can find the admin console log entry or the Terraform commit. That entry tells you nothing about whether today's task warranted the access. CyberArk's 2026 research found 45% of organizations still apply the same privileged access controls to agents as they do to human identities. And agents are non-deterministic: the same prompt can produce different tool sequences, so you can't enumerate behaviors in advance, which means you can't assign a role that fits.

Where it comes from. Everywhere. This is the default in every major cloud platform and agentic framework. AWS Bedrock AgentCore assigns an execution IAM role at runtime creation; the role's permissions apply to all operations and can't be scoped per invocation. LangChain, AutoGen, CrewAI: same pattern. Developers reach for API keys and service accounts because the frameworks don't offer anything else.

What makes it distinct. The access decision is completely decoupled from the task. Whoever configured the role didn't know what the agent would be doing on any given Tuesday. They knew what it might do, so they granted everything it could need. A sales engineer two beers in would put it this way: the role is a guess, and it's always a generous one.

Dynamic Attribute-Based Scoping

What it is. Access decisions are evaluated at runtime against policy, using attributes of the agent, the resource, the action, and the environment.

What it does. Instead of asking "does this agent have the Customer Service role?" the system asks "does this agent, operating on behalf of this user, with this task context, have permission to read this specific record right now?" The policy engine evaluates that question every time the agent invokes a tool. A billing agent can read the invoice it needs without being able to read employee contracts, because the policy evaluates the specific resource against the specific request. Permissions don't persist between invocations.

Where it comes from. The conceptual foundation is NIST SP 800-162, which defined the ABAC reference architecture in 2014. That spec predates AI agents, but its "subject" definition covers them: "an active entity (generally an individual, process, or device)." The most complete shipped implementation for agents is Amazon Bedrock AgentCore Policy, GA since March 2026, which uses Cedar to evaluate every agent-to-tool request at the gateway. Default-deny posture. Forbid wins over permit. OPA/Rego is the other widely deployed engine, extensible to agent contexts. Cerbos evaluates agent and delegating-user attributes together in a single policy check.

What makes it distinct. The access decision happens at the moment of execution, against the current context. Who decided? The policy decided, and the decision is logged with the full attribute set that produced it. The policy evaluates what the agent is trying to do, right now, against what's allowed. Prediction is irrelevant. Agent non-determinism doesn't matter because each tool call gets its own authorization check.

JIT Per-Task Elevation

What it is. The agent starts with zero standing privileges. When a task requires access, a narrow, time-bound credential is minted for that specific task and automatically expired when the task completes.

What it does. A token exchange (per RFC 8693) swaps a broad token for a narrow one. The narrow token carries both the agent's identity and the delegating user's identity (the On-Behalf-Of pattern), so the audit trail shows who authorized the action and who performed it. When the task ends, the credential dies. There's nothing persistent to revoke, nothing to drift, nothing for an attacker to find in a compromised environment.

Where it comes from. CyberArk Secure AI Agents (GA December 2025) was first to market with purpose-built JIT for agent identities: discovery, zero standing privileges, session monitoring. HashiCorp Vault provides the dynamic secrets layer: credentials generated on-demand, scoped to a session, expired in minutes, with correlation IDs linking every credential to the originating task. Microsoft's approach uses Entra Agent ID (public preview since November 2025) combined with Privileged Identity Management for time-bound, approval-gated elevation. (Note: Microsoft Entra Permissions Management was retired November 2025. Don't cite it in a buyer conversation.)

What makes it distinct. The credential's existence is the audit record. You don't need a separate logging system to prove the agent had access only when it needed it, because the credential didn't exist before the task and doesn't exist after. JIT for agents deserves its own category, separate from traditional PAM. Traditional PAM elevates a human who knows what task they're performing and requests access accordingly. Agent JIT must scope a credential for a task that couldn't be predicted until the agent's reasoning produced it. The scope is determined by the authorization system at task initiation, by policy, without a human request. That's a structurally different problem. Only 1% of organizations have fully implemented JIT access today. That number tells you both how early this is and how large the gap is.

Three Scenarios, Three Different Answers

I'm using scenario mapping here because these three approaches surface in specific buyer conversations with specific stakes, and a trait-by-trait matrix would flatten distinctions that only matter in context. Three scenarios, each representing a question your buyer is actually asking.

Scenario 1: The agent needs access to sensitive data for a specific task.

Static roles grant access to the entire data class. If the agent has Files.Read.All, it can read the invoice it needs and the patent draft it doesn't. The access decision was made at provisioning time by someone who wasn't thinking about this particular task.

Dynamic ABAC evaluates the request against the specific resource's attributes. A Cedar policy can enforce that the agent reads only records where the patient_id in the tool input matches the JWT claim (meaning the policy checks that the agent is only accessing the specific patient's data, not the whole database). The decision is made at call time, by policy, with full context.

JIT elevation mints a credential scoped to exactly the data the task requires. The credential expires when the task ends.

Static roles fail on granularity. ABAC and JIT both solve it, but differently: ABAC controls what the agent can touch (resource-level); JIT controls when and for how long (temporal). In practice, the strongest posture layers both.

Scenario 2: The agent's behavior changes mid-session.

The non-determinism problem. The agent starts by querying a ticket system, then decides it needs the CRM, then discovers a file store. Static roles either already granted access to all three (overpermission) or didn't grant the file store (the agent breaks). No mechanism to adjust.

Dynamic ABAC handles this natively. Each tool invocation is evaluated independently. The agent can access the ticket system, get evaluated again for the CRM, and get denied on the file store if policy doesn't permit it. No reconfiguration needed.

JIT elevation requires a new credential for each escalation. The architecture must support mid-session re-elevation, and not all JIT implementations handle this cleanly yet. Traditional secrets managers were built for workloads that don't change context frequently. Agents break that assumption.

For mid-session behavior changes, ABAC is the cleanest fit. JIT works when the underlying credential infrastructure supports rapid re-issuance. Static roles are structurally incapable.

Scenario 3: An auditor asks who authorized a specific agent action.

With static roles, you can show the agent had a role that included the permission. You cannot show that anyone decided the agent should use that permission for that specific action. The audit trail stops at provisioning.

With dynamic ABAC, every decision is logged with the full attribute context: agent identity, delegating user, resource attributes, action, environment conditions, and the policy that produced the permit or deny.

With JIT, the credential itself is the audit artifact. It was minted at a specific time, for a specific task, with a specific scope, on behalf of a specific user. Its existence proves the authorization; its expiration proves the boundary.

For any environment governed by OMB M-25-21 and M-25-22 or agency-level AI governance directives, static roles are insufficient. ABAC provides decision-level auditability. JIT provides credential-level auditability. Together they answer the auditor's question completely.

How to Say This in the Field

Don't say	Do say	Why it matters
"Agents should use least privilege."	"Your agents are running on service accounts with fixed scopes set at deploy time. The question is whether those scopes match what the agent actually needs for each individual task."	Moves from principle to mechanism.
"You need ABAC for your agents."	"Runtime policy evaluation checks every tool call at execution time. That's what handles agent non-determinism."	Describes the behavior, avoids the acronym.
"JIT access solves this."	"The credential should only exist while the task exists. When the task ends, the token expires."	Concrete mechanism, not a category label.
"Static roles don't work for AI."	"Static roles assume you can enumerate what the agent will do in advance. Agents are non-deterministic. The role can't anticipate what it doesn't know."	Names the specific failure mode.
"We need to treat agents like privileged users."	"Agents need identity controls that match how they actually operate: ephemeral tasks, variable scope, no human in the loop. That's a different identity class."	Distinguishes agent identity from human identity.
"OAuth handles this."	"OAuth gets you authenticated. The task-level authorization is a separate problem."	Names precisely where OAuth stops.
"CyberArk has a product for this."	"CyberArk shipped purpose-built agent JIT in December 2025. Zero standing privileges, agent discovery, session monitoring. First to market."	Factual, positions you as informed.
"The cloud providers are handling this."	"AWS shipped Cedar-based per-tool-call authorization in March 2026. Microsoft has Entra Agent ID in preview with PIM for JIT. Shipped capabilities, but platform-native."	Specific and honest about scope.
"Okta does JIT for agents."	"Okta Privileged Access supports JIT for non-human identities. For FedRAMP accounts, check availability. It's not in compliance cells yet."	Surfaces the constraint before the buyer does.
"Compliance requires this."	"OMB M-25-21 and M-25-22 include governance requirements for AI systems. Your buyer's CAIO is reading those as operational constraints."	Connects the technical pattern to the buyer's policy environment.

The field is genuinely early. Best practices for agent permission scoping haven't consolidated, and anyone who tells you they have is selling something. What has consolidated: static roles fail for non-deterministic actors, authorization needs to happen at runtime, and the credential's lifespan should match the task's lifespan. Those three principles are stable ground. Everything else is still being built.