For security and AI platform teams, AI data poisoning vs data leakage separates integrity from confidentiality. Poisoning corrupts training data, retrieval corpora, or agent memory so AI behaves incorrectly. Leakage lets PII, PHI, PCI, source code, secrets, or intellectual property escape through prompts, files, responses, retrieval, or tool calls. The controls differ: validate trusted inputs for poisoning, classify and enforce sensitive-data policy for leakage.

Last updated: August 2026.

The two terms drift together in security conversations, as if they were one problem seen from opposite angles. They are not. Treat them as one blurred category and your controls miss half the risk surface. This explainer separates the two, maps each to the layer of the AI stack it strikes, and covers the detection strategies, control design, compliance implications, insider and supply chain vectors, and enforcement each failure mode requires.

AI data poisoning is an integrity attack on what the model learns and retrieves

AI data poisoning means an attacker corrupts the data an AI system learns from or retrieves so the system produces degraded or attacker-chosen outputs. It targets integrity. The question is not whether data escaped, but whether the data the model trusts is trustworthy. The corruption enters during training, during fine-tuning, or later through a retrieval corpus or agent memory the model reads at inference time.

Poisoning is dangerous because it is efficient. Peer-reviewed research reports that in neural machine translation models used for code generation, poisoning as little as 3 percent of training data can yield a 12 to 41 percent attack success rate, and corrupting only 0.001 percent of tokens in a medical dataset can raise harmful outputs by nearly 5 percent. Small write, large blast radius. That asymmetry makes training-data validation and provenance controls essential long before a model reaches production.

Public datasets and scraped web content widen the injection surface. Anyone can contribute, and crawled content is often ingested without line-by-line review. Take a common example: an attacker seeds a publicly accessible corpus with documents carrying embedded trigger phrases, so the fine-tuned model produces specific outputs when it meets those phrases in production. That is a classic backdoor. Private datasets narrow the surface but do not close it. A compromised ingestion workflow, a poorly scoped knowledge-base write permission, or an insider with elevated privileges can still introduce corrupted records without alerting the data owners.

AI data leakage is a confidentiality failure where sensitive data escapes the boundary

AI data leakage means sensitive data crosses a boundary it should not cross when an AI system processes it. Personally identifiable information (PII), protected health information (PHI), payment card data (PCI), intellectual property, source code, and secrets all leave through the same everyday channels employees use to get value from AI: a prompt that pastes a customer record, a file upload, a model response that surfaces confidential text, a retrieval result that returns a document the requester should not see, or a tool call that ships data to an external service.

Leakage often starts with usage nobody approved. Survey work shows 43 percent of workers admit sharing sensitive workplace information with AI tools without employer knowledge, including internal documents, financial data, and client records (National Cybersecurity Alliance, 2025). When the tool is unmanaged, there is no data path visibility and no record of what left. This is why data loss prevention (DLP) for AI, built on real-time classification, matters. It recognizes sensitive categories as they move through an AI interaction and enforces policy before data escapes. Source code is a frequent category: developers paste proprietary logic into assistants to get help. See AI coding assistant data leakage and Cursor source code exposure for that path in depth.

Side-by-side comparison: two failure modes, two control strategies

Line the two modes up against the properties security teams design around. Poisoning is a write-phase integrity problem. Leakage is a read-and-send confidentiality problem. The table below maps each mode to the layer it strikes, the direction of harm, and where Aurascape’s runtime controls apply: real-time classification, inline policy enforcement on governed AI interactions, and approved agent-to-tool execution.

A short rule of thumb: for poisoning, monitor write-phase integrity through provenance, validation, and behavioral drift on trusted inputs; for leakage, enforce sensitive-data policy on the read-and-send path with real-time classification; for both, collect evidence at the interaction layer. Aurascape applies runtime control where governed AI interactions move data: prompts, responses, files, and approved agent-to-tool execution. Training-pipeline poisoning that happens outside those interactions still needs validation, provenance, and chain-of-custody controls at the data pipeline layer (Aurascape, 2026).

The poisoning taxonomy: label flipping, backdoors, clean-label, and data injection

Poisoning is a family of techniques, not a single attack. The variant determines where the corruption enters, how hard it is to detect, and which controls work best.

1. Label flipping. An attacker mislabels training examples so the model learns wrong associations. The corruption sits in the metadata, not the content, so it survives content-level review while degrading model behavior on targeted classes.
2. Backdoor poisoning. The model behaves normally under ordinary inputs until a specific trigger appears, then produces the attacker’s chosen output. It stays dormant during testing and activates in production.
3. Clean-label poisoning. Poisoned samples keep correct labels and look benign to human reviewers. The corruption hides in subtle feature perturbations rather than obvious mislabeling, so it survives manual audit.
4. Data injection. Rather than altering existing records, the attacker adds crafted records to a public dataset, scraped corpus, or knowledge base the system later ingests. This is the dominant vector for RAG corpus poisoning and agent memory poisoning at runtime.

Supply chain vectors extend each of these. Third-party datasets, shared model components, vendor-managed retrieval corpora, plug-ins, connectors, and external tool outputs all carry poisoned content into a governed system. When a connector ingests from an external knowledge base or an agent calls a third-party tool that returns tainted output, the corruption enters through a trusted channel. So chain-of-custody covers not just internal data pipelines but every upstream data source an AI system trusts. Write permissions matter for the same reason: scope who and what can write to training datasets, retrieval corpora, and memory stores, log every such write, and you hold a foundational access control for the integrity side.

RAG corpora and agent memory: where poisoning and leakage share a surface

Retrieval-augmented generation (RAG) moved a large share of risk out of training and into runtime. Write a crafted document into the retrieval corpus, and the model reads it as trusted context and repeats or acts on the embedded instruction. That is knowledge-base poisoning: an integrity attack that never touches model weights and bypasses controls that only check training data. The same corpus is also a leakage surface. A poorly scoped retrieval returns a confidential document to a user who should not see it, a confidentiality failure through the same read path.

Agent memory is the sharpest example of a dual surface. OWASP’s work on agentic AI security names memory poisoning as a distinct risk category. A write into memory can plant an instruction the agent trusts on the next turn, an integrity failure. A read from memory can surface a credential or confidential exchange captured in an earlier session, a confidentiality failure. Both events pass through the same execution step. Aurascape classifies sensitive data and enforces policy on governed AI interactions and approved agent-to-tool execution in real time, while provenance, validation, and anomaly detection address whether the written content is trustworthy (Aurascape, 2026). Model Context Protocol (MCP) is one common tool-execution pattern here, not the whole agent access-control problem.

Poisoned models open a distinct leakage path worth naming precisely. Model inversion and membership inference are confidentiality attacks against model outputs. If training data includes memorized PII, PHI, source code, or secrets, those techniques can expose whether a specific record was present or reconstruct parts of sensitive inputs. They are leakage paths in their own right, present even without poisoning, but a model whose training set was tampered with widens what an attacker can extract. OWASP ranks prompt injection (LLM01), sensitive information disclosure (LLM02), and excessive agency (LLM06) among the top risks in the OWASP Top 10 for LLM Applications (OWASP, 2025). An injection that manipulates agent behavior is an integrity event; a disclosure through a response or tool call is a confidentiality event.

Detection approaches and defense controls for each mode

Poisoning and leakage need overlapping but distinct detection and defense designs. For a security or AI platform team building controls, the sequence across both modes runs like this:

1. Discover AI apps, accounts, and agents. An unmanaged AI app or agent is an unmonitored ingestion and exfiltration path. Discovery identifies unmanaged AI apps, accounts, and agents so teams bring their ingestion and exfiltration paths under policy before they turn routine.
2. Validate and trace data writes. Every input to a training dataset, retrieval corpus, or memory store should carry chain-of-custody: who wrote it, from where, and when. Behavioral drift monitoring compares model output distributions over time and flags statistical anomalies that signal a training or retrieval corruption, for example a measurable shift in classification accuracy on a held-out test set.
3. Classify data in real time at the interaction layer. AI DLP recognizes PII, PHI, PCI, source code, and secrets as they move through an AI interaction. For leakage, this is the primary enforcement control. For poisoning, it covers the subset of writes that carry policy-violating sensitive content.
4. Enforce inline policy with five actions. At the point data would leave or enter a governed AI interaction, a control that can allow, coach, warn, block, or redact gives security teams graduated response rather than a binary alert.
5. Create interaction records for audit and effectiveness. Record which governed interaction occurred, which tool call ran, what data moved, and which policy decision applied, with role-based access control for privacy. That gives teams the evidence to separate an integrity event from a confidentiality event after the fact.

Anomaly detection deserves a concrete example for each mode. For poisoning, a useful signal is a drift in model output on a stable benchmark after a new corpus ingestion: the model suddenly recommends actions it previously scored as low-priority, and something in the new data shifted its behavior. For leakage, the comparable signal is an AI interaction that transfers a volume or category of data inconsistent with the Intention or entitlement granted to the user, such as a coding assistant session that includes a full authentication token rather than a code pattern.

Insider threat is a real vector for both modes. A privileged user with write access to a private knowledge base can introduce corrupted records without tripping external-source controls. The same user with access to approved AI workflows can exfiltrate sensitive data through prompt inputs that look like ordinary usage. Neither event looks like a network intrusion; both look like permitted activity. Entitlement-level granular controls that track what data moves through which AI Intention, scoped by account type, are the practical response.

Regulatory and compliance exposure from each failure mode

The two modes carry distinct compliance implications, and conflating them leaves gaps in the control design a compliance team hands to auditors.

GDPR and HIPAA attach obligations to confidentiality failures. Under GDPR, a personal-data breach that poses a risk to individuals can require notification to the supervisory authority (GDPR, 2016), and the HHS HIPAA Breach Notification Rule sets notification requirements for unsecured PHI (HHS, 2013). Not every unauthorized disclosure triggers notification automatically; the obligation depends on the risk assessment each rule defines. Integrity failures raise a different set of concerns. The EU AI Act requires high-risk AI systems to meet accuracy, resilience, and transparency obligations (EU AI Act, 2024), and corrupted model behavior from poisoning directly threatens those obligations. NIST’s AI Risk Management Framework addresses both dimensions under the Govern, Map, and Measure functions (NIST AI RMF, 2023). Security and compliance teams should document controls separately for integrity and confidentiality rather than present a single AI security program that conflates the two.

Remediation costs also differ. Leakage remediation stops the flow, notifies affected parties where required, and contains what left. Poisoning remediation can require retraining, rebuilding a retrieval corpus, or purging and re-indexing a memory store, each carrying real time and engineering cost. Survey data indicates roughly a quarter of organizations in the UK and US fell victim to AI data poisoning in the past year, with 37 percent also observing unauthorized use of AI tools by employees as a direct leakage vector. For a deeper look at the leakage side, see sensitive data leaks and AI tool DLP gaps. Teams evaluating coding-assistant risk can also review whether Cursor retains or trains on source code.

Policy is the precondition for either audit trail. ISACA found that 90 percent of organizations say employees use AI tools, but only 38 percent have a formal, comprehensive AI policy and 25 percent have none (ISACA, 2026). Without a governed AI usage policy enforced at the interaction layer, neither poisoning writes nor leakage reads leave the audit record a compliance team needs.

Frequently asked questions

What is the core difference between AI data poisoning and AI data leakage?

Poisoning targets integrity: it corrupts what a model learns or retrieves so outputs turn wrong or attacker-chosen. Leakage targets confidentiality: sensitive data such as PII, PHI, source code, or secrets escapes through prompts, files, responses, or tool calls. Poisoning needs input validation and provenance; leakage needs real-time classification and enforcement.

Where in the AI stack does data poisoning happen?

Poisoning happens at training time, at fine-tuning time, or at runtime through a corrupted retrieval corpus or agent memory. Runtime knowledge-base or memory poisoning never touches model weights, so controls that only inspect training data miss it entirely.

Can a poisoned model also cause data leakage?

Yes. Model inversion and membership inference are confidentiality attacks against model outputs. If training data includes memorized PII, PHI, source code, or secrets, those techniques can expose whether a record was present or reconstruct parts of sensitive inputs. They are leakage paths even without poisoning, but tampered training data widens what an attacker extracts.

Is agent memory a poisoning or a leakage risk?

Both. A write into memory can plant a malicious instruction the agent trusts on the next turn, an integrity failure. A read from memory can surface a credential or confidential exchange from an earlier session, a confidentiality failure. Both risks live on the same runtime memory path, so inline governance of that path addresses each.

What controls stop AI data leakage at the interaction layer?

AI DLP built on real-time data classification is the primary control. It recognizes PII, PHI, PCI, source code, and secrets as they move through an AI interaction, then enforces inline with five policy actions: allow, coach, warn, block, and redact. Aurascape runs 600+ real-time data classifiers for that recognition step.

How do supply chain and insider vectors differ for each mode?

Supply chain poisoning enters through third-party datasets, vendor-managed corpora, plug-ins, or connectors that carry corrupted content via a trusted channel. Insider leakage uses approved AI workflows to move sensitive data out through ordinary-looking prompts. Both bypass perimeter controls and require entitlement-level policy enforcement at the interaction layer.

Why is poisoning harder to remediate than leakage?

Persistence. Once a model learns corrupted content, remediation may require retraining, corpus rebuild, or memory purge, each with real cost and time. Leakage remediation stops the flow and contains what left. That retraining burden makes prevention controls at the write phase more valuable than detection after the fact for poisoning.

How does Aurascape produce audit evidence for both modes?

Aurascape creates interaction records for audit and effectiveness, governed by role-based access control (RBAC) for privacy. That gives security teams audit evidence of which governed tool call or interaction involved a suspicious write and which involved a sensitive-data disclosure, separating integrity events from confidentiality events across the same audit trail.

Aurascape helps security and AI platform teams separate integrity risk from confidentiality risk at runtime: classify sensitive data in governed AI interactions, enforce policy on approved agent-to-tool execution, discover AI apps, accounts, and agents, and create interaction records for audit and effectiveness governed by role-based access control for privacy. The outcome is separate integrity and confidentiality evidence without slowing approved AI use (Aurascape, 2026).

See how Aurascape governs AI data integrity and confidentiality in one place →