Teams often focus only on whether an AI tool is sanctioned, instead of evaluating the sensitivity of the data being sent and the access context of the user. A better approach is to classify the tool’s risk, understand what data is leaving, and enforce controls that prevent leakage into unsafe models or resurfacing to the wrong person. Visibility has to come before policy.
Why This Matters for Security Teams
Data flowing into generative AI tools is not just another application traffic problem. It is a governance and exposure problem, because the same prompt can carry source code, customer records, regulated data, secrets, or operational context that should never leave controlled systems. Teams often assume an approved tool is safe by default, but that misses the real question: what data is being sent, who is sending it, and under what privilege. Current guidance from the NIST AI 600-1 Generative AI Profile is useful here because it frames GenAI risk around context, data handling, and lifecycle controls rather than simple tool allowlisting.
The practical issue is that GenAI use is often embedded into chat interfaces, plugins, copilots, and workflow automations that look harmless until sensitive material is pasted or forwarded at scale. Security teams also miss the access dimension: a junior analyst with broad access to a repository can leak far more through a prompt than through a traditional file export. In practice, many security teams discover prompt leakage only after sensitive data has already been copied into an external service, rather than through intentional data-loss design.
How It Works in Practice
Effective control starts with classifying data before it reaches the model. That means separating public content, internal business data, confidential material, regulated data, and secrets, then deciding which classes may be used in which AI tools. The most mature programs also distinguish between human-entered prompts and data passed automatically through connectors, because automation increases the blast radius when controls are weak. The question is not only whether the model is approved, but whether the specific interaction is safe.
Operationally, teams should combine policy, technical enforcement, and monitoring:
- Restrict sensitive prompts, attachments, and copy-paste into unmanaged AI services.
- Apply DLP-style inspection to detect secrets, personal data, and high-risk content before transmission.
- Use identity and access context to shape policy, so higher privilege does not translate into freer data movement.
- Log AI interactions where feasible, with clear retention and privacy rules.
- Review connectors, browser extensions, and agent workflows that can exfiltrate data outside approved boundaries.
That last point matters because AI risk often enters through integrations rather than the chat box itself. A copilot with access to email, tickets, documents, or code repositories can expose data through retrieval, summarisation, or prompt chaining even when the base model is not directly given a file. The NIST AI 600-1 GenAI Profile is helpful for translating this into governance terms, while access control and monitoring still need to be implemented in the surrounding systems. These controls tend to break down when organisations allow broad, unsupervised plugin access because the data path becomes difficult to see and even harder to constrain.
Common Variations and Edge Cases
Tighter data controls often increase friction for legitimate work, requiring organisations to balance productivity against leakage risk. That tradeoff is especially visible in research, software engineering, legal review, and customer support, where users genuinely need large amounts of context to do their jobs. Best practice is evolving toward tiered access and context-aware controls rather than a single blanket ban, but there is no universal standard for this yet.
One common edge case is training and fine-tuning. Some teams focus only on prompts and forget that the same data may later be reused for model improvement, retention, or retrieval augmentation. Another is cross-border or regulated-data handling, where a prompt may appear harmless in isolation but becomes problematic once stored, logged, or processed by a third party. Identity also matters: if an AI tool responds based on the caller’s access rights, then over-permissioned accounts can reveal more than intended, especially in agentic workflows that act on behalf of users. Where the environment includes unmanaged consumer tools, browser shadow IT, or opaque vendor retention terms, the guidance usually breaks down because the organisation cannot reliably prove where the data went or who can later see it.
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 AI RMF, NIST AI 600-1 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST AI RMF | GOV-4 | Governance is needed to classify AI data risk and assign ownership. |
| NIST AI 600-1 | GenAI profile guidance fits prompt handling, retention, and context risk. | |
| OWASP Agentic AI Top 10 | A1 | Prompt injection and unsafe tool use can expose sensitive data through AI workflows. |
| NIST CSF 2.0 | PR.DS | Data security controls apply to sensitive information sent into AI services. |
| MITRE ATLAS | AML.T0001 | Adversarial AI techniques include manipulating inputs and extracting sensitive content. |
Use the GenAI profile to define acceptable inputs, retention limits, and monitoring expectations.
