AI data leakage in agents exposes a new identity governance gap

At a glance

What this is: This is CrowdStrike’s analysis of how AI agents can leak data by chaining tool calls, crossing context boundaries, and bypassing the access assumptions that traditional controls rely on.

Why it matters: It matters because IAM and governance teams need to treat agent behaviour, tool access, and data movement as one control problem across NHI, autonomous, and human-driven workflows.

Context

AI data leakage in agentic systems is not only a content problem. When an AI agent can decide which databases, APIs, and tools to use during a live session, it can move information in ways that traditional access models did not anticipate.

The governance gap is that many controls still assume data stays attached to a stable identity boundary or a fixed workflow. In practice, agent-driven retrieval, chaining, and logging can break that boundary and expose sensitive data through ordinary operational paths.

CrowdStrike’s analysis frames this as an identity and access issue as much as a data protection issue. For practitioners, the important question is not just what the model can see, but what the agent can do with that data once it starts acting across systems.

Key questions

Q: What breaks when AI agents chain access across tools and services?

A: The original approval no longer describes the effective access path. Each individual hop may look legitimate, but the combined chain can extend privilege beyond what the organisation intended. The failure is visibility across the delegation chain, not just at the first credential issuance point.

Q: Why do agent prompts and logs create governance risk?

A: Because they often preserve sensitive content outside the original source boundary. Prompts can contain private inputs, logs can capture plaintext outputs or retrieved records, and context stores can extend the life of information beyond the intended session. That creates a retention and replay problem that classic IAM alone does not solve.

Q: How should security teams reduce data exposure before connecting enterprise data to AI tools and agents?

A: Security teams should first inventory data, classify what is sensitive, and identify where it is exposed, over-permissioned, or publicly accessible. That foundation lets teams apply controls to the data most likely to create AI risk. The practical goal is to reduce blast radius before agents inherit access, while keeping visibility strong enough to support remediation and governance.

Q: What is the difference between model access and agent access?

A: Model access is about what the LLM can process, while agent access is about what a runtime system can do with that information across tools, APIs, and storage layers. The model may only infer, but the agent can act, chain, and persist data. That is why agent governance must include identity, privilege, and data lineage.

Technical breakdown

Why agentic data flows defeat static access assumptions

Agentic systems are not just LLMs with extra tools. They can select actions at runtime, call multiple systems in sequence, and pass intermediate results into shared context or downstream APIs. That creates a moving data path that is hard to pre-authorise because the exact sequence is decided during execution. In governance terms, the access decision is no longer made once at provisioning time. It is repeated implicitly every time the agent chooses a tool, which means the control surface is distributed across prompts, tool permissions, and context handling rather than sitting in one policy layer.

Practical implication: treat tool invocation paths as governed access paths, not just application logic.

How prompts, logs, and context storage become leakage points

Data leakage in AI systems often happens after the initial request, not at the moment of access. Prompts may contain sensitive inputs, logs may capture plaintext conversations or retrieved records, and context stores may persist data beyond the intended session boundary. When the same information is copied into multiple places, the security model shifts from one guarded repository to several weaker retention points. This is why data minimisation, sanitisation, redaction, and scoped logging matter in AI systems. The problem is not only disclosure to users, but accidental persistence in places that are easy to overlook during audits.

Practical implication: map where agent context is stored, logged, and replayed before expanding deployment.

Why agent tool chaining changes the blast radius of a leak

A single agent session can query a customer system, enrich the result with a document store, then forward the output into another service. If any one step contains sensitive data, the agent can propagate it to places that would normally remain isolated. That is the governance problem CrowdStrike is pointing to: data leakage becomes a cross-system identity issue when one runtime identity has broad delegated access across several tools. The risk is amplified when the agent’s permissions are wider than the task, because the agent can combine legitimate accesses into an unintended disclosure chain.

Practical implication: constrain tool scope per task and segment access so one agent session cannot bridge isolated data domains.

Threat narrative

Attacker objective: The objective is to exfiltrate sensitive information by abusing legitimate agent access paths and turning routine tool use into cross-system disclosure.

1. Entry occurs when a user prompt or connected workflow gives an AI agent access to sensitive sources such as documents, databases, or APIs.
2. Credentialed access is then used to retrieve content from multiple systems, with the agent deciding dynamically which tools to call and in what order.
3. Escalation happens when retrieved data is copied into shared context, logs, or downstream API outputs, extending exposure beyond the original source.
4. Impact is sensitive information disclosure across users or systems, including unintended propagation of confidential, regulated, or credential-bearing data.

Breaches seen in the wild

• Nx s1ngularity attack 2025: Attackers stole Nx's npm token via a GitHub Actions flaw and shipped malware that stole 2,349 secrets and abused developers' AI CLIs.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Agentic AI data leakage is really delegated access leakage: the core failure is not that the model knows too much, but that a runtime identity can move data across systems faster than governance can reason about it. Once an agent can choose tools during execution, data protection and access control stop being separable disciplines. Practitioners should treat agent sessions as live access pathways with their own boundaries, not as passive inference events.

Runtime context is the new sensitive store: prompts, shared memory, logs, and retrieval caches now behave like high-value data repositories because they can retain or reproduce information outside the original source control. That creates a governance surface that sits between classic DLP and IAM, and neither discipline covers it fully on its own. The implication is that identity teams must account for where data travels after access is granted, not only who authenticated to get it.

Least privilege becomes task-scoped, not role-scoped: agentic systems invalidate the assumption that a stable role cleanly defines permissible behaviour for the duration of a session. The same agent may need different sources at different moments, which means static role definitions can over-grant by design. Practitioners should rethink privilege as a short-lived, task-bounded envelope tied to execution context.

Identity governance for AI agents must include data lineage: the article shows that the security question is no longer just whether the agent was authorised, but whether the data it touched can be traced, minimised, and contained after the fact. That pulls AI risk management into the same operational conversation as NHI governance and access certification. The practitioner takeaway is to govern the full movement of data through the agent, not just the initial permission check.

What this signals

AI agent governance now needs a data lineage view: if the agent can pass information between systems, then the security boundary is no longer the model alone. Teams need to know where sensitive content enters, where it is copied, and where it can resurface after the original request ends.

The practical shift is from protecting a single prompt-response exchange to governing the whole execution trail. That means tighter source scoping, lower-retention logging, and clearer separation between retrieval, reasoning, and downstream action.

A useful operating model is to treat each agent session as a short-lived delegated identity with data movement rights. That framing aligns IAM, NHI governance, and data protection around the same runtime boundary.

For practitioners

• Map agent tool chains to data exposure paths Inventory every database, API, document store, and search index an agent can reach, then document which data types can move between them in a single session.
• Limit context persistence and log retention Reduce how much prompt content, retrieved data, and intermediate reasoning is written to logs or shared memory, especially where plaintext records may persist.
• Apply task-scoped access boundaries Constrain each agent workflow to the minimum source set needed for the task, and avoid broad standing access that lets one session bridge isolated domains.
• Classify and minimise sensitive inputs before retrieval Tag PII, credentials, financial data, and confidential business content before the agent can ingest it, so the model never sees material it does not need.

Key takeaways

• Agentic AI leakage is an identity governance issue as much as a data security issue, because runtime tool use can move sensitive information across systems in ways static controls do not model.
• The exposure is not limited to outputs. Prompts, shared context, logs, and downstream API calls can all become persistence points for confidential data.
• Teams need task-scoped permissions, tighter context handling, and clear data lineage for every agent session if they want to limit disclosure and replay risk.

Key terms

• Agentic Data Leakage Boundary: The point at which an AI agent is allowed to access data but can still move that data outside the intended business context. This boundary matters because the risk is not only unauthorised access, but also lawful access used in ways the organisation did not intend.
• Runtime Identity: Runtime identity is the practice of making identity and authorization decisions at the moment an action occurs. For agents and workloads, it means access is validated against live context, not only against the identity state set during onboarding or provisioning. That makes accountability and scope enforcement possible inside fast-moving workflows.
• Session persistence: The tendency for access to remain valid after the original authentication event has ended or been revoked upstream. In browser-centric incidents, this is the gap between killing the login and actually terminating the live SaaS or application session that the attacker is still using.
• Tool chaining: Tool chaining is the practice of using one capability to unlock the next, such as searching for a secret, authenticating with it, and then using that access to reach another system. For AI agents, tool chaining is the mechanism that turns broad permissions into compound risk.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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.