AI data leakage in agents exposes a new identity governance gap

At a glance

What this is: The article argues that AI data leakage is driven by agentic workflows that move sensitive information across tools, contexts, and logs without sufficient control.

Why it matters: For IAM and NHI practitioners, this means access governance must extend beyond human users to agents, retrieval paths, and tool-level permissions.

👉 Read CrowdStrike's analysis of AI data leakage in agentic systems

Context

AI data leakage is not just a content problem, it is an access problem. In agentic systems, autonomous software can retrieve, transform, and forward sensitive data across multiple tools in a single workflow, which means traditional IAM controls often lose sight of where authority starts and stops for each non-human identity.

CrowdStrike frames the risk around prompts, logs, retrieval layers, and API calls because those are the places where sensitive data is most likely to move outside its intended boundary. That is a familiar pattern for NHI governance: once machine identities can chain actions, the main question becomes whether controls can still enforce least privilege at runtime.

Key questions

Q: How should security teams control AI agents that can move data across multiple systems?

A: Security teams should treat each agent as a non-human identity with bounded scope, explicit permissions, and continuous logging. The agent should only access the tools needed for the current task, and every tool call should be recorded as an identity action. When possible, separate high-risk data sources from general-purpose workflows so one agent cannot freely bridge sensitive contexts.

Q: Why do AI agents create more leakage risk than traditional applications?

A: AI agents can decide which tools to use, chain actions, and carry context forward without a human approving each step. That makes the exposure path dynamic instead of fixed. Traditional applications usually have clearer transaction boundaries, while agents can read from one system, transform the data, and write it into another before policy catches up.

Q: What is the difference between data protection in LLMs and data protection in agentic AI?

A: LLM data protection focuses on what enters and leaves a model response. Agentic AI protection must also cover what the agent retrieves, stores in context, forwards to tools, and leaves behind in logs or memory. The second problem is broader because the non-human identity can act across multiple systems, not just generate text.

Q: When should organisations tighten controls around AI assistants?

A: Controls should tighten as soon as an assistant can access internal data, invoke tools, or write to downstream systems. That is the point where the assistant stops being a text interface and starts behaving like an identity with execution authority. The more sensitive the data, the more important it is to enforce short sessions, scoped permissions, and explicit review.

Technical breakdown

Why agentic workflows create data leakage paths

Agentic AI differs from a static model because it can choose tools, query systems, and chain actions based on intermediate results. That creates a dynamic trust boundary. A single request may touch a document store, a database, an API, and a log pipeline, while each step inherits context from the prior one. If access checks are applied only at the front door, the agent can still move data into places where it should not land. The real failure mode is not one model response. It is the accumulation of valid actions by a non-human identity that was never designed for broad, stateful access.

Practical implication: Treat each tool call as an access event that needs scope, logging, and revocation logic.

How retrieval and context storage bypass familiar controls

Retrieval-augmented generation and context memory can strip away or weaken the original access metadata that protected a document or record. Once data is embedded, chunked, or cached, the authorization decision may no longer follow it cleanly. That is why sensitive information can reappear in outputs, logs, or shared context even when the source system was protected. From an NHI perspective, the problem is not only who can call the agent, but what the agent is allowed to preserve, reuse, and propagate after retrieval.

Practical implication: Preserve source authorization signals through retrieval, storage, and output handling wherever possible.

Why logs, training data, and downstream APIs matter

Debug logs, audit trails, and training datasets can become durable leak points because they often capture raw prompts, responses, or intermediate artifacts. Downstream APIs add another layer of exposure when an agent forwards sensitive material into another system without re-evaluating policy. These paths are especially risky because they look operational, not malicious. They also create governance blind spots: teams may protect the source application while leaving the observability and integration stack outside the control model.

Practical implication: Classify logs, training sets, and integration endpoints as first-class exposure surfaces, not back-office systems.

Threat narrative

Attacker objective: The attacker objective is to exfiltrate sensitive data by abusing agentic workflows that move information across trusted systems.

1. Entry occurs when users feed sensitive content into an AI assistant or when an agent receives access to connected tools and data sources.
2. Escalation happens when the agent chains retrieval, context storage, and API calls, carrying data across systems that were not intended to share it.
3. Impact appears when sensitive prompts, credentials, or business records surface in responses, logs, downstream systems, or training artifacts.

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 data leakage is now an NHI governance problem, not just an application security problem. The article shows that agents can access and move data in ways that traditional user-centric IAM does not fully model. Once execution authority is delegated to software, the question becomes how to govern scope, context, and persistence across machine actions. Practitioners should treat agent identity as a policy boundary, not a convenience layer.

Ephemeral access does not eliminate trust debt in agentic systems. Short-lived credentials reduce exposure time, but they do not solve the deeper issue of what the agent is allowed to see, chain, and retain during its session. If contextual data can be copied into logs, memory, or downstream calls, the risk persists after the token expires. The right control objective is to shrink the identity blast radius, not just the credential lifetime.

Retrieval pipelines need policy continuity from source to output. When access control metadata falls off during embedding, chunking, or caching, the system can no longer answer a simple governance question: who is allowed to see this information now? That gap is where leakage becomes systemic. Practitioners should design for policy continuity across retrieval, generation, storage, and export.

The operational unit of control is the tool invocation. Each API call, database lookup, or log write made by an agent should be governed as an auditable identity action with explicit scope. Without that discipline, teams end up reviewing model behavior after the fact instead of constraining execution before harm occurs. The practical conclusion is to govern agents as active identities with bounded authority.

Identity blast radius: this article reinforces that the greatest risk comes from how far a single non-human identity can move data once it is trusted. That is a structural control issue, not an isolated prompt issue. Organisations should re-evaluate whether their current access model can survive autonomous chaining.

From our research:

• 88% of security professionals are concerned about secrets sprawl, with 49% of those in larger organisations described as "very concerned", according to The 2024 State of Secrets Management Survey.
• Only 44% of organisations are currently using a dedicated secrets management system, according to the same survey.
• For a broader control model, see the NHI Lifecycle Management Guide for provisioning, rotation, and offboarding practices that reduce long-lived access risk.

What this signals

Agentic AI widens the NHI governance surface faster than most programmes can inventory it. When a system can retrieve data, call tools, and persist context in one workflow, the security problem becomes identity sprawl with execution authority. That is why teams should track not only human access reviews but also connector sprawl, service account ownership, and session boundaries across AI workflows.

The control gap will increasingly show up in logs, caches, and downstream integrations rather than in the model itself. Teams that already struggle with secrets handling should assume AI adoption will amplify those weaknesses, especially where sensitive prompts and responses are retained for troubleshooting or analytics. The practical response is to align AI telemetry with the NHI Lifecycle Management Guide and to use the NIST Cybersecurity Framework 2.0 to map ownership, monitoring, and response responsibilities.

Identity blast radius: the key design question is how far an agent can move data once it has been trusted. With 88% of security professionals already concerned about secrets sprawl, per our 2024 survey, AI programmes should expect the same sprawl to appear in contextual memory and tool integrations unless they constrain scope from day one.

For practitioners

• Classify agent tool calls as identity events Log each database query, API call, retrieval action, and outbound write as an auditable non-human identity event with scope and purpose recorded.
• Preserve authorization through retrieval Carry source permissions and sensitivity labels into vector stores, caches, prompts, and generated outputs so access decisions do not disappear after ingestion.
• Segment high-risk data paths Separate prompts, logs, memory stores, and downstream integrations for finance, HR, customer, and secret-bearing workflows so one agent cannot freely traverse all contexts.
• Limit session scope and replay risk Use short-lived credentials, explicit session boundaries, and re-authentication for high-impact actions so agents cannot keep working with stale authority.
• Review AI integrations with NHI controls Map every agent, connector, and service account to an owner, a purpose, and a review cycle, then align that inventory with the NHI Lifecycle Management Guide and the OWASP NHI Top 10.

Key takeaways

• AI data leakage in agentic systems is primarily an identity and access problem because non-human identities can chain tools, contexts, and outputs across multiple systems.
• Traditional model-level controls are insufficient if retrieval, logs, memory, and downstream APIs are allowed to bypass policy continuity.
• Practitioners should reduce identity blast radius with scoped permissions, short sessions, and auditable tool-level controls before AI adoption expands further.

Key terms

• Agentic AI: Agentic AI is software that can plan and execute tasks with tool access rather than only generating text. In security terms, it behaves like a non-human identity with delegated authority, which means its permissions, logging, and revocation must be governed like any other active system identity.
• Identity Blast Radius: Identity blast radius is the amount of damage a single identity can cause if it is misused, overprivileged, or compromised. For AI agents and other non-human identities, it measures how far access, data movement, and downstream actions can spread before controls stop them.
• Retrieval-augmented Generation: Retrieval-augmented generation is a pattern where an AI model pulls external information before generating output. The security challenge is that access rules can weaken when data is chunked, embedded, cached, or reused, so source permissions may not automatically follow the content into the model's context.
• Tool Invocation: Tool invocation is an action where an AI agent calls an external system such as a database, API, or file service. Each invocation should be treated as an auditable identity action because it is the point where the agent can move data, trigger changes, or widen its reach across the environment.

Deepen your knowledge

AI data leakage in agentic systems is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for agents that can retrieve, store, and forward sensitive data, this course is a practical starting point.

This post draws on content published by CrowdStrike: Data Leakage, AI's Plumbing Problem. Read the original.