TL;DR: AI agents are already operating beyond human-speed access patterns, and 73% of CISOs say they are critically concerned while only 30% report mature safeguards, according to Aembit. Legacy IAM assumptions around static sessions, long-lived secrets, and predictable users do not hold once agents authenticate to APIs, databases, and MCP servers at runtime.
At a glance
What this is: This analysis argues that AI agent identity security requires a different IAM model because autonomous agents break assumptions built around static sessions, long-lived secrets and human-speed access patterns.
Why it matters: IAM, PAM and NHI teams need to reassess how identities are proven, authorised and audited when software acts at runtime across APIs, databases and MCP servers.
By the numbers:
- 73% of CISOs are critically concerned about AI agent security risks.
- only 30% have mature safeguards in place
Context
AI agent identity security is the problem of proving, authorising and auditing software that makes access decisions at runtime. The article says traditional IAM does not fit because it assumes predictable sessions, password-based authentication and human-speed access patterns.
The governance gap is not just credential sprawl. Agents can call multiple services in seconds, create new trust relationships with each step and bypass the review cadence that human-centric IAM programmes depend on.
Key questions
Q: What breaks when AI agents are treated like standard human users?
A: You lose visibility into effective permissions, expected behaviour, and real blast radius. Human-centric controls can misclassify normal agent activity as compromise, or miss policy violations that happen entirely within legitimate access. The failure is not only technical, it is governance design that assumes a person is always behind the action.
Q: Why do static credentials create more risk for AI agents than for traditional workloads?
A: AI agents execute quickly, can chain actions across systems and may terminate before manual review ever happens. Static credentials remain valid long after the task ends, which means stolen or shared secrets can be replayed outside the intended scope and become a direct path to privileged access.
Q: How do security teams know if agent authorization is actually working?
A: Authorization is working only if the agent can complete the intended task without gaining unnecessary reach. Good signals include short-lived credentials, task-scoped permissions, approval for sensitive changes, and clear logs linking each action to a user and an agent. If credentials are reused, privileges persist, or the agent can move between systems without reauthorization, the control is failing.
Q: What should teams do when autonomous agents need access to multiple systems?
A: Design for runtime authorisation rather than broad pre-provisioning. Each system should evaluate the agent’s identity and context before granting access, and the resulting permission should be narrow enough to fit one task, not an entire workflow. If teams widen scopes to avoid failure, they are trading usability for uncontrolled blast radius.
Technical breakdown
Why legacy IAM fails for AI agents
Legacy IAM was designed around stable subjects: human users who log in, receive a session, and remain inside a bounded access pattern until logout. AI agents behave differently. They authenticate to multiple systems, select tools dynamically at runtime, and can chain calls across APIs, databases and MCP servers in seconds. That means the identity subject is no longer a person with a predictable intent path but a software workload whose access needs are continuously changing. Once access is granted, the system may not have a clean moment to re-evaluate who or what is acting. The result is a mismatch between static identity controls and dynamic execution behaviour.
Practical implication: Treat agent identity as workload identity, not user identity, when designing authentication and authorisation flows.
How cryptographic attestation changes agent identity
The article describes a shift from secret-based trust to proof-based trust. Instead of presenting a reusable API key, an agent can present cryptographic attestation from a trusted runtime such as cloud infrastructure, Kubernetes or a CI/CD platform. That proof is bound to the environment and to the agent instance, which makes it materially different from a shared credential. In practice, this changes the trust object from something stored and reused to something verified at runtime. The control question becomes whether the workload is running where it claims to be running and whether that environment still matches policy.
Practical implication: Base agent access on attestation and short-lived credentials rather than reusable static secrets.
Why runtime policy matters more than pre-provisioned access
Agentic access cannot be assumed in advance because the agent determines its needed permissions dynamically as tasks unfold. The article notes that over-granting expands blast radius, while under-granting often leads teams to loosen controls after failures. Runtime policy evaluation is the answer to that tension: identity, posture and context are checked at the moment of access, not just at onboarding. This is especially important when agents interact with multiple trust domains, such as cloud providers, SaaS platforms and external AI services, each with different scopes and expiry models.
Practical implication: Move authorisation decisions to request time so permissions stay aligned with actual task context.
Threat narrative
Attacker objective: Exploit agent access paths to reach data, tools or downstream systems through identity controls that were never built for autonomous runtime behaviour.
- Entry occurs when an AI agent authenticates successfully to APIs, databases or other connected services using credentials or attestations accepted by the legacy stack.
- Escalation follows as the agent accumulates tool access across multiple integrations, creating new trust relationships that are not fully governed or reviewed.
- Impact is the creation of invisible, time-bounded but powerful machine access that can be abused through credential sprawl, unreviewed permissions or manipulated agent behaviour.
Breaches seen in the wild
- CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Legacy IAM is built on a human-session assumption that does not survive autonomous execution. The model assumes identity is established once, then trusted for the duration of a session. AI agents continuously acquire new access paths while they work, so the original trust decision becomes stale almost immediately. The implication is not simply more automation, but a different identity premise: runtime identity proof must replace login-time trust.
Ephemeral credential trust debt is now the core NHI problem in agentic systems. Every new integration can add another credential, scope and expiry model, and the article shows how that proliferation becomes invisible quickly. Short-lived credentials reduce exposure, but they also increase operational dependency on runtime governance because the control boundary moves from storage to issuance. Practitioners should read that as a governance shift, not just a secrets-management improvement.
Accountability chains fracture when agents delegate to sub-agents or chained services. The article notes that no system tracks which agent authorised which sub-agent to act, which means the delegation record is partial even when the action is valid. That is a governance failure, not a logging nuisance. IAM teams need to recognise that delegation is now an identity property, not only a workflow concern.
Shadow agents create the same governance blind spot that shadow IT created, but at machine speed. Unregistered agent identities can appear with credentials no one tracks and access patterns no one monitors. The difference from legacy shadow IT is that these identities can create trust relationships in seconds and disappear just as fast. The practical conclusion is that discovery, ownership and lifecycle control must move earlier in the agent deployment path.
Agentic identity requires a named concept: runtime trust boundaries. The article makes clear that the real control problem is not whether an agent exists, but where its trust boundary begins and ends during execution. When identity, posture and context are evaluated only at startup, the boundary is too wide for autonomous behaviour. Practitioners should treat every runtime decision as a new trust event.
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
Runtime trust boundaries: agent identity is no longer a login-time event but a sequence of access decisions that must be revalidated as the workflow unfolds. Programmes that still rely on stable sessions will keep missing the moment when the agent changes scope mid-task.
The operating signal for practitioners is whether agent access can be issued, constrained and revoked without relying on human-paced review. 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, which makes runtime governance a near-term programme requirement.
For practitioners
- Define agents as managed workloads Assign each agent, orchestrator and tool connector a distinct identity and ownership record so access can be tied to a specific runtime subject rather than a broad application bucket.
- Replace static secrets with runtime proof Use cryptographic attestation and short-lived credentials for agent access, and remove reusable API keys from agent configuration wherever possible.
- Policy-gate every agent request Evaluate identity, environment posture and request context at access time so approvals reflect the task being attempted rather than a pre-set role.
- Track delegation across sub-agents Log which agent authorised each downstream action, including tool handoffs and chained calls, so accountability survives delegation.
- Discover shadow agents early Continuously inventory agent identities, connected tools and issuance paths so unmanaged runtime actors do not build hidden access paths.
Key takeaways
- AI agent identity security exposes a structural mismatch between legacy IAM and autonomous software that can request, combine and use access at runtime.
- The article shows why static credentials, session trust and human-speed review do not scale once agents interact with APIs, databases and MCP servers.
- Practitioners need identity proof, runtime policy and traceable delegation if they want agent access to stay governable.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article centres on proving AI agent identity at runtime instead of trusting static login assumptions. |
| NHI-05 — Overprivileged NHI | The article warns that pre-provisioned permissions expand blast radius when agents determine access dynamically. | |
| NHI-07 — Long-Lived Secrets | The article criticises API keys and service account secrets that persist across agent workflows. | |
| Recommendation — Replace static login trust with attested, workload-bound authentication for AI agents. Scope agent permissions to each task so runtime access does not exceed need. Eliminate long-lived secrets from agent workflows and issue short-lived credentials instead. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Autonomous agents can accumulate or misuse access across chained tools and delegation paths. |
| Recommendation — Constrain agent privilege paths and review delegation chains for identity abuse. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article describes credential sprawl and ungoverned movement across connected systems. |
| Recommendation — Hunt for credential access and lateral movement patterns created by agent workflows. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Runtime access control and entitlement scoping are central to the article's governance model. |
| Recommendation — Enforce request-time authorisation for agent entitlements and permissions. | ||
| NIST Zero Trust (SP 800-207) | Continuous verification — Continuous verification | The article depends on verifying workload identity and posture continuously, not once at login. |
| Recommendation — Apply continuous verification to every agent access decision and revoke when posture changes. | ||
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.
- Cryptographic Attestation: Cryptographic attestation is a method of proving that a workload or service is genuine by using cryptographic evidence instead of static shared secrets. It is especially useful for short-lived access models because identity proof is tied to runtime context rather than reusable credentials.
- Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.
- Shadow Agent: An AI agent deployed without formal registration, identity governance, or security oversight, the agentic equivalent of shadow IT. Shadow agents are more dangerous than typical shadow NHIs because they actively take actions using their credentials.
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 June 6, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org