They assume AI is a standalone risk when in practice it is another path for data movement and reuse. If prompts, outputs, and embedded content are not governed under the same policy model as other workflows, sensitive information can leak through ordinary user activity rather than obvious malicious behaviour.
Why This Matters for Security Teams
Separating AI security from data security creates a blind spot: teams end up treating prompts, outputs, embeddings, and retrieved context as an isolated AI problem instead of another channel for sensitive data movement. That mistake matters because leakage often happens through ordinary workflows, not only through obvious malicious prompts or model abuse. Current guidance increasingly treats AI systems as data-intensive systems first, which means the same policy, classification, retention, and access controls must apply across the stack.
This is not theoretical. NHIMG research on the Ultimate Guide to NHIs — Key Research and Survey Results shows that only 1.5 out of 10 organisations are highly confident in securing NHIs, and weak rotation plus over-privilege remain common causes of compromise. When AI services use those identities to fetch data, the risk becomes a data governance issue as much as an identity issue. The control failure is usually organisational, not technical, because security ownership gets split between AI teams and data teams. In practice, many security teams discover the problem only after sensitive content has already been reused in an AI workflow rather than through intentional governance design.
How It Works in Practice
AI security and data security should be aligned around the full lifecycle of information: ingestion, indexing, retrieval, inference, output, logging, and retention. If a model can read a document, retrieve records through RAG, or embed content into prompts, then it is participating in data processing and should inherit data policy requirements. That includes classification, masking, access control, encryption, audit logging, and deletion rules. The relevant question is not just “is the model safe?” but “what data can this workload see, reuse, and emit?”
Practically, teams should map AI flows to the same controls used for other high-risk data paths and then add AI-specific safeguards where needed. That usually means:
- Classify prompts, retrieved context, embeddings, and outputs as governed data assets.
- Apply least privilege to the data sources behind AI tools and connectors.
- Prevent sensitive fields from entering prompts unless there is a clear business need.
- Log model queries and outputs with the same retention and review expectations used for other sensitive workflows.
- Use policy checks at retrieval and output time, not just at application login.
For data handling baselines, ISO/IEC 27002:2022 Information Security Controls remains a useful reference because it ties access, classification, and monitoring together. For AI-specific risk treatment, the CSA MAESTRO agentic AI threat modeling framework helps teams reason about tool use, data exposure, and policy enforcement across agentic workflows. NHIMG has also documented real-world leakage patterns in the DeepSeek breach, where exposed records included chat histories, backend credentials, and API keys. These controls tend to break down when AI is allowed to query multiple systems through loosely governed connectors because no single team owns the full data path.
Common Variations and Edge Cases
Tighter AI-data controls often increase operational friction, so organisations have to balance leakage reduction against developer speed, analytics value, and user experience. Best practice is evolving here, and there is no universal standard for how aggressively to inspect prompts or redact outputs in every environment. The right answer depends on data sensitivity, regulatory exposure, and whether the workload is internal, customer-facing, or autonomous.
Two edge cases matter most. First, embeddings and vector stores are often treated as “not real data” even though they can preserve enough semantic context to expose confidential information. Second, agentic systems can chain tools, which means a harmless-looking prompt can trigger retrieval from protected systems and then write the result somewhere less controlled. That is why the 12,000 Secrets Found in Public LLM Training Dataset matters operationally: once sensitive content is copied into AI pipelines, it can persist well beyond the original system of record. The emerging view, reflected in the Ultimate Guide to NHIs — Key Research and Survey Results, is that data governance and identity governance must be enforced together, not sequentially.
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, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Covers credential misuse in AI data paths and connector-driven leakage. |
| OWASP Agentic AI Top 10 | Addresses unsafe tool use and data exfiltration through agent workflows. | |
| CSA MAESTRO | Maps agentic data movement and policy enforcement across tool chains. | |
| NIST AI RMF | GOVERN | Supports accountability for AI-enabled data handling and risk ownership. |
| NIST CSF 2.0 | PR.DS-1 | Data protection applies directly to prompts, outputs, and embedded content. |
Treat prompts, tools, and outputs as controlled attack surfaces with runtime checks.
