What is AI data leakage?

By Identra · Updated

AI data leakage is the unintended or unauthorized exposure of sensitive information through an AI system or workflow. It can happen when data is submitted to an unapproved service, retrieved beyond a user's authorization, or disclosed through generated answers and agent actions.

Key numbers

How does AI data leakage happen?

An AI workflow moves information between people, applications, models, data stores, and tools. Leakage happens when information crosses a boundary that policy or access rules should protect. The destination might be an external provider, a personal account, another employee, or a publicly shared conversation.

Common entry points include pasted prompts, uploaded files, screenshots, and documents retrieved through connectors. Sensitive information can also leave through generated answers, tool calls, debugging logs, or saved conversation histories. A coding assistant might encounter a credential in a configuration file even when the employee never pastes it into a prompt.

External processing is not automatically leakage. An approved workflow may legitimately send confidential information to a contracted service. The deciding factors are authorization, purpose, recipient, and permitted handling. Unapproved use, often called shadow AI, makes those boundaries harder to establish and enforce.

Does submitting data mean it becomes training data?

No. Submission, retention, training, and disclosure to other users are separate questions. Their answers depend on the service, account type, contract, settings, and application architecture. Avoid assuming either that every prompt trains a model or that a training exclusion prevents every form of exposure.

A service may retain conversation history or operational logs without using that content for training. A connected application may also copy information into its own storage. Review the complete workflow, including integrations and sharing settings, rather than relying on a single privacy statement.

These distinctions are central to AI data privacy. Before approving a use case, establish which data can be processed, where it can be retained, who can access it, and how deletion requests are handled. A confidential document sent to an unauthorized recipient is still exposed even if no model learns from it.

What does AI data leakage look like in an enterprise?

Consider a sales employee who uploads a customer contract to a personal AI account to draft a renewal summary. The contract contains negotiated pricing and named customer contacts. If company policy permits that data only in an approved workspace, the upload creates an unauthorized copy. The issue exists before any generated answer is shared.

A different scenario starts inside an approved enterprise assistant. A payroll folder has overly broad sharing permissions, and the assistant retrieves salary details for an employee who has no business need to see them. This is copilot oversharing. The assistant can amplify an existing access problem without bypassing the source system's permissions.

An attacker can also place instructions in a document an agent reads, attempting to make it send confidential content to an external destination. This is a possible consequence of indirect prompt injection, rather than an accidental upload. Defenses must address both legitimate workflows that expose too much and malicious attempts to redirect them.

Which controls help prevent AI data leakage?

AI data loss prevention applies data protection policies to AI interactions. Existing DLP may already cover some browser, endpoint, network, or SaaS activity. Coverage varies, so test actual prompts, uploads, connectors, and outputs before deciding what additional controls are needed.

Choose controls by data sensitivity and workflow. Redacting a name may leave enough context to identify someone. Blocking an upload does not address an assistant retrieving the same information through a connector. Effective protection combines content checks with destination restrictions and access controls.

  • Block

    Useful when
    The data or destination is prohibited
    Limit to consider
    Other transfer paths need coverage
  • Redact or mask

    Useful when
    The task can work with less sensitive content
    Limit to consider
    Remaining context may still disclose sensitive facts
  • Restrict access

    Useful when
    Assistants retrieve from enterprise repositories
    Limit to consider
    Existing sharing permissions need review
  • Alert and review

    Useful when
    Teams need to investigate suspicious activity
    Limit to consider
    An alert alone does not prevent disclosure

How do you build a practical prevention program?

Start with a specific workflow, such as summarizing customer contracts or using a coding assistant. Define the permitted data, account, destination, and actions. Apply least privilege to both the person requesting the work and the applications performing it.

Good controls produce a predictable outcome: approved work proceeds with the minimum necessary data, prohibited transfers stop where enforcement is available, and exceptions have an owner and expiration. Test with synthetic sensitive content so validation does not create another disclosure.

  • Inventory AI services, desktop clients, agents, and connectors. Record owners and distinguish company accounts from personal accounts.
  • Map data classes to approved uses. Specify which content must be removed, which destinations are permitted, and which transfers must be blocked.
  • Review repository sharing and connector permissions. Remove unnecessary access to sensitive folders, mailboxes, and databases.
  • Test enforcement across pasted text, uploads, retrieved documents, tool calls, and generated outputs. Include attempts to send data to an unapproved destination.
  • Limit sensitive content in logs. Record enough information to investigate the actor, destination, action, and result without creating unnecessary copies of prompts.
  • Give employees an approved way to complete the task and clear instructions for reporting mistakes.

What should you do after suspected AI data leakage?

Establish what information was exposed, which account or application sent it, and who could receive or access it. Preserve relevant evidence while restricting access to that evidence. Distinguish a blocked attempt from a completed transfer and from confirmed access by another party.

Contain the affected workflow. Remove shared links, restrict the connector, or suspend the relevant access as appropriate. Rotate exposed credentials and assess whether existing sessions or tokens also need revocation. Request deletion where available, but do not treat a deletion request as proof that every copy is gone.

Involve security, privacy, legal, and the data owner as needed to assess obligations and impact. Repair the permission or policy gap, then repeat the original workflow with safe test data to confirm the fix.

How Identra thinks about it

Identra checks prompts on the device before they are sent. In the browser, sensitive prompts can be allowed, alerted, masked or blocked by policy. Prompts to Codex and Claude Code are checked before they are sent and blocked when policy is active. Prompt content stays on the device by default. File uploads to AI can be blocked by policy, work and personal AI accounts are told apart, and connected AI apps holding company data are identified.

Go deeper: Identra in the browser

Frequently asked questions

Is AI data leakage the same as data leakage in machine learning?

No. In machine learning evaluation, data leakage usually means training or evaluation uses information that should have been unavailable, producing misleading performance results. In AI security, it means sensitive information is exposed without authorization.

Can AI data leak without an attacker?

Yes. An employee can upload a confidential file to the wrong account, or an assistant can surface documents with overly broad sharing permissions. Neither requires a malicious prompt.

Does running a model locally eliminate data leakage?

No. Local processing can reduce external transfers, but connectors, tools, logs, shared outputs, and other users can still expose information. Review the entire application workflow.

Are enterprise AI accounts safe for confidential data?

Approval depends on the data and use case, along with contractual terms, settings, access controls, and connected applications. An enterprise account label alone does not establish that every confidential document is permitted.

Can prompt instructions prevent sensitive data disclosure?

Instructions can guide behavior, but they should not be the sole access control. Enforce permissions outside the model, minimize the data provided, and restrict destinations and tool actions.

Related terms

Keep exploring · AI threats and attacks