AI agent identity risk outpaces existing IAM controls and governance

At a glance

What this is: This analysis argues that AI agents create NHI governance problems across visibility, delegated trust, and long-lived secrets, especially when they act across multiple enterprise applications.

Why it matters: IAM and NHI teams need to treat AI agents as governed identities, or they will lose control over who can access what, through which permissions, and with which credentials.

👉 Read Okta's analysis of AI agent identity risk and NHI governance

Context

AI agent identity risk is growing because agentic systems combine autonomous execution with identity patterns that were built for software, not for decision-making workloads. In practice, that means service accounts, API tokens, OAuth grants, and app-to-app connections can expand faster than IAM teams can inventory or constrain them.

The governance gap matters because once an agent can move between tools, data sources, and external services, the blast radius is no longer limited to a single application. For NHI practitioners, the core question is not whether AI will be adopted, but whether access, consent, and secrets handling will be controlled before that adoption becomes operational debt.

Key questions

Q: How should security teams govern AI agents as non-human identities?

A: Security teams should assign each AI agent an owner, a purpose, and a bounded permission set, then monitor its actions as they would any other NHI. That means inventorying connected systems, reviewing consent paths, and revoking access when the task changes. Governance fails when agents are treated as background automation instead of accountable identities.

Q: When does delegated access become too risky for AI agents?

A: Delegated access becomes too risky when an agent can reach sensitive systems through broad consent, hidden OAuth scopes, or user-approved app-to-app links. If the business cannot explain why that access is needed, who approved it, and when it expires, the privilege is already too broad. High-value data should never rely on informal consent alone.

Q: What is the difference between secrets rotation and NHI governance for AI agents?

A: Secrets rotation reduces the time a credential can be abused, but NHI governance decides whether the agent should have that credential at all. Rotation is a hygiene control. Governance is the control structure that defines scope, approval, monitoring, and revocation. Autonomous systems need both, but governance comes first because it limits the blast radius.

Q: Why do AI agents create more identity risk than ordinary applications?

A: AI agents can make choices, chain actions, and adapt to context, so the same credential may be used in ways teams did not explicitly anticipate. Ordinary applications usually follow fixed logic. Agents can drift across systems, which makes access decisions harder to predict and audit. That unpredictability is why they need explicit identity controls.

Technical breakdown

Why AI agents behave like non-human identities

AI agents are software entities that use identity credentials to act, but they do not behave like deterministic workloads. They plan, choose actions, and iterate across tools, which means the same identity can produce different access paths depending on prompts, context, or connected systems. That makes them closer to governed NHI entities than to traditional application code. When an agent authenticates with service accounts, OAuth tokens, or API keys, the security model must account for both machine identity and autonomous decision-making. Without that, privilege assumptions collapse quickly.Practical implication: Treat every agent as an identity with its own lifecycle, entitlement set, and audit requirements.

Practical implication: Treat every agent as an identity with its own lifecycle, entitlement set, and audit requirements.

Delegated trust and app-to-app access risks

Delegated trust becomes risky when a user can consent to one application accessing another on their behalf, or when agent workflows inherit permissions without central approval. The problem is not just authentication. It is the scope of authorization that gets quietly expanded through app-to-app connections, sometimes into crown-jewel systems. In NHI terms, this is a governance failure in consent management, not a simple integration issue. The more tools an agent can reach, the more likely a single compromise or prompt manipulation can translate into sensitive data exposure.Practical implication: Centralise approval for cross-application trust and block unsafe consent paths where sensitive data is in play.

Practical implication: Centralise approval for cross-application trust and block unsafe consent paths where sensitive data is in play.

Long-lived secrets create persistent agent risk

AI use cases often push teams toward long-lived secrets because function calling, MCP-style integrations, and SaaS connections need credentials that survive beyond a single session. That increases the chance of leakage through logs, developer workflows, or compromised endpoints. The issue is not only storage. It is that durable secrets create durable access, which is the opposite of least privilege for autonomous systems. Ephemeral credentials reduce exposure, but they only work when the surrounding identity model can support short-lived, scoped access.Practical implication: Replace static secrets with short-lived credentials wherever the workflow can tolerate it, and audit every exception.

Practical implication: Replace static secrets with short-lived credentials wherever the workflow can tolerate it, and audit every exception.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI agents should be treated as governed NHI, not as extended application logic. Once an autonomous system can choose actions across tools and data sources, the identity problem changes from account management to behavioural control. That shifts the security question from "can it authenticate" to "what can it do, and under what conditions?" Practitioners need entitlement design, logging, and access review built around agent behaviour, not just around the underlying workload.

Delegated trust is the real control surface for agentic AI. The dangerous part of many AI integrations is not the model itself, but the permissions inherited through user consent, app-to-app links, and hidden OAuth scopes. Those grants can outlast the business case that justified them. The field should stop treating consent as a convenience layer and start treating it as an access governance decision.

Ephemeral credential trust debt is becoming a practical NHI problem. Teams know static secrets are risky, yet they still rely on them when integrations become complex or when agents need persistent reach. That creates trust debt because every exception accumulates future exposure. The practitioner takeaway is simple: if the access cannot be short-lived and auditable, it is probably too broad for an autonomous system.

Visibility has become a prerequisite for AI governance, not a reporting nicety. If security teams cannot inventory which AI tools are connected, which resources they touch, and which permissions they hold, then policy enforcement is mostly aspirational. The market is moving toward environments where AI adoption happens first and governance catches up later. That order needs to reverse if organisations want to avoid unreviewed identity sprawl.

NHI programs now need agent-specific controls, not just secrets hygiene. Secrets rotation and vaulting remain necessary, but they do not solve non-deterministic behaviour, delegated authorization, or cross-system data access. Practitioners should treat agent governance as its own control domain, with lifecycle, approvals, monitoring, and revocation handled explicitly. The sooner that domain is formalised, the lower the blast radius of adoption.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• Only 44% of organisations have implemented policies to govern AI agents even though 92% agree that governance is critical, which shows that policy adoption is lagging behind risk recognition.
• That gap is a signal to move from reactive secrets handling to explicit agent lifecycle control, as outlined in Top 10 NHI Issues.

What this signals

Ephemeral credential trust debt is now a practical governance issue for AI programmes. The more often teams use persistent tokens to simplify integration, the more unmanaged access they accumulate across systems. As AI adoption expands, that debt turns into an audit and containment problem unless organisations move to short-lived, reviewable access paths.

With 98% of organisations planning to deploy more AI agents in the next 12 months, the operational default will be expansion rather than control. That makes agent inventory, consent review, and revocation workflows part of core identity architecture, not an optional security overlay. Teams that wait for a mature standard will already be managing sprawl.

Programmes that already use the OWASP NHI Top 10 or the NIST AI Risk Management Framework can adapt faster because the control language already exists. The next step is to bind those frameworks to actual agent inventories and approval records, then enforce them in daily operations.

For practitioners

• Implement agent inventory and ownership mapping Track every AI tool, connected resource, and executing agent in a single inventory that names the business owner, technical owner, and approval source. Include app-to-app links and consent grants so shadow AI does not hide inside sanctioned workflows.
• Restrict delegated trust at sensitive systems Block user-consent flows where AI agents can reach crown-jewel data, and require central approval for high-risk app-to-app access paths. Use explicit policy for cross-system access rather than leaving scope decisions to end users.
• Shorten secret lifetime wherever possible Replace downloadable API tokens and static credentials with ephemeral tokens and scoped access patterns. Where long-lived secrets remain unavoidable, enforce vaulting, monitoring, and immediate revocation procedures.
• Review agent permissions on a fixed cadence Tie AI agent access reviews to the same discipline used for privileged access, including periodic recertification, usage logs, and exception tracking. The goal is to remove standing access that no longer matches the task.

Key takeaways

• AI agents create a governance problem because they act as identities, but they do not behave like deterministic workloads.
• The scale of the issue is already visible, with most organisations reporting AI agents acting beyond intended scope.
• Practitioners should tighten inventory, consent, and secrets controls before agent adoption expands further.

Key terms

• AI Agent: An AI agent is software that can plan, choose actions, and use tools on its own within a defined environment. In identity terms, it behaves like a non-human actor that must be authenticated, authorised, monitored, and revoked with the same care as other privileged NHI types.
• Delegated Trust: Delegated trust is the practice of allowing one application or identity to act on behalf of another, often through consent, scopes, or token exchange. For AI agents, it becomes risky when users can approve access that security teams would normally want to centralise, review, and constrain.
• Ephemeral Credential: An ephemeral credential is a short-lived secret or token that expires quickly and limits the window of abuse. It is a preferred pattern for NHI governance because it reduces standing access, but it still requires scope control, logging, and revocation if the task or agent behaviour changes.
• Identity Blast Radius: Identity blast radius is the amount of systems, data, and permissions that can be reached if one identity is misused or compromised. For AI agents, the blast radius can expand quickly when broad scopes, hidden app links, or persistent secrets connect multiple enterprise resources.

Deepen your knowledge

AI agent identity governance is covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for autonomous systems, it is a practical place to start.

This post draws on content published by Okta: AI, IAM, and identity security posture analysis for AI agents. Read the original.