TL;DR: Agentic AI combines planning, tool use, and autonomous execution, so each agent needs a verifiable identity before it can safely invoke APIs or other systems, according to Aembit. Traditional IAM assumptions break when software can act on its own, leaving traceability gaps, delegated credential risk, and weak accountability for machine actions.
At a glance
What this is: This article argues that agentic AI needs verifiable identity and runtime governance because autonomous systems can invoke tools, APIs, and workflows without the human-paced assumptions built into traditional IAM.
Why it matters: It matters because IAM, PAM, and lifecycle controls must now account for software that initiates action, not just software that responds to it, or accountability and least privilege will fail under agentic behaviour.
Context
Agentic AI is software that can pursue a goal, choose sub-tasks, use tools, and adjust execution as conditions change. That changes the identity problem from authentication of a user to governance of an acting system, because the actor itself can decide when and how to invoke external resources.
The core gap is not just whether an agent can log in. It is whether the organisation can prove which identity initiated the action, what boundary that identity was allowed to cross, and whether the resulting access path was constrained by policy rather than delegated human credentials.
For IAM and NHI programmes, this is a governance shift rather than a narrow integration issue. The article’s starting position is typical of the current market: most enterprise controls were built for human or service-to-service access, not for runtime systems that plan and act independently.
Key questions
Q: How should security teams govern machine identity credentials in agentic AI environments?
A: Security teams should extend secrets scanning to cover MCP configuration files, enforce short-lived credentials for all agent workloads, and assign clear ownership to every non-human identity regardless of its origin , human-created or AI-generated.
Q: Why do delegated credentials increase risk when AI agents and users are not clearly separated?
A: Delegated credentials can blur the boundary between user intent and agent autonomy. If the agent inherits the user’s identity, it may execute actions that are technically authorized but operationally unsafe, such as deleting production resources or exposing sensitive data. Clear identity separation allows additional policy checks, runtime controls, and confirmation steps before high-risk actions proceed.
Q: What breaks when AI agents can act without a verified human behind them?
A: Fraud and IAM controls lose attribution. If an agent can move money, create accounts, or change settings without a verified human owner, the organisation may detect the action but still be unable to prove who authorised it or whether it was legitimate. That weakens investigation, dispute handling, and governance accountability across the full lifecycle.
Q: How do agentic AI controls differ from traditional Zero Trust practices?
A: Traditional Zero Trust often stops at verifying identity and device posture, but agentic controls must verify what the actor does after access is granted. In practice, that means applying continuous scrutiny to tool calls, data movement, and delegated actions. The key difference is that the security boundary moves from login to runtime behaviour.
Technical breakdown
Why verifiable identity is the baseline for agentic AI
Agentic AI systems do not just consume data. They initiate actions through APIs, databases, software tools, and sometimes other agents. That means every runtime action needs an identity that can be authenticated, authorised, and audited independently of any human user who requested the task. A verifiable workload identity is the control anchor because it binds actions to a specific machine actor rather than to an inherited human session. Without that binding, the organisation loses the ability to distinguish legitimate agent activity from impersonation, delegated credential use, or opaque automation chains.
Practical implication: treat the agent as the actor that must be identified and governed, not as an extension of the human who prompted it.
Where delegated credentials create traceability gaps
The article points to a common failure mode: agents acting with impersonated or delegated human credentials. That pattern preserves access while destroying attribution, because the log trail points back to a person or shared account rather than to the runtime actor that actually executed the workflow. In practice, this makes incident investigation, approval review, and privilege scoping much weaker. The issue is not only exposure of a secret. It is the collapse of the identity boundary between a person and a software actor that can independently chain actions across systems.
Practical implication: remove human credential delegation from agent workflows wherever the action path needs auditability or revocation.
How runtime policy changes the control model
Agentic systems operate in a loop of observe, reason, act, and learn, which means access decisions can no longer be treated as one-time provisioning events. Runtime policy must decide what the agent can reach based on its verified identity, environment, and current context at the moment of action. This is where least privilege becomes dynamic rather than static. The governance question is not whether an agent has access in general, but whether it can use that access for the specific tool, data source, and task at hand without inheriting broader standing privilege.
Practical implication: shift access enforcement to runtime and scope permissions to the task, not to the account lifetime.
Threat narrative
Attacker objective: The attacker objective is to execute actions through an agentic workflow while avoiding clear attribution and exploiting the authority inherited from delegated credentials.
- Entry occurs when an agent is allowed to authenticate through delegated or impersonated credentials rather than a verifiable workload identity.
- Credential abuse follows when the runtime actor inherits access that was originally granted to a human or shared account, obscuring who or what actually initiated the action.
- Escalation happens when the agent chains tool calls across APIs, databases, or other agents without a separate boundary for each step.
- Impact is the loss of attribution, control, and containment, because the organisation cannot reliably reconstruct which agent performed which action and under what authority.
Breaches seen in the wild
- Moltbook AI agent keys breach: Moltbook breach exposed 1.5M AI agent keys.
- DeepSeek database exposure 2025: An unauthenticated DeepSeek ClickHouse database exposed over a million log lines with plaintext chat history and API keys in 2025.
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 AI identity is now a governance problem, not a feature toggle. Once software can choose actions and tools at runtime, identity must be proven at execution time rather than inferred from the user who initiated the request. Traditional IAM assumes a stable human operator behind the session, but agentic systems make that assumption unreliable. Practitioners should treat agent identity as a first-class governance object with its own lifecycle and audit trail.
Delegated human credentials create an accountability illusion. The organisation appears to have control because access was granted through existing IAM processes, but the actual actor is a software system operating under borrowed authority. That breaks the clean line between requestor, executor, and owner. The implication is that accountability for machine action cannot be reconstructed after the fact if the agent never had its own verifiable identity.
Runtime identity boundaries matter more than provisioning volume. Many IAM programmes still measure how many identities they manage, when the real risk is whether each identity has the right to select tools, change plans, and continue acting without a new authorisation event. Agentic systems compress the gap between decision and execution, so policy has to move closer to the tool call itself. Practitioners should reframe control ownership around runtime enforcement.
Ephemeral trust is the right mental model for agentic access. The useful concept here is not static account management but identity blast radius, the amount of damage a single agent identity can create before the organisation can interrupt it. Agentic AI extends the blast radius of a mistake because one poor tool choice can cascade into multiple systems. Practitioners should govern the chain of actions, not just the initial login.
From our research library:
- Gartner predicts that by 2028, 33% of enterprise software applications will include agentic AI, up from less than 1% in 2024, and that 15% of day-to-day work decisions will be made autonomously.
- Read next: Agentic AI Identity Guide
What this signals
Governance programmes built for human operators do not survive contact with systems that can select tools, sequence actions, and keep working without waiting for approval. The control point has to move from account creation to execution control, or least privilege becomes a paperwork exercise instead of an operational boundary. That is why verifiable identity for agents is now a design requirement, not an architectural enhancement.
Identity blast radius: the real risk in agentic environments is not just access, but how far a single runtime identity can propagate mistakes across tools, data, and other agents. Once access and action are fused, review cadences built for humans no longer match the speed of execution. Organisations need policy that constrains the action chain before it expands, not after the fact.
69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to the 2026 Infrastructure Identity Survey. For practitioners, that means current IAM roadmaps should be re-scoped around runtime governance, auditability, and revocation at the point of action, not just around provisioning workflows.
For practitioners
- Define a unique identity for every agent Assign each agent a verifiable workload identity so logs, approvals, and revocation actions map to the runtime actor rather than to a human proxy.
- Eliminate borrowed human credentials from agent flows Remove delegated usernames, shared sessions, and copied tokens from agent workflows where attribution, scoping, or rollback matters.
- Scope agent permissions to specific tools and tasks Restrict what each agent can call, change, or query at runtime so privilege is tied to the current task context instead of standing access.
- Log the full decision chain, not just the final action Capture prompts, tool selections, policy decisions, and executed outcomes so investigators can reconstruct how the agent reached the action.
- Review offboarding for autonomous identities Make sure agent identities, keys, policies, and downstream integrations are removed together when the use case ends or the workflow changes.
Key takeaways
- Agentic AI turns identity into an execution control problem because software can act, adapt, and chain tools without a human in the loop.
- Delegated human credentials weaken attribution and make revocation, containment, and investigation materially harder once an agent is acting.
- The control that matters most is verifiable runtime identity with task-scoped permission and complete decision logging.
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 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The article centres on agent identity, delegated authority, and runtime privilege misuse. |
| Recommendation — Map agent workflows to ASI03 and prevent borrowed authority from becoming standing privilege. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Verifiable workload identity is the article's core control boundary for agents. |
| NHI-05 — Overprivileged NHI | The article warns that agent tools and APIs can be exposed to more access than the task needs. | |
| Recommendation — Apply NHI-04 to replace delegated credentials with verifiable agent authentication. Use NHI-05 to scope each agent to the minimum runtime access needed for the task. | ||
| NIST AI RMF | GOVERN — AI Governance and Accountability | The article is fundamentally about governing who is accountable when AI acts independently. |
| Recommendation — Establish AI governance controls that assign ownership, review, and accountability for agent actions. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The post emphasises task-scoped access and runtime authorisation for agent actions. |
| Recommendation — Enforce PR.AA-05 so agent permissions are approved and constrained at the point of use. | ||
Key terms
- Agentic AI Identity: The complete set of credentials, permissions, and governance controls applied to an autonomous AI agent, covering authentication, authorisation, action logging, and access revocation. Distinct from traditional NHI because agent identities are often ephemeral, delegated, and multi-hop.
- Verifiable Workload Identity: A machine identity that can be authenticated and traced back to a specific runtime actor without relying on shared or borrowed human credentials. In agentic environments, this becomes the control point that preserves attribution, supports revocation, and prevents the agent from operating under an ambiguous account boundary.
- Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
- Delegated Credential: A token, key, or other secret that allows one system to act on behalf of another identity. For agentic environments, delegated credentials matter because they extend trust into runtime, where the agent can use them to reach tools, data, or services without a fresh human approval.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on May 31, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org