TL;DR: AI agents are becoming the dominant attack surface because they retrieve data, call tools, and take actions across enterprise systems, while legacy DLP, DSPM, and IAM controls were built for users and static workloads, according to Cyera. The core issue is not just visibility, but governance of non-human identities whose runtime decisions expand blast radius faster than review processes can keep up.
At a glance
What this is: Cyera argues that AI security is shifting from prompt scanning to data, identity, and runtime control as agents become the main enterprise attack surface.
Why it matters: For IAM, IGA, PAM, and NHI teams, the practical problem is that agent identities now need governance tied to data reach, tool use, and runtime behaviour, not just login rights.
By the numbers:
- The Cloud Security Alliance puts the ratio of NHIs to humans at 10x to 50x in most enterprises, and it's accelerating as agents scale.
👉 Read Cyera's analysis of the future of AI data security and agent risk
Context
AI agent identity risk is not the same problem as chatbot misuse. A chatbot waits for a prompt, but an agent can retrieve data, call tools, and take action across systems in one session, which means existing controls that assume a human user are already out of step with the behaviour being governed.
That shift matters to identity programmes because every agent behaves like a non-human identity with credentials, permissions, and a blast radius. Once the security question becomes what data the agent can reach and what it can do with that data, IAM, DSPM, and runtime enforcement stop being separate conversations and become one control problem.
Key questions
Q: How should security teams govern AI agents that can reach sensitive data?
A: Treat each agent as a non-human identity with explicit data reach, not just application access. Governance should connect credentials, allowed tools, reachable datasets, and runtime actions. If the agent can read, transform, and write sensitive information, the control objective is blast-radius reduction, not only authentication or inventory.
Q: Why do AI agents change identity governance requirements?
A: AI agents change governance because they do not merely hold access, they exercise it dynamically. That means privilege, intent, and data exposure can shift inside a single workflow. Periodic reviews and static role models can miss the actual risk unless runtime behaviour is tied back to identity and data.
Q: What breaks when DLP and DSPM are built only for users and files?
A: They miss the chain of authenticated actions that an agent performs across systems. A user-centric control can inspect a file or message, but it often cannot explain tool calls, retrievals, or downstream writes. That leaves the organisation with visibility into content, not into the identity that moved it.
Q: How do security teams know if agent governance is actually working?
A: It is working only if the team can answer three questions quickly for any agent: what it can reach, what it did recently, and whether that behaviour matches intent. If any of those answers require manual reconstruction, governance exists on paper but not in operations.
Technical breakdown
Why agent loops create a different security boundary
An AI agent does not just generate text. It can retrieve context, call tools, hand work to other agents, and write changes back into enterprise systems. That creates an execution loop that spans identity, data, and action. Traditional DLP and DSPM controls were designed to inspect files, messages, or repositories, not a chain of authenticated actions that mutates state across systems. The security boundary is therefore not the prompt. It is the full agent loop, including retrievals, tool calls, and downstream effects on data.
Practical implication: govern the full agent loop, not only prompt input and output.
Why non-human identity becomes the control plane
Cyera frames every AI agent as a non-human identity because it has credentials, an effective permission set, and a measurable blast radius. That is the right model for IAM, because the meaningful question is not whether the agent can authenticate, but what it can reach once authenticated. This is where NHI governance differs from human IAM. Human access is usually measured through roles and reviews. Agent access has to be understood through data reach, tool scope, and runtime intent. Without that mapping, identity controls cannot explain actual exposure.
Practical implication: tie each agent identity to the sensitive datasets and systems it can actually reach.
Why posture tools are converging with runtime controls
AI security posture management inventories models, datasets, vector stores, agents, and related infrastructure. That is useful, but posture alone does not stop unsafe action at runtime. The article points to a market shift from asset visibility to policy enforcement between the model and the data. In practice, that means runtime controls must inspect what the agent is about to do, not just what it asked for. The architectural direction is a control stack that links discovery, governance, protection, and proof across the same identity and data graph.
Practical implication: evaluate whether your stack can enforce policy before data is touched, not just report on assets.
Breaches seen in the wild
- Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
- Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
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 are now the most important non-human identity problem because their permissions have operational consequences, not just access consequences. The article is right to move the centre of gravity away from prompt safety and toward identity and data reach. Once an agent can retrieve, decide, and act, the question is not whether it logged in, but how far its authority extends at runtime. For practitioners, this means NHI governance must be measured in reachable data and executable actions, not only credential inventory.
Discovery without runtime proof is only a partial control. The article's AI-SPM and DSPM convergence point is structurally sound, but it also exposes a familiar failure mode: organisations can build a better list of assets without reducing actual exposure. A named concept here is agent blast-radius mapping, which means tying each agent to the specific data and systems its tools can touch. That concept is now central to OWASP-NHI and ZT-NIST-207 alignment. Practitioners should treat any posture view that cannot prove blast radius as incomplete governance.
The governance assumption that access is stable long enough to be reviewed is already under pressure from agentic behaviour. That assumption was designed for identities whose privilege state persists across a review cycle. It fails when an agent can assemble context, call tools, and complete work in one runtime loop, because the meaningful access event may begin and end before any certification process can observe it. The implication is that identity review models built for periodic observation are missing the object they claim to govern.
Security programmes that separate IAM, DSPM, and AI governance are creating their own blind spots. The article's strongest signal is not that AI needs a new product category, but that existing control ownership models are fragmented around the wrong abstraction. If the identity, the data, and the runtime action are not governed together, no team can answer what an agent can reach, what it has done, or whether that matches intent. Practitioners should treat convergence as a governance requirement, not an organisational preference.
The market is moving toward runtime policy enforcement because static analysis no longer matches agent behaviour. Prompt scanning is already commoditising, which pushes differentiation toward enforcement, traceability, and data-aware control decisions. That direction validates zero trust thinking for machines, but only when the control plane can see the identity, the data, and the action in one frame. Practitioners should expect vendor claims to shift from visibility to enforcement and should test accordingly.
From our research:
- 69% of organisations now have more machine identities than human ones, according to The Critical Gaps in Machine Identity Management report.
- 57% of organisations lack a complete inventory of their machine identities, which is why discovery alone is not yet governance.
- For a forward view on where NHI and agent identity controls are heading, read Ultimate Guide to NHIs , 2025 Outlook and Predictions.
What this signals
Agent blast-radius mapping: the next phase of AI governance is less about flagging unsafe prompts and more about proving which data, tools, and write paths an agent can actually touch. With 66% of organisations saying their current tooling is not adequate to manage the scale of machine identities they now have, according to The Critical Gaps in Machine Identity Management report, the operational gap is already visible. Teams should expect audit questions to move from model provenance to runtime authority.
That shift will force IAM and DSPM owners to share a common view of identity, entitlement, and data exposure. The organisations that can answer those questions quickly will be able to govern both human and non-human access with the same operating model, while everyone else will keep chasing disconnected inventories.
For practitioners
- Map each agent to its reachable data Create an inventory that links every agent, model, and workflow identity to the sensitive datasets, APIs, and systems it can reach. Do not stop at application ownership or login records.
- Separate prompt inspection from runtime policy Test whether your controls can evaluate retrievals, tool calls, and agent-to-agent handoffs before the action completes. Prompt scanning alone does not stop unsafe use of sensitive context.
- Use blast-radius questions in access reviews Ask what data the agent can touch today, what it touched in the last 24 hours, and whether that remains consistent with its intended purpose. If you cannot answer quickly, your review model is too slow for the identity type.
- Treat endpoint telemetry as part of AI governance Include browser extensions, local code access, and developer tooling in your control scope, especially where agents run on laptops and use human credentials to call APIs or write files.
Key takeaways
- AI agents turn identity governance into a runtime problem because they can retrieve data, choose actions, and change state across systems in one loop.
- The evidence points to scale pressure already outpacing existing controls, with machine identities now exceeding human identities in most organisations.
- Practitioners need governance that ties each agent to reachable data, tool scope, and observable actions, or reviews will miss the real exposure.
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 address the attack and risk surface, while NIST Zero Trust (SP 800-207) and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Agent credentials and blast radius are central to this article's governance model. |
| NIST Zero Trust (SP 800-207) | PR.AC-4 | Continuous verification is needed when agent access and behaviour change at runtime. |
| NIST CSF 2.0 | GV.OV-01 | AI governance must span identity, data, and runtime decisions across teams. |
Inventory every agent identity and bind it to its allowed data, tools, and ownership.
Key terms
- Agent Blast Radius: The set of data, systems, and actions an AI agent can affect if its behaviour is unsafe, compromised, or misconfigured. In practice, it is the security boundary that matters when identity, tool use, and data access converge at runtime.
- Runtime Policy Enforcement: A control pattern that evaluates and applies security decisions while the agent is executing, not only when it is configured or scanned. It is essential when the actor can retrieve context, call tools, and mutate state without waiting for human review.
- Non-Human Identity: A machine or software identity that authenticates and acts without a human being directly operating each step. For AI agents, this includes credentials, permissions, ownership, and lifecycle controls that must be managed as rigorously as human access.
- AI Security Posture Management: A governance approach for discovering and tracking AI assets such as models, agents, datasets, vector stores, and related infrastructure. It becomes useful only when inventory is connected to runtime exposure and the identity that can actually reach the data.
Deepen your knowledge
AI agent governance, data reach, and non-human identity controls are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building an operating model for agents that act on sensitive data, it is worth exploring.
This post draws on content published by Cyera: The Future of AI Data Security: Trends, Tools, and Technologies to Watch. Read the original.
Published by the NHIMG editorial team on 2026-05-21.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org