Because traditional DLP is optimised for files, email, and known egress paths. ChatGPT turns sensitive data into free text entered in a browser or desktop app, which often bypasses pattern matching and attachment-based controls. If the policy engine cannot see the paste, it cannot classify or stop the leak in time.
Why This Matters for Security Teams
Traditional DLP was built around a world of predictable choke points: email gateways, file shares, web uploads, and endpoint file movement. ChatGPT changes the control problem because the risky action is often a paste into a browser field or desktop app, not a file transfer. That means the sensitive content may never trigger the inspectors, classifiers, or CASB policies that organisations rely on. The security issue is not just leakage, but loss of visibility into where data is being transformed, summarised, or reused.
This matters because AI prompts can contain source code, customer records, credentials, incident details, or regulated data in plain text. Once that text is submitted, the organisation may have little assurance about retention, downstream use, or prompt injection risk. Current guidance in the NIST Cybersecurity Framework 2.0 points teams toward governance, data protection, and continuous monitoring, but it does not assume legacy DLP alone will cover browser-based AI workflows. In practice, many security teams discover the gap only after employees have already normalised pasting sensitive data into public or unmanaged AI tools, rather than through intentional prompt governance.
How It Works in Practice
To understand the failure mode, it helps to separate content inspection from context enforcement. Traditional DLP usually inspects files, messages, and network transactions where data is packaged in a recognizable format. A ChatGPT prompt often arrives as unstructured text, copied from multiple sources, then submitted through a browser session that may look like ordinary web traffic. If the policy engine cannot reliably see the clipboard event, the rendered page, or the semantic meaning of the text, the control becomes reactive instead of preventive.
Security teams that want better coverage usually need multiple layers:
- Endpoint controls that monitor clipboard use, browser uploads, and sanctioned AI applications.
- Browser or SaaS controls that distinguish approved copilots from public AI services.
- Data classification rules that extend from documents into prompt text and copied snippets.
- Identity-aware policy decisions so high-risk data can be blocked for certain users, devices, or sessions.
- Logging that captures prompt activity for audit, training, and incident response without storing unnecessary sensitive content.
The practical challenge is that no universal standard exists yet for prompt-level DLP. Teams often borrow from data security posture management, OWASP guidance for LLM applications, and browser governance patterns to close the gap. The strongest implementations tie AI usage to identity, device trust, and data sensitivity so a user cannot move from approved collaboration tools into unmanaged AI systems without enforcement. These controls tend to break down when users work on unmanaged devices or personal browsers because the organisation cannot reliably observe the paste, the session context, or the destination.
Common Variations and Edge Cases
Tighter prompt controls often increase user friction and operational overhead, requiring organisations to balance data protection against speed of adoption. That tradeoff is especially sharp for teams using AI in software engineering, legal review, customer support, or incident response, where the value of a prompt is highest exactly when the text is most sensitive.
There are also important edge cases. Some organisations try to solve the problem by blocking all AI tools, but that is usually brittle and easy to bypass through personal accounts or mobile apps. Others rely on redaction or tokenisation alone, which can reduce exposure but will not stop a user from pasting context that remains identifiable when combined with other inputs. For highly regulated environments, current guidance suggests treating prompts as a governed data flow, not an informal user action.
Identity is part of the control model here. If access policy does not consider who is prompting, from what device, and under what business context, DLP becomes a static filter in a dynamic workflow. The better question is not only whether the content matches a rule, but whether the user should be able to place that content into an AI system at all. For organisations aligning to the NIST Cybersecurity Framework 2.0, this is a governance and monitoring problem as much as a data inspection problem.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and MITRE ATLAS address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF and NIST AI 600-1 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.DS | Prompt data handling maps to data security and leak prevention. |
| OWASP Agentic AI Top 10 | LLM05 | Prompt injection and unsafe prompt handling are central to this failure mode. |
| NIST AI RMF | GOVERN | AI governance is needed where legacy DLP cannot see prompt context. |
| NIST AI 600-1 | GenAI profile addresses misuse, data leakage, and output handling. | |
| MITRE ATLAS | AML.TA0001 | Adversarial manipulation of model inputs includes prompt-based abuse. |
Classify prompt data as sensitive flow and enforce protection across browser and endpoint paths.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 14, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
