AI agent identity risk is outpacing enterprise IAM controls

At a glance

What this is: This is an analysis of why AI agents create identity security risk that legacy IAM, PAM, CSPM, DSPM, and NHI controls do not fully model.

Why it matters: It matters because identity programmes now need to govern agent lifecycle, effective permissions, and tool access patterns, not just human accounts or deterministic machine workloads.

Context

AI agent identity risk is the gap that appears when autonomous systems can read data, call tools, and request additional permissions during execution. Traditional IAM and NHI controls assume access can be pre-modelled around stable roles or deterministic workload patterns, which does not fit agentic behaviour.

The article frames AI Security Posture Management as a way to discover AI models and their data pipelines, then compute how those relationships create risk. For identity teams, the important shift is that the control problem moves from account inventory alone to effective permissions across a dynamic access graph.

Key questions

Q: What breaks when AI agents are given broad inherited permissions?

A: Broad inherited permissions break the assumption that access is tied to a narrow business need. The result is larger blast radius, weaker accountability, and faster propagation of mistakes or abuse across connected systems. A single compromised or misconfigured agent can then touch far more data and workflows than the original task required.

Q: Why do agentic systems increase identity security risk even when IAM is already in place?

A: Because traditional IAM is designed around stable identities and predictable lifecycles, while agents can combine human permissions, their own credentials, and JIT approvals in one run. That creates effective permissions that exceed what static role models usually describe.

Q: How can teams tell whether AI access is actually under control?

A: Look for evidence that access is limited by purpose, not just by account. If you can show which data the system can reach, which actions it can trigger, and how policy changes when the use case changes, you have real governance. If you only have sign-off at deployment time, control is still mostly theoretical.

Q: What is the difference between human identity governance and NHI governance for AI tools?

A: Human identity governance assumes a person, a manager, and a clear employment lifecycle. NHI governance has to manage credentials, tokens, bots, and agents that can appear instantly, change scope quickly, and outlive the original use case if no one explicitly retires them.

Technical breakdown

Why effective permissions matter more than account counts

AI agents do not behave like ordinary service accounts. They can inherit user permissions, keep their own credentials, or combine both within the same workflow. That means the relevant question is not how many identities exist, but what each identity can actually do across data, tools, and delegated approvals. Once agents can request JIT permissions mid-run, the security boundary becomes the effective permission set at execution time, not the nominal entitlement on paper.

Practical implication: Measure and govern effective permissions for agent identities, not just the identities themselves.

Why CSPM and DSPM stop short for agentic systems

CSPM focuses on configuration posture and DSPM focuses on data at rest, but AI agents create risk through runtime relationships. The article points to the need to map data pipelines, prompt inputs, RAG sources, and external tool connections because those links determine what an agent can touch and how far an action can spread. Without identity context, posture tools can miss the access paths that matter most.

Practical implication: Add identity-aware access mapping to posture workflows so runtime agent paths are visible.

How MCP changes the trust boundary for AI agents

Model Context Protocol extends an agent’s reach to external systems through connected servers, which act as bridges to tools and data. That bridge can also become an attack surface when the server is compromised, malicious, or over-permissioned. In practice, MCP turns integration design into identity design because the trust boundary now includes the permissions, context, and execution rights exposed through the connection itself.

Practical implication: Treat MCP-connected tools as governed identity endpoints, not just integration plumbing.

Threat narrative

Attacker objective: The attacker wants to turn a single AI agent identity into a high-reach execution path for data exposure, misuse of tools, or broader compromise.

1. Entry occurs when an attacker influences the agent environment through poisoned training data, tainted context, or a compromised MCP-connected tool. Those inputs shape what the agent can see and do during execution.
2. Escalation happens when the agent inherits human permissions or requests additional JIT access during a run, expanding the effective blast radius beyond the original task.
3. Impact follows when the agent performs unauthorized reads, tool actions, or data exposure at machine speed across the connected enterprise data ecosystem.

Breaches seen in the wild

• DeepSeek database exposure 2025: An unauthenticated DeepSeek ClickHouse database exposed over a million log lines with plaintext chat history and API keys in 2025.
• LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.

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 agent identity risk is a control-model problem, not just a new workload category. The article is right to separate agentic systems from deterministic workloads because their permissions change with context, prompts, and task flow. That breaks the assumption that identity can be governed only through stable provisioning states. Practitioners need to treat agent behaviour as an execution-time governance problem, not a static account-management problem.

Access Graph is the right abstraction because effective permissions, not nominal entitlements, determine blast radius. A single graph that joins human identity, agent identity, data lineage, and tool access gives security teams the missing unit of analysis. This is especially important when an agent inherits a user’s rights in one step and uses its own credentials in another. Practitioners should align governance to the path of action, not the list of assigned roles.

Traditional NHI governance is necessary but insufficient when the identity can act non-deterministically. Service accounts, keys, and secrets remain relevant, but agentic systems add runtime choice about what to access next and which tool to use. That means the security assumption that least privilege can be fixed at provisioning time no longer holds cleanly. Practitioners must reframe privilege as something that can drift within a session, not just across a lifecycle.

Least privilege for agents now depends on controlling the permission inheritance chain. Human-on-behalf-of access, service-account access, and MCP-connected tool access can all stack into one execution path. The result is a governance problem that spans IAM, NHI, and application integration teams at the same time. Practitioners should expect responsibility to shift from identity issuance alone to continuous authorization oversight.

Named concept: agentic access graph. The article points toward a governance model that maps who or what can take which action on which data across human and non-human identities. That concept is valuable because it replaces fragmented inventory thinking with relationship-based control. Practitioners should use it to explain why agent identity security cannot be solved by a single legacy control domain.

From our research library:

• Only 23% of IT leaders were very confident in their organisation's ability to manage security and governance for GenAI deployments, according to a 2025 Gartner survey of 360 IT leaders.
• Read next: Ultimate Guide to NHIs — Key Challenges and Risks

What this signals

Agentic access graph: Identity teams need a relationship model that shows how human rights, agent credentials, RAG sources, and MCP-connected tools combine into one execution path. Without that graph, least privilege is only a provisioning statement, not a runtime control.

The control shift is from counting identities to proving what each agent can do at inference time. That is where legacy IAM, PAM, and posture tools stop being sufficient and where governance starts to depend on effective permissions across the full agent lifecycle.

AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026. That scale reinforces why agentic systems need identity controls that extend beyond the model itself.

For practitioners

• Map agent effective permissions Build a current-state view of what each agent can actually do across data sources, tools, and delegated human rights. Use that map to identify where nominal roles understate real blast radius.
• Classify agent trust paths Inventory every MCP-connected server, external tool, and data pipeline that an agent can reach. Mark which ones expand access during runtime versus which ones only surface existing data.
• Separate deterministic and agentic identities Do not govern agents as if they were ordinary service accounts. Distinguish predictable machine workloads from systems that can select actions and request new privileges during execution.
• Review JIT approval boundaries Check whether JIT permissions for agents create a false sense of control when access is granted mid-run and used immediately. Require review points that bind to execution scope, not just request approval.
• Limit permission inheritance Where agents operate on behalf of users, constrain how much of the user’s access they can inherit and where that inheritance can be forwarded into external tools or downstream systems.

Key takeaways

• AI agents create an identity problem that spans inherited permissions, their own credentials, and runtime tool use, which legacy control models do not fully capture.
• The practical risk is not just more identities, but more effective permissions across data pipelines, external tools, and JIT access paths.
• Identity programmes need to govern agent behaviour through relationship-based access visibility, not rely on human-era lifecycle assumptions alone.

Key terms

• Agentic Security Graph: A unified view of the identities, tools, APIs, data sources, and permissions that an AI agent can traverse. It shows the operational path from an agent’s action to the systems and records it can reach, which is essential for governing cross-platform risk.
• Effective Permissions: Effective permissions are the access an identity can actually use after role inheritance, scope, and policy are applied. In Azure AI environments, they often matter more than the assigned role name because inherited rights can widen access to data, logs, and secret stores.
• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Agentic Development Lifecycle: The Agentic Development Lifecycle is the control pattern for building, approving, deploying, and reviewing AI agents before they reach production. It extends software change discipline into identity governance by requiring traceability for creation, access grants, business purpose, and ongoing oversight.

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.