You Cannot Audit ChatGPT. You Can Only Audit Yourself.

4 December, 2025 • Artificial Intelligence • 572 views • 5 minutes read

ChatGPT data leakage

The hard boundary most companies refuse to face

Public LLMs are sealed systems. No enterprise, regulator, or court can inspect who submitted which prompt to OpenAI, Anthropic, Google, or Perplexity. There is no backdoor. There is no audit API. There is no retroactive proof mechanism. Once sensitive data crosses that boundary, attribution is probabilistic at best and legally weak at worst.

This single fact defines the security reality of the AI era. If your strategy depends on checking what went into a public LLM, your strategy is already broken.

The real control surface is not the model

The real control surface is the environment the employee operates in, not the model they talk to. Data leakage is not an AI problem. It is a network, device, and governance problem. LLMs are just high-efficiency extraction interfaces.

You cannot observe what the model stores. You can, however, observe what your systems transmit. That is the only layer you truly control.

What is actually detectable

You can detect:

  • Which employee device accessed a public LLM site
  • When and how often access occurred
  • How much data left the network
  • Whether transmitted data matched sensitive patterns
  • Which files were accessed immediately before transmission

You cannot detect:

  • Whether the model retained the data
  • Whether the data was used in further training
  • Whether it will reappear in future outputs
  • Which staff at the model provider could access it

Detection exists only on your side of the boundary, never after it.

The only defensible technical stack

A credible approach is layered, with each layer handling a different part of the causal chain from employee intent to data exfiltration.

1. Network-level telemetry

Firewalls, secure web gateways, and DNS logging provide behavioural visibility. They track which domains are accessed, how often, and by whom. Typical domains include:

  • chat.openai.com
  • api.openai.com
  • claude.ai
  • gemini.google.com
  • perplexity.ai

This layer reliably answers three questions: who used public LLMs, at what frequency, and from which device. It does not inspect content. It maps risk posture.

2. Data Loss Prevention as the core control

Data Loss Prevention (DLP) is the only mechanism that directly controls content rather than behaviour. It scans outbound data in real time for:

  • Identity numbers and personal identifiers
  • Financial records and statements
  • Customer or client databases
  • Contracts and legal documents
  • Pricing models and commercial terms
  • Source code and internal repositories
  • Internal strategy documents and language patterns

DLP can then enforce:

  • Blocking copy-paste into browser fields
  • Preventing file uploads to unknown services
  • Masking or redacting sensitive fields
  • Triggering real-time alerts to security teams

Without DLP, AI policy is largely ceremonial. It exists on paper, not in the data path.

3. Endpoint telemetry closes the human loop

Endpoint monitoring ties behaviour to specific user actions. It can observe sequences such as:

  1. An internal document or system is opened
  2. Sections of content are copied
  3. A browser tab with a public LLM is focused
  4. Data is transmitted out of the environment

This sequence reveals intent and context. Attribution does not come from the LLM side. It comes from reconstructing what the user did on the endpoint.

4. Watermarking and honeytokens enable attribution

You can embed synthetic markers inside internal content:

  • Uniquely phrased sentences in strategy decks
  • Fake but realistic client entries in CRM exports
  • Controlled financial tables and assumptions
  • Distinctive wording in confidential memos

If these markers later appear in:

  • Public AI-generated outputs
  • Competitor material
  • Leaked documents on the open web

You gain forensic evidence that data has leaked and a strong indication of where the leak originated.

Why policies alone fail

Policy without telemetry delivers three failures in a row:

  • No reliable detection of violations
  • No credible attribution to individuals or systems
  • No enforceability that stands up to internal review or external scrutiny

Once data leaves the environment, there is no technical recall. Only legal exposure remains. For that exposure to be manageable, the policy must be explicit, signed, and backed by live controls that show you actively tried to prevent the breach.

Anything softer is theatre intended to comfort management, not protect data.

The behavioural risk curve

Leakage risk is not evenly distributed. It clusters where speed and pressure are highest, for example:

  • Sales teams under aggressive quota pressure
  • Marketing teams trying to produce content faster
  • Junior developers relying on public AI copilots
  • Finance teams analysing spreadsheets in browser-based tools
  • Legal teams summarising long-form contracts externally

The pattern is simple. Wherever “just paste it into ChatGPT” feels like the fastest route to progress, you have concentrated risk.

What does not work, regardless of budget

Some ideas are attractive but structurally unsound, regardless of how much money is available:

  • Asking model providers to supply detailed prompt logs per employee
  • Relying purely on trust-based or honour-system compliance
  • Running occasional manual spot audits on devices
  • Using NDAs as the primary protection against misuse
  • Relying on “we anonymise before pasting” patterns that are often reversible

These approaches break under real operational pressure and time constraints.

The correct mental model

Public LLMs should not be treated as internal tools with slightly weaker controls. They are more similar to public broadcast channels with zero transparency once data is submitted.

Once your data touches a public LLM, the risk profile shifts from internal governance to external litigation and regulatory exposure. That shift is one-way.

The executive reality in one table

The practical question is not whether you can investigate ChatGPT. You cannot. The question is whether you can investigate your own infrastructure with enough fidelity to demonstrate control.

Lever Function
Network logging Behaviour visibility over who uses public LLMs and how often
DLP Content enforcement that stops sensitive data crossing the boundary
Endpoint telemetry Reconstruction of user actions for attribution and root-cause analysis
Watermarking Evidence that specific internal assets have leaked externally
Legal policy Authority to act on violations and prove due diligence

Remove any one of these levers and accountability collapses. Either you cannot see violations, cannot prove who caused them, or cannot act decisively when they occur.

Final principle

Data leakage into public LLMs is not fundamentally an AI governance problem. It is a failure of internal control design.

Control the environment. The model is just the exit door.

5 of 1 ratings
The curve is 0.95ⁿ plotted across twenty steps: 95 per cent per step at the left, 36 per cent at the right, with the drop marked in amber. Someone scrolling past learns something before they click, and the thing they learn is uncomfortable enough to make t

Eight essays on why agentic AI programmes fail

9 August, 2026

A new series on measurement, causal inference, security, governance and the one number that tells you whether any of it is working. All eigh..