AI agent growth is exposing the limits of data security controls

At a glance

What this is: Cyera frames AI and data security around the growing challenge of securing AI agents, with its own metrics showing large-scale discovery, classification, and protection activity across enterprise environments.

Why it matters: IAM, NHI, and security teams need to treat AI agents as governed identities because their access patterns, data interactions, and control surfaces can outgrow traditional review, classification, and privilege models.

By the numbers:

• 76% say autonomous AI agents are the hardest to secure, according to Cyera Research Lab's 2025 AI Data Security Readiness report.
• Cyera says it has helped enterprises protect more than 530 million identities.

👉 Read Cyera's announcement on AI and data security growth

Context

AI agent security is becoming a governance problem, not just a tooling problem. As agents gain access to data, prompts, and downstream systems, the identity question shifts from who logged in to what runtime entity is allowed to act, read, and generate.

Cyera's announcement is a useful signal because it ties data security, identity visibility, and AI control into one operating model. For IAM and NHI programmes, the practical issue is whether current governance can keep pace with autonomous access patterns, especially where data sensitivity and action scope overlap.

Key questions

Q: How should security teams govern AI agents that access sensitive data?

A: Start by treating each agent as a governed non-human identity with explicit ownership, scope, and telemetry. Then tie its permissions to the sensitivity of the data it can reach, not just to the system it runs in. The goal is to prove why the agent is allowed to touch that data and detect when its behaviour drifts outside the approved purpose.

Q: Why do autonomous AI agents complicate least privilege?

A: Least privilege becomes harder to define when the actor can choose actions at runtime and change tool use within a task. The entitlement model may be correct on paper but still fail in practice because the real risk is not the stored permission alone, it is how the agent combines access, data, and execution timing.

Q: What do security teams get wrong about AI agent data risk?

A: They often focus on the data store and miss the identity of the actor interacting with it. An exposed dataset is not the only issue. The same data can become materially riskier when an autonomous agent can query, summarise, or act on it without enough governance context to justify that use.

Q: How can organisations tell whether AI agent governance is working?

A: Look for evidence that every agent has an owner, a defined purpose, a current access map, and usable telemetry showing what it actually did. If you cannot explain who approved the agent, what data it touched, and whether those interactions were expected, the control model is not yet working.

Technical breakdown

AI agent identity and data access boundaries

AI agents create a different control surface from human users or static service accounts because they can interact with data at runtime, often across multiple systems and contexts. In practice, that means access cannot be evaluated only at provisioning time. Security teams need visibility into which agents exist, what data they can reach, and whether the interaction is appropriate for the task, because the risk is not just access but action taken on that data.

Practical implication: maintain a live inventory of agent identities and map each one to the data classes it can touch.

DSPM, DLP, and identity convergence

Data security posture management discovers where sensitive data lives, DLP constrains how it moves, and identity governance defines who or what may interact with it. When these controls are separate, AI agents can slip through the gaps because identity context is missing from data controls and data sensitivity is missing from identity controls. The technical issue is not one product category, but fragmented control ownership.

Practical implication: align identity and data control decisions around the same asset classification and access model.

Why autonomous agents create a different review problem

Autonomous AI agents are harder to govern because their access is often dynamic, task-driven, and short-lived. That changes how least privilege is assessed, since the actor may select actions and data at runtime rather than following a fixed workflow. Traditional recertification models assume stable entitlements, but agent behaviour can shift within a session, making the review artifact obsolete before it is checked.

Practical implication: treat agent runtime behaviour as a control signal, not just entitlement records.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

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 governance is now an identity and data problem at the same time. The article's own numbers show that enterprises are already discovering millions of agents and protecting hundreds of millions of identities, which means the control boundary is no longer a single system or team. Data security tools that do not understand identity context, and identity tools that do not understand data sensitivity, will both miss the real exposure. Practitioners should treat agent governance as a shared operating model across IAM, NHI, and data security.

Autonomous AI agents break the assumption that access can be certified after the fact. Access review was designed for conditions where entitlements persist long enough to be observed, logged, and re-approved. That assumption fails when the actor is autonomous because access selection and execution can shift at runtime, inside the same task window. The implication is that review cadences built for stable identities do not describe the actual risk surface.

Data classification now has to account for the identity of the actor using the data. The announcement links 97% precision in classification with immediate insight into which AI models and agents interact with data, which is the right direction conceptually. The broader lesson is that data sensitivity alone is no longer enough. A secret, prompt, or record can carry different risk depending on whether a human, service account, or autonomous agent is the one touching it. Practitioners should move toward identity-aware data governance.

AI agent scale makes control fragmentation more dangerous, not less. Once an environment contains thousands of agents, fragmented oversight across DLP, DSPM, IAM, and business teams becomes a structural weakness. The industry is entering a phase where the main question is not whether agents will exist, but whether the organisation can explain their access and prove why it is acceptable. That is a governance maturity test, not a feature checklist.

Named concept: runtime identity-data coupling. The useful concept here is that AI agent risk is created by the coupling of runtime identity and data movement, not by either one alone. When the actor can choose actions against sensitive data during execution, the security model must evaluate both identity intent and data context together. Practitioners should expect this to become a standard design assumption for AI governance programmes.

From our research:

• 76% say autonomous AI agents are the hardest to secure, according to the 2025 AI Data Security Readiness report.
• From our research: When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• For a broader view of how AI-era identity risk changes governance priorities, see Ultimate Guide to NHIs , 2025 Outlook and Predictions.

What this signals

Runtime identity-data coupling: the governance challenge is not just whether AI agents can access data, but whether the organisation can explain why that access was acceptable at the moment it happened. That requires identity, data classification, and telemetry to be evaluated together, not in separate programmes.

The practical signal for IAM and NHI teams is that agent inventories and data maps must converge quickly, or policy will be enforced against incomplete context. Cyera's scale claims suggest enterprises are already moving in that direction, but the broader market signal is that autonomous actors are making control fragmentation visible faster.

With 4M agents already discovered and secured in Cyera's customer base, the category is moving from experimental oversight to operational governance. Teams that still treat AI access as an edge case will find their review processes lagging behind the pace of deployment.

For practitioners

• Inventory every AI agent identity Maintain a continuously updated register of agents, the systems they can reach, and the data classes they are allowed to access. Include both sanctioned and shadow AI so that governance is based on runtime reality rather than assumed architecture.
• Bind data classification to identity context Link sensitive data labels to the human, workload, or agent identity that is interacting with the data so policy can distinguish approved use from unacceptable exposure. This is especially important where prompts, records, and downstream actions intersect.
• Review autonomous access as runtime behaviour Use telemetry from agent sessions, tool calls, and data interactions to decide whether access stayed within scope. Do not rely only on entitlement snapshots, because they often miss the behaviour that creates the actual risk.
• Unify IAM, DSPM, and DLP governance Assign shared ownership for agent access decisions across identity and data teams so control gaps do not form between classification, privilege assignment, and enforcement. The objective is one policy model for the same actor across all layers.

Key takeaways

• AI agents turn data security into an identity governance problem because runtime behaviour now matters as much as stored entitlement.
• Cyera's own figures show enterprise scale is already large enough that fragmented control ownership will miss real exposure.
• Practitioners should unify identity, data, and runtime telemetry before agent populations outgrow manual review models.

Key terms

• Ai Agent Identity: An AI agent identity is the runtime identity used by software that can decide actions, select tools, and execute tasks without a human stepping through every move. In governance terms, it must be owned, scoped, monitored, and reviewed like any other high-risk non-human identity.
• Runtime Identity-Data Coupling: Runtime identity-data coupling describes the security relationship between who or what is acting and the data being touched at that moment. It matters because the same dataset can present different risk depending on whether a human, workload, or autonomous agent is using it in session.
• Shadow AI: Shadow AI is AI use that exists outside approved governance, inventory, or control processes. It can include unsanctioned agents, unmanaged model connections, or hidden prompt workflows, and it usually becomes visible only after data or access oversight fails.

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 trying to connect data security, access control, and autonomous behaviour in one programme, it is a practical place to start.

This post draws on content published by Cyera: Cyera becomes one of the top 10 fastest-growing companies, powering the new era of AI and data security. Read the original.