TL;DR: AI agents are dynamic, ephemeral and autonomous, so the source article argues they need identity controls at every step from OIDC authentication to JIT provisioning, policy evaluation and human approval for sensitive actions, according to Strata Identity. The core issue is that legacy IAM assumes fixed, long-lived identities, while agentic work creates delegation chains and runtime decisions that existing NHI models do not cover.
At a glance
What this is: This analysis argues that AI agents need purpose-built identity governance because static NHI controls do not adequately handle ephemeral, delegated and autonomous execution.
Why it matters: IAM teams need to separate agentic identity from ordinary NHI because the control points, approval model and audit expectations change when software can choose actions at runtime.
By the numbers:
- By 2026, 30% of enterprises will rely on AI agents that act independently, triggering transactions and completing tasks on behalf of humans or systems.
👉 Read Strata Identity's analysis of agentic identity flow and Zero Trust controls
Context
AI agent identity has become a governance problem because runtime behaviour now includes reasoning, delegation and action selection, not just credential use. That makes the primary question one of identity control, not model quality or workflow speed, and it sits squarely inside agentic AI and NHI governance.
The source article frames the gap clearly: legacy IAM and static NHI patterns were built for long-lived accounts and fixed scopes, while agentic flows can traverse APIs, clouds and trust zones in a single task. For practitioners, the issue is whether current identity controls can still prove who acted, under what authority and with what delegation context.
Key questions
Q: How should security teams govern AI agents that can act on behalf of users?
A: Security teams should govern AI agents as delegated actors with explicit subject-actor binding, task-scoped authority and step-up approval for sensitive actions. The control objective is not just authentication, but proving who authorised the action, what the agent was allowed to do and whether the execution stayed inside policy.
Q: Why do AI agents expose gaps in existing NHI governance?
A: AI agents expose gaps because many NHI controls assume fixed scopes, stable credentials and predictable task boundaries. When an actor can reason, delegate and choose actions at runtime, governance has to account for dynamic authority, not just credential possession.
Q: What breaks when agent identities are not provisioned just in time?
A: Without just-in-time provisioning, agent identities accumulate like any other standing account, which increases exposure, permission drift and audit noise. The result is a longer-lived identity surface that no longer matches the short-lived nature of the work being performed.
Q: Who should approve high-risk actions taken by an AI agent?
A: A verified human should approve high-risk agent actions before execution, especially where money, sensitive data or privilege changes are involved. Approval should be coupled with liveness validation and logged context so the organisation can prove the decision was intentional and attributable.
Technical breakdown
OIDC and OAuth subject-actor trust binding in agentic flows
The article describes a delegated model where a human or upstream agent authenticates, then binds subject and actor through OAuth scopes and OIDC-backed identity. That matters because the subject is not always the entity executing the work. In agentic systems, the actor identity needs explicit constraints that survive across task execution, delegation and resource discovery. Without that binding, authorization becomes ambiguous as soon as the agent begins choosing APIs or services at runtime.
Practical implication: map every delegated agent flow to a named subject, actor and scope relationship before allowing production access.
JIT provisioning and ephemeral agent identities
Just-in-time provisioning changes the identity lifecycle by creating agent credentials only for the duration of a task, then retiring them after completion. The article ties this to attributes such as TTL, purpose, risk and delegation context, which turns identity into a short-lived policy object rather than a standing account. That is a major departure from ordinary NHI handling, where long-lived credentials often persist across repeated tasks and operators.
Practical implication: design agent identities to expire automatically with task completion and verify that no reusable credential survives the session.
Policy evaluation, human approval and observability for autonomous actions
The article combines layered policy evaluation with human-in-the-loop approval for sensitive actions and centralized logging for every decision point. This is important because agentic execution can cross policy domains quickly, making coarse-grained access rules insufficient on their own. By logging subject, actor, delegation, purpose, resource and policy decisions, the architecture creates an audit trail that can support compliance and incident review. The real control plane is the combination of authorization, approval and observability.
Practical implication: require step-up approval and full decision logging for any agent action that can move money, expose data or change entitlements.
Breaches seen in the wild
- Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
- AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Agentic identity is not a variant of NHI governance, it is a different control problem. The article makes the right distinction between static machine credentials and dynamic, self-directed agent behaviour. A service account is assigned a task and kept inside fixed bounds, but an AI agent can reason, delegate and select execution paths mid-session. That changes what identity evidence needs to prove, and practitioners should stop treating agentic access as a simple extension of workload identity.
Least privilege is designed for known intent, and that assumption breaks when the actor decides at runtime. Least privilege was built for a condition where scope can be determined at provisioning time. That assumption fails when the actor is autonomous because the execution path, tool choice and timing emerge during the task itself. The implication is that access design must be reconsidered around runtime authority rather than static role assignment.
Dynamic, ephemeral agent identities create an identity blast radius that legacy reviews cannot comfortably absorb. The article's JIT model reduces standing exposure, but it also means the governance boundary moves into the live session. That raises the bar for policy evaluation, subject-actor binding and forensic logging because there may be no durable entitlement state to review after the fact. Practitioners should treat agent identity as an event-driven control surface, not a managed account list.
Runtime delegation context is the named concept that matters most here: authority is no longer just who authenticated, but what the agent was allowed to do, for whom and under what purpose. The article repeatedly attaches purpose, risk and delegation context to the identity lifecycle, which is the right unit of control for agentic systems. That framing is more defensible than role-only governance because it captures why the action was allowed, not just that a credential existed. Practitioners should build policy around delegation context as a first-class identity attribute.
Human approval remains essential because autonomous execution can outpace the controls that were built for human-paced change. The article's step-up and liveness checks show that high-risk agent actions still need verified human intent. That is a governance statement as much as a security one: when software can act quickly and across domains, accountability has to be re-anchored at the approval boundary. Practitioners should preserve human authorization for sensitive outcomes even when routine work is delegated.
From our research:
- 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
- That gap aligns with Ultimate Guide to NHIs, which shows 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
What this signals
Runtime delegation context is becoming the real control plane for agentic identity, because the question is no longer whether an agent can authenticate, but what it is authorised to do in the moment and under whose intent. Teams that keep using static role models will miss the live decision boundary.
With 80% of organisations reporting agent actions beyond intended scope in the cited research, the governance problem is already operational rather than theoretical. That means access reviews alone will not close the gap if the session can self-direct before review ever happens.
Practitioners should align agent governance with the OWASP Top 10 for Agentic Applications 2026 and the NIST AI Risk Management Framework so policy, authorization and accountability are designed for runtime behaviour, not just static entitlements.
For practitioners
- Map subject, actor and delegation chains Inventory every agentic workflow so the human, delegating agent and executing agent are explicitly linked in policy, logs and approvals. Do not allow opaque delegation paths where the actor identity is clear but the authorising subject is not.
- Convert standing agent access into task-scoped identities Issue agent credentials with TTL, purpose, risk and delegation context, then retire them automatically when the task ends. This prevents reusable identities from becoming a hidden standing-privilege layer.
- Gate sensitive actions with step-up approval Require liveness validation and human confirmation for actions that touch payments, production data or entitlements. The approval step should occur before execution, not after the agent has already committed the change.
- Log every policy decision end to end Send subject, actor, purpose, resource and policy outcomes into a centralized audit system that your SIEM can query. Use those records to prove why the action was allowed and whether the delegation stayed within scope.
- Rebuild review processes around runtime authority Test whether access reviews, recertification and offboarding still make sense when the identity may exist only briefly and act autonomously. If the control depends on a stable account, it will miss the governance moment that matters.
Key takeaways
- AI agents change identity governance because they can act, delegate and choose tools at runtime, which makes static NHI assumptions incomplete.
- The scale of the problem is already clear, with 30% of enterprises expected to rely on independently acting agents by 2026.
- Task-scoped identity, human approval for sensitive actions and complete decision logging are the controls that turn agentic access into something auditable.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 address the attack and risk surface, while NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | Agent runtime behaviour and tool use are central to this article. | |
| NIST AI RMF | The article focuses on governance and accountability for AI-driven behaviour. | |
| NIST Zero Trust (SP 800-207) | PR.AC-4 | Zero Trust access decisions are applied continuously in the flow. |
Map agent workflows to runtime authorization, delegation and tool-use constraints before production deployment.
Key terms
- Agentic Identity: An agentic identity is a non-human identity that can make runtime decisions, choose tools and carry out tasks with limited or no direct human intervention. In practice, it needs governance around delegation, purpose and approval because the identity is acting, not just authenticating.
- Subject-Actor Binding: Subject-actor binding links the human or upstream delegator to the AI agent that actually performs the work. It is the control relationship that makes delegation explicit, so auditors can see who authorised the action, what the agent executed and under which scope.
- Just-in-Time Provisioning: Just-in-time provisioning creates identity access only when a task requires it and retires that access when the task ends. For agentic systems, the value is not convenience, but reducing standing privilege and limiting how long a delegated identity can exist.
- Delegation Context: Delegation context is the set of task, purpose, risk and authority details that explain why an AI agent was allowed to act. It turns access from a simple credential question into a governance question, which is essential when the actor can select actions dynamically.
Deepen your knowledge
AI agent identity governance and runtime delegation are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for autonomous workflows from a similar starting point, it is worth exploring.
This post draws on content published by Strata Identity: the agentic identity flow and how identity controls need to change for AI agents. Read the original.
Published by the NHIMG editorial team on 2025-06-20.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org