AI agents are breaking data security controls built for humans

At a glance

What this is: Cyera argues that AI agents break the human-centric assumptions behind current data security and identity controls, especially where permissions, visibility, and enforcement are still static.

Why it matters: For IAM practitioners, the issue is not just AI adoption but control design: agentic behaviour changes how access is granted, observed, and contained across NHI, autonomous, and human identity programmes.

By the numbers:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.

👉 Read Cyera's analysis of how AI agents are breaking data security controls

Context

AI agent identity risk is emerging because the controls most enterprises rely on were designed for human users, not software actors that decide, act, and chain tool calls at runtime. In practice, that means the old model of authenticate a user, then authorize a request, no longer matches how agents reach sensitive data or systems.

The governance gap shows up first in visibility and then in enforcement. If an agent inherits permissions, moves across APIs, and reasons over data in context, security teams need to understand the agent's effective blast radius, not just the files it touched or the role it was assigned.

Key questions

Q: How should security teams govern AI agents that can call tools and access data on their own?

A: Treat each agent as a governed identity with a defined purpose, effective permissions, and a measured blast radius. Security teams should enforce policy at the tool layer, continuously reconcile actual behaviour against intended use, and keep inventories current across platforms, endpoints, and browser-based tools. Static approval lists are not enough once agents act at runtime.

Q: Why do AI agents complicate IAM and data security controls?

A: Because the core controls were built for human sessions and file-centric data movement, while agents act continuously, inherit permissions, and reason over data in context. That breaks the assumptions behind IAM, ITDR, DSPM, and DLP. The practical result is false confidence unless teams govern permissions, context, and action paths together.

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: Who is accountable when an AI agent accesses sensitive data it was not meant to use?

A: Accountability sits with the team that approved the agent, its connectors, and its policy boundaries, not with the runtime behaviour alone. Organisations need ownership for intent, permissions, monitoring, and validation so they can prove whether the agent stayed inside its approved purpose. Without that, audit and regulatory response become retrospective guesswork.

Technical breakdown

Why human identity controls misread agent behaviour

Traditional IAM and ITDR systems are built to interpret sessions through a human lens. SSO, MFA, roles, and provisioning assume a person logs in, performs bounded work, and leaves behind a trace that can be reviewed later. Agents do not behave that way. They can act 24/7, burst through thousands of API calls, inherit permissions from creators, and trigger alerts that look like compromised accounts. The result is signal collapse: legitimate agent activity becomes indistinguishable from malicious automation unless controls understand purpose, tool use, and runtime context.

Practical implication: map each agent to an identity model that includes purpose, effective permissions, and expected action patterns, not just a user-like login record.

How agentic workflows defeat data-state thinking in DSPM and DLP

DSPM and DLP were created to find data at rest and control where it moves. AI agents add a different failure mode because they can retrieve sensitive data, hold it in context, transform it, and act on it elsewhere without moving a file in the traditional sense. That breaks file-centric inspection. The security question becomes whether an agent is allowed to reason over data at all, in which tools, and under which conditions. Context becomes the control surface, not just storage location or transmission path.

Practical implication: extend data governance to agent context, prompt content, connector scope, and downstream tool actions instead of relying on file movement alone.

Policy enforcement inside the loop for AI agent access control

The article's most operational point is that scanning prompts and responses is not enough. Real protection sits between the agent and the action, where a tool call can be blocked before execution, sensitive context can be redacted, and prompt injection embedded in retrieved content can be detected. This is a runtime control problem, not a post hoc review problem. The security model has to consider the intent behind the agent's task, the permissions it can exercise, and the data residency or policy rules that apply when it is about to act.

Practical implication: enforce policy at the moment of tool invocation, not only at the user request or content inspection layer.

Threat narrative

Attacker objective: The objective is to turn legitimate agent access into unauthorized data reach and action without triggering the controls that were built for human sessions.

1. Entry occurs when an agent is provisioned with inherited permissions from a human creator, a platform connector, or a browser-based tool registry that was never fully audited. The initial access is legitimate, which is why traditional compromise indicators miss it.
2. Escalation happens when the agent uses those permissions to read sensitive data, call tools, and act across systems in ways that exceed its stated purpose. The behaviour can look normal to the platform while still violating governance boundaries.
3. Impact follows when the agent reaches data or systems outside its intended envelope, creating unauthorized exposure, data movement through context, and actions that no reviewer can reliably reconstruct after the fact.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

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

NHI Mgmt Group analysis

Human-centric IAM assumptions are collapsing under agentic runtime behaviour. SSO, MFA, roles, and provisioning were designed for identities that authenticate, act within bounded human workflows, and stop. Agents are faster, more persistent, and more distributed than the controls that were built to govern them. That means the problem is not only coverage, but premise: the control stack assumes a person is behind every meaningful action. Practitioners should treat agent identity as a separate governance surface, not a variant of user IAM.

Context, not file movement, is becoming the real data-security boundary for agents. DSPM and DLP still matter, but they are insufficient when an agent can retrieve data, keep it in context, and act on it without moving a document in a detectable way. This is the identity-data coupling problem: access and reasoning now happen in the same runtime. Identity blast radius: the effective set of data, tools, and systems an agent can reach once its context and permissions are combined. Security teams should measure that blast radius directly.

Policy enforcement must move from inspection to execution control. The article's strongest architectural claim is that prompt scanning alone cannot stop harmful agent behaviour. Blocking a tool call before it executes, redacting sensitive context, and detecting injected instructions inside retrieved content are runtime controls, not review controls. For practitioners, this shifts AI security from content filtering toward policy enforcement at the action layer, which is where most agent risk actually materializes.

Given the scale of AI agent adoption, weak governance is already a programme-level exposure. According to AI Agents: The New Attack Surface, 98% of companies plan to deploy even more AI agents within the next 12 months. That makes continuous governance a baseline requirement, not a future enhancement. The practical conclusion is straightforward: if agent inventory, intent, and effective permissions are not continuously reconciled, the security programme is already behind the runtime it is supposed to govern.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• For the broader control pattern, the Ultimate Guide to NHIs explains how lifecycle and blast-radius controls must evolve when non-human identities outgrow human-centric governance.

What this signals

Identity blast radius will become a standard design lens for AI governance because agents can inherit permissions, retain context, and act across systems faster than review cycles can respond. Programme owners should expect more pressure to prove not just who approved an agent, but what that agent could actually reach at the moment it acted.

With 52% of companies able to track and audit the data their AI agents access, the operational divide is already visible: half the market can evidence behaviour, half cannot. That gap matters because auditability is now a core control, not a reporting extra, and it will increasingly shape procurement, assurance, and incident response maturity.

The next governance step is to tie agent runtime behaviour to existing identity and zero-trust patterns using resources such as the Ultimate Guide to NHIs and NIST AI Risk Management Framework. Security teams that treat agents as just another automation layer will miss the action-layer control problem entirely.

For practitioners

• Inventory agent identities continuously Track every native, self-hosted, endpoint, and browser-based agent through platform APIs, network telemetry, OAuth signals, and endpoint mapping. Do not rely on self-reported spreadsheets or static inventories, because they miss unmanaged agents and shadow AI.
• Define effective permissions and purpose for each agent Record what each agent was built to do, what tools it can call, and which datasets it can actually reach. Compare stated intent to effective permissions so teams can spot when an agent's real blast radius exceeds its purpose envelope.
• Enforce policy at the tool-call layer Block or redact actions before execution when a tool call would violate data residency, access scope, or content handling rules. The control point has to sit inside the loop, because post-execution review does not prevent agent misuse.
• Validate controls with automated red-teaming Probe agents with prompt injection, jailbreaks, exfiltration attempts, and out-of-policy tool calls, then retain evidence that the guardrails held. Use those results to support audit, board reporting, and regulator readiness.
• Rebuild review cadence around runtime behaviour Replace static point-in-time reviews with continuous checks that reconcile the agent's actual actions against its approved intent. If the behaviour changes faster than the review cycle, the governance model is too slow.

Key takeaways

• AI agents break the assumption that identity controls can be built around human-paced sessions and file-based data movement.
• The scale of exposure is already material, with 80% of organisations reporting agents that have acted beyond intended scope.
• The practical answer is runtime governance, continuous inventory, and execution-layer policy enforcement rather than static review alone.

Key terms

• Agent Identity: An agent identity is the security representation of a software actor that can read data, call tools, and take action at runtime. Unlike a human user, its access must be evaluated through purpose, tool scope, and actual behaviour rather than login events alone.
• Identity Blast Radius: Identity blast radius is the full set of data, tools, APIs, and systems an identity can reach when its permissions, context, and runtime behaviour are combined. For agents, it is often larger than the assigned role suggests and must be measured continuously.
• Runtime Policy Enforcement: Runtime policy enforcement means blocking or constraining an identity's action at the moment it tries to execute, rather than reviewing the action after the fact. For agents, this is the control point that prevents unsafe tool calls, data exposure, and policy drift.
• Shadow AI: Shadow AI is the use of AI agents or tools that security and governance teams have not discovered, approved, or monitored. It creates hidden identity risk because access, data use, and action paths exist outside the normal inventory and review process.

Deepen your knowledge

AI agent governance and identity blast radius are covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for agents that can act across tools and data, it is a strong starting point.

This post draws on content published by Cyera: AI Agents are breaking data security, here's how to fix it. Read the original.