Why do sanctioned controls often fail to prevent ChatGPT data leaks in practice?

Why This Matters for Security Teams

Sanctioned controls are often designed around an approved platform, but data leakage usually happens through the gaps between policy, device trust, and user behaviour. A corporate DLP rule or workspace restriction can reduce risk, yet it does not automatically stop a user from pasting sensitive material into a personal account, a browser profile outside management, or an unsanctioned extension. That is why control scope matters as much as control strength.

Security teams also need to account for the fact that ChatGPT usage is not one uniform channel. The same prompt can enter through a managed web app, a consumer login, a desktop client, or an integrated browser extension, each with different visibility and enforcement. Current guidance suggests aligning controls to the full data path rather than assuming a single sanctioned interface will contain the problem. NIST SP 800-53 Rev. 5 remains a useful baseline for access control, auditability, and system monitoring expectations, especially where organisations need to map policy to implementable safeguards through NIST SP 800-53 Rev 5 Security and Privacy Controls.

In practice, many security teams encounter the leak after the prompt has already left the managed boundary, rather than through intentional AI governance.

How It Works in Practice

Preventing ChatGPT data leaks requires treating AI use as a multi-channel access problem, not just a content filtering problem. The core issue is that sanctioned controls usually inspect one layer, while the real workflow spans identity, endpoint posture, browser state, network routing, and user choice. If controls do not follow the user across those layers, sensitive text can still reach a model through an unmanaged path.

A practical control stack usually combines:

• Identity enforcement, so only approved accounts can access the sanctioned service.
• Device posture checks, so unmanaged or high-risk endpoints are blocked or limited.
• Browser and extension governance, so shadow plugins cannot exfiltrate content.
• Data classification and copy-paste controls, so protected content is handled differently from ordinary text.
• Logging and detection, so unusual prompt patterns, account switching, and bulk submission are visible to the SOC.

This is also where AI-specific threat models matter. Prompt injection, indirect prompt injection, and malicious extension behaviour can all cause the model or the surrounding workflow to process data in unsafe ways. The recent Anthropic report on the Anthropic — first AI-orchestrated cyber espionage campaign report is a useful reminder that AI systems can be operationalised inside broader attack chains, not just used as standalone tools.

Best practice is to pair preventive controls with detection and response. That means alerting on unsanctioned AI domains, monitoring browser and endpoint telemetry, and correlating identity events with exfiltration patterns in SIEM and XDR workflows. These controls tend to break down when users can move sensitive work to personal devices or unmanaged browsers because the organisation loses both policy enforcement and reliable telemetry.

Common Variations and Edge Cases

Tighter AI access control often increases user friction and support overhead, requiring organisations to balance data protection against productivity and exception handling. That tradeoff becomes sharper in hybrid work, BYOD, and developer-heavy environments where AI tools are embedded into daily workflows and blanket blocking is rarely sustainable.

There is no universal standard for this yet, so the right response depends on the risk profile of the data being handled. For highly sensitive environments, the best pattern is to disallow pasting confidential content into consumer AI services unless the session is explicitly governed and logged. For lower-risk use cases, organisations may accept limited access with redaction, DLP, and approved-account requirements.

One important edge case is shadow identity. A user may have a sanctioned corporate login and a separate personal login to the same AI service, which defeats policy if controls only inspect SSO traffic. Another common gap is the browser extension layer, where sanctioned web access still leaks data through add-ons, clipboard handlers, or local automation. Organisations should also consider that desktop clients may bypass web proxy inspection entirely. The most resilient approach is to define controls by data sensitivity and trust boundary, not by the brand name of the AI application.

Related resources from NHI Mgmt Group

• Why do cloud-based AI inspection controls often fail in practice?
• Why do ISO 27001 access controls often fail in practice?
• Who is accountable when browser controls fail to prevent data exposure?
• Why do email security controls fail to stop many data leaks?