Subject Profiles
Static Least-Privilege
What it is: A permission assignment model in which an agent receives the minimum set of permissions required to perform its intended function, determined at provisioning time and held constant across all subsequent invocations.
What it does: At deployment, an administrator — or an automated provisioning system — enumerates the resources and actions the agent is expected to need: read access to a document store, write access to a ticketing system, call rights to a specific API. Those permissions are provisioned as a fixed credential or scope set. Every time the agent runs, it runs with that same permission set, regardless of what the specific task requires.
Where it comes from: Static least-privilege is the direct application of NIST SP 800-53's least-privilege principle (AC-6) to non-human identities. It maps cleanly onto existing provisioning workflows — create a service account, assign it a role, audit it periodically — which is why most current production AI agent deployments use this model. The fit is administrative convenience, not architectural suitability.
What makes it distinct: The permission set is fixed at provisioning time, based on what the agent might need across all possible tasks, not what it needs for the task it's actually running right now.
Just-in-Time Permission Elevation
What it is: A permission model in which an agent receives only the permissions required for the specific task currently being executed, issued at the moment the task begins and expired when the task ends.
What it does: When an agent receives a task, a policy engine evaluates the task context — what action is being requested, against what resource, under what conditions — and issues a time-bounded, scope-limited credential for that specific operation. The credential doesn't persist between tasks. If the agent's next invocation requires different permissions, it requests them again, and the policy engine evaluates again.
Where it comes from: JIT elevation as a concept originates in PAM — the privileged access workflow where a human requests elevated access, an approval process runs, a time-bounded credential is issued, and the session is recorded. The AI agent variant is being developed across several communities: the CNCF's workload identity work, emerging guidance in NIST's AI Risk Management Framework, and vendor-specific implementations from Okta, Microsoft Entra, and others. As of mid-2026, there is no production standard for JIT elevation in agentic AI workflows. The field is converging on the concept; the implementation is still being built.
What makes it distinct: The permission set is determined at runtime by task context, not by identity alone. The agent's identity is a necessary input to the policy decision, but not a sufficient one — the task itself is the other variable.
Okta Concept Mapping: PAM
PAM's core move is right: time-bound the credential, don't leave it sitting in a service account. Where it breaks: PAM assumes you know the target system at request time. JIT for agents has to determine the target dynamically — the policy engine isn't vaulting a known credential; it's deciding at runtime what to issue. In a buyer conversation, "JIT elevation" and "PAM for agents" are not the same thing, and conflating them will cost you credibility when the implementation team asks follow-up questions.
Comparison Strategy: Trait-Led Analysis
Trait-led analysis is the right structure here because the failure of static least-privilege is structural — it shows up across every agent deployment, not just specific scenarios. Mapping to a single workflow would let a buyer think "that doesn't apply to us." The traits apply universally. Four dimensions: when permissions are assigned, what the permission set is based on, what the failure mode looks like, and what the operational requirements actually are.
Dimension 1: When Permissions Are Assigned
Static least-privilege assigns permissions once, at provisioning time. This works for human users because human job functions are stable enough that a provisioned permission set remains approximately correct over time. An analyst provisioned to read from a data warehouse will, in fact, mostly read from a data warehouse.
An agent's job function is not stable in the same way. The same agent, deployed to "assist with procurement workflows," might on one invocation need to read a vendor contract, on the next need to write to a purchase order system, and on the next need to call an external vendor API to check delivery status. These are different permission sets. To cover all of them statically, you provision the union of all possible permissions, which is not least-privilege. It's maximum-of-all-tasks privilege, wearing least-privilege's name.
JIT elevation assigns permissions at task execution time. The agent presents the task context to a policy engine, the engine determines what permissions are required for that specific operation, and issues them. The agent never holds permissions it isn't actively using.
Static assignment means the agent's permission surface is constant and maximal. JIT means the permission surface is bounded by the current task.
Dimension 2: Basis for the Permission Set
Static least-privilege bases permissions on identity: this agent, in this role, gets these permissions. The policy is written once, at provisioning time, and applies to every invocation.
JIT elevation bases permissions on identity plus task context. The policy engine needs to know not just what is asking, but what it's asking to do. This requires the agent, or the orchestration layer above it, to surface structured task metadata that the policy engine can parse and evaluate. That's a genuine new requirement. Existing IAM policy engines evaluate identity attributes, group memberships, and resource attributes. They don't natively evaluate "the agent is currently executing a task of type X against resource Y at step Z in a workflow."
That's where JIT for agents diverges from PAM. PAM's policy evaluation answers: does this human have authorization to access this system? The answer is a function of identity and resource. JIT for agents must answer: does this agent have authorization to perform this action, in this task context, against this resource? The answer is a function of identity, task type, resource, and workflow state. The policy language to express that doesn't fully exist yet in production IAM systems.
Okta Concept Mapping: OAuth Scopes
Scopes are the right unit of analysis — read:contracts, write:purchase-orders — and the buyer who knows OAuth is already thinking in the right direction. Where it breaks: scopes are issued at authentication time and persist for the token's lifetime, but JIT elevation requires scopes tied to task execution and expired at task completion, which is a different token architecture than OAuth alone provides. In a buyer conversation: "we scope the agent with OAuth" gets you the vocabulary; the token lifecycle still needs work.
Dimension 3: Failure Mode
The failure mode of static least-privilege for agents is systematic over-provisioning. Because you can't predict at provisioning time exactly which permissions each task will require, you provision for the broadest plausible case. The agent ends up with more access than any single task needs. This isn't a configuration error — it's the logical outcome of applying a provisioning-time model to a runtime-variable problem. The NIST AI RMF flags this pattern explicitly: agents accumulate permissions because narrowing them is tedious and breaks workflows.
The failure mode of JIT elevation is infrastructure that doesn't exist. JIT requires a policy engine that can evaluate task context, a mechanism for the agent to surface that context at runtime, a credential issuance system that can issue task-scoped credentials, and enforcement that actually terminates the credential when the task ends. In most enterprise environments today, none of these components are fully assembled for agentic workflows. The model can't be fully implemented yet, so teams fall back to static provisioning anyway.
The honest answer for most buyers right now: you're probably running static least-privilege, you're probably over-provisioned, and the JIT infrastructure to fix that is partially available and not yet standardized.
Dimension 4: Operational Requirements
Static least-privilege requires a provisioning process, a role or scope definition, and periodic access reviews. These exist in every mature IAM program. The operational burden is low because the model is familiar.
JIT elevation requires four things that are genuinely new:
Runtime context awareness. The policy engine must receive task context at the moment of execution — not just the agent's identity, but what the agent is doing. This means the agent or the orchestration layer must emit structured task metadata that the policy engine can parse.
Task-level policy evaluation. Policies must be written at the task level, not the resource level. "This agent can read contracts when executing a procurement review task" is a different policy structure than "this service account has read access to the contracts bucket." Most IAM policy engines aren't built for the former.
Short-lived credential issuance. The credential must be issued at task start and scoped to that task. Technically achievable with existing infrastructure (short-lived tokens, SPIFFE/SPIRE for workload identity), but it requires the orchestration layer to request credentials per task rather than per session.
Expiration enforcement tied to task completion. The credential must expire when the task ends, not on a timer. Timer-based expiration is a reasonable approximation, but a task that runs longer than expected will either fail because the credential expired, or succeed with a credential that was issued for a different task scope. True task-completion-triggered expiration requires the orchestration layer to signal task completion to the credential issuer. Hardest to implement in practice, and most production implementations skip it.
Okta's governance capabilities cover parts of this: fine-grained authorization, lifecycle management for service accounts. But Okta doesn't have a complete, production-ready answer for task-scoped credential issuance tied to agent workflow state. Nobody does yet. Better to say it before the buyer's implementation team discovers it.
Okta Concept Mapping: Zero Trust / Non-Human Identities
Zero trust maps directly: don't assume the agent's prior authorization covers the current request. Where it needs extension: ZT frameworks were designed for human users with predictable access patterns, so "verify" means identity and device posture, not task context, which is what agent JIT requires. In a buyer conversation, zero trust is the right principle, but applying it to agents means extending the existing ZT architecture, not just pointing it at a new subject type.
How to Say This in the Field
| Don't say | Do say | Why it matters |
|---|---|---|
| "We follow least-privilege principles for the agent." | "We provision least-privilege at the task level, not the role level — the agent only holds permissions while it's actively using them." | "Least-privilege" without timing specificity describes the failure mode, not the solution. |
| "It's like PAM for agents." | "JIT elevation borrows PAM's time-bounding concept, but the policy evaluation is different — PAM knows the target system at request time, agent JIT has to determine it dynamically." | Collapsing JIT into PAM leads buyers to think their existing PAM investment solves this. It doesn't. |
| "The agent only gets what it needs." | "The agent only gets what it needs for this specific task — the permission set changes with every invocation." | "What it needs" sounds like static scoping. Task-specificity is the operative distinction. |
| "We can scope the agent with OAuth." | "OAuth scopes give us the right vocabulary, but they're issued at authentication time. JIT requires scopes tied to task execution — that's a different token lifecycle." | Buyers who know OAuth will think scopes solve the problem. They're necessary but not sufficient. |
| "We'll audit the agent's access." | "Audit tells you what happened. Task-scoped permissions limit what can happen. We need both, and audit doesn't substitute for the other." | Audit-as-control is a common deflection. It doesn't address the over-provisioning problem. |
| "The agent has read-only access." | "Read-only covers this task. The question is whether the agent needs write access on the next task, and whether that's provisioned statically or issued at runtime." | Read-only sounds safe but is still a static permission that may not match the task. |
| "This is a zero trust problem." | "Zero trust is the right principle. ZT frameworks weren't designed for non-human identities executing non-deterministic workflows, and that's the gap worth naming." | "Zero trust" without specificity is a deflection. Name the implementation gap. |
| "The agent needs admin access to do its job." | "If the agent needs admin access for every task, that's a signal the tasks haven't been decomposed finely enough. JIT elevation works best when tasks are scoped narrowly." | Admin-for-everything is the failure mode of static over-provisioning. Don't accept the premise. |
| "We'll use short-lived tokens." | "Short-lived tokens are part of it. The harder requirement is tying expiration to task completion, not to a timer — a task that runs long shouldn't hold credentials issued for a different scope." | Timer-based expiration is an approximation. Name the gap so the buyer understands what fully implemented looks like. |
| "JIT elevation solves the agent permission problem." | "JIT elevation is the right model. The honest answer is that the infrastructure to fully implement it (task-level policy evaluation, task-completion-triggered expiration) isn't standardized yet. Here's what's available today and where the gaps are." | Overclaiming JIT as a solved problem destroys credibility when the buyer's team tries to implement it. |