Organisations should treat prompts, uploads, and model outputs as governed data flows, then apply classification, inspection, and logging at the point of use. The control objective is to stop sensitive information from entering AI workflows without visibility. That requires policy, access rules, and monitoring to work together, not as separate programmes.
Why This Matters for Security Teams
GenAI tools do not just process text. They ingest prompts, attachments, retrieved context, and outputs that may include customer records, source code, credentials, or regulated content. If that data enters the model path without classification and enforcement, the organisation loses visibility at the exact point where exposure becomes hardest to unwind. NIST’s NIST AI 600-1 GenAI Profile treats these flows as a governance problem, not a prompt hygiene problem.
The practical risk is not limited to accidental leakage. Sensitive data can be retained in logs, copied into downstream tools, or resurfaced through outputs and chat histories. NHIMG research on the Ultimate Guide to NHIs highlights how fragmented secrets handling already undermines control, and the same pattern appears in AI adoption when teams connect multiple copilots, plugins, and model endpoints without a common policy layer. The control objective is to prevent sensitive information from entering uncontrolled AI workflows, then prove that prevention with logs and inspection.
In practice, many security teams discover the exposure only after a user has already pasted the sensitive data into a public or poorly governed GenAI tool.
How It Works in Practice
Effective control starts by treating prompts, uploads, and retrieved context as governed data flows. That means data classification must be available where the user interacts with the tool, not only in an upstream data catalog. The policy decision should happen at the point of use, with enforcement that can block, redact, warn, or route the request to a safer path depending on sensitivity and business need.
For most organisations, that control stack has four parts. First, classify sensitive data types such as secrets, regulated personal data, source code, and confidential business data. Second, inspect content before it reaches the model, including file uploads and prompt text. Third, log the request, the policy decision, and the data handling action so security teams can reconstruct what entered the workflow. Fourth, limit downstream retention and connector scope so the model, plugins, and retrieval layers do not become hidden copies of the original data.
- Use policy at the gateway or client layer, not only in the model.
- Apply allowlists for approved tools and connectors.
- Mask or tokenize high-risk fields before submission where possible.
- Separate user telemetry from sensitive content logs.
- Review whether the provider retains prompts, outputs, or embeddings.
Current guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls supports the same operational pattern: identify the data, control the flow, and retain evidence. NHIMG’s DeepSeek breach coverage is a useful reminder that AI systems can expose far more than a single prompt when governance fails across the stack. These controls tend to break down when users can bypass sanctioned interfaces by copy-pasting into unmanaged browser tools because the organisation loses inspection at the actual data egress point.
Common Variations and Edge Cases
Tighter data controls often increase friction for employees, so organisations must balance protection against productivity and false positives. That tradeoff is real, especially in research, engineering, and legal teams where high-value work depends on rapid iteration. Best practice is evolving, but there is no universal standard for every use case yet.
Some environments need stronger restrictions than others. Highly regulated sectors may block entire classes of sensitive data from external GenAI tools, while lower-risk teams may allow redaction and approved-use workflows. The harder edge case is retrieval-augmented generation, where the model never sees the raw source system directly but can still leak sensitive context if the retrieval layer is over-permissive. Another common gap is shadow AI, where employees use personal accounts or unapproved extensions outside enterprise logging.
Security teams should also account for provider-side retention and training terms. If prompts or uploads are retained for model improvement, the organisation must decide whether that is acceptable for each data class. The strongest pattern is to set explicit policy by data type, enforce it in the gateway, and review exceptions regularly. NHIMG’s Ultimate Guide to NHIs — Key Research and Survey Results and the vendor research on secrets leakage both point to the same operational lesson: once sensitive data enters a tool with broad reuse paths, recovery becomes slow and incomplete.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF, NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST AI RMF | GenAI data flow governance aligns with risk management and lifecycle controls. | |
| NIST CSF 2.0 | PR.DS-1 | Sensitive data protection requires controls over data at rest and in transit. |
| NIST SP 800-63 | Strong identity assurance helps ensure only authorised users access sensitive AI tools. | |
| OWASP Non-Human Identity Top 10 | NHI-03 | Secrets and tokens in AI workflows are NHI assets that need tighter handling. |
Map AI data flows, assign owners, and set controls for collection, use, retention, and disposal.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
