Perimeter controls focus on networks and endpoints, but AI systems operate across cloud, SaaS, and on-prem environments where data is distributed and reused. That creates visibility gaps, overprovisioned access, and weak governance over how sensitive data enters prompts, models, and workflows. Data-centric control closes those gaps by governing the data itself.
Why This Matters for Security Teams
Perimeter controls were built for a world where data stayed inside a network boundary and users accessed systems from relatively fixed locations. AI systems break that assumption because sensitive content is copied into prompts, retrieval stores, embeddings, logs, and downstream workflows across cloud, SaaS, and on-prem environments. NIST’s NIST Cybersecurity Framework 2.0 is useful here because it pushes teams to think beyond boundary enforcement and toward continuous governance of assets and data flows.
The practical failure is not just exposure, but reuse. Once sensitive data is embedded in an AI workflow, traditional network segmentation does little to control who can prompt against it, retrieve it, or have it reproduced by the model. NHIMG research on the State of Secrets in AppSec shows how fragmented control already is: organisations maintain an average of 6 distinct secrets manager instances, which weakens centralised oversight and makes enforcement inconsistent.
In practice, many security teams discover data leakage only after a model response, retrieval path, or connected tool has already exposed it to the wrong workflow.
How It Works in Practice
Data-centric control starts by treating the sensitive artifact itself as the enforcement point. Instead of assuming the perimeter will block misuse, teams classify data, attach policy to it, and monitor where it moves. That means controlling not only storage, but also prompts, embeddings, connectors, vector databases, and model outputs. NIST SP 800-53 Rev. 5 remains relevant because controls around access, audit, and information flow can be mapped to AI pipelines when they are implemented consistently.
For AI systems, the most effective pattern is to separate the data plane from the model plane:
- Classify sensitive data before it enters prompts or retrieval indexes.
- Use just-in-time access for connectors and service accounts rather than standing privileges.
- Apply tokenisation, redaction, or masking before content reaches the model.
- Log prompt, retrieval, and output events so policy can be audited after the fact.
- Restrict model access to approved datasets and deny blind access to raw repositories.
NHIMG’s Ultimate Guide to NHIs is especially relevant because AI pipelines often rely on non-human identities rather than human users, which means entitlement sprawl can hide in service-to-service traffic. The control question is not “Is the network trusted?” but “Can this specific data item be used, transformed, or exposed in this specific context?” That is why data tagging, runtime policy checks, and short-lived credentials must work together rather than as isolated tools. These controls tend to break down in loosely governed SaaS integrations because data is copied into unmanaged SaaS storage before policy can be enforced.
Common Variations and Edge Cases
Tighter data controls often increase latency and operational overhead, requiring organisations to balance protection against developer friction and query performance.
There is no universal standard for every AI architecture yet, so guidance is still evolving on how aggressively to inspect prompts, how much content to redact, and where to place policy gates. For high-risk use cases, the safer approach is to assume that retrieval-augmented generation, copilots, and agent workflows can all leak sensitive data unless explicitly constrained. For lower-risk internal assistants, current guidance suggests tiered controls rather than blanket blocking, especially when visibility into prompts is needed for incident response and quality assurance.
Edge cases matter. A model hosted inside a private cloud can still expose sensitive information through API logs, shared vector stores, or overbroad connector scopes. Similarly, a strong network perimeter offers limited protection when the real risk is a poisoned prompt, a compromised plugin, or a misconfigured service token. NHIMG’s DeepSeek breach is a reminder that sensitive data can escape well beyond the original trust boundary when operational controls do not follow the data itself.
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 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.DS | Data security is the core issue when AI systems reuse sensitive information. |
| NIST SP 800-53 Rev 5 | AC-6 | Least privilege limits who and what can reach sensitive AI data. |
| OWASP Non-Human Identity Top 10 | NHI-03 | AI pipelines often depend on non-human credentials that expand exposure. |
| NIST AI RMF | AI risk management must address data leakage across model workflows. | |
| CSA MAESTRO | MAESTRO maps controls to AI lifecycle and runtime risk points. |
Classify, protect, and monitor sensitive data across prompts, storage, and output paths.
Related resources from NHI Mgmt Group
- Why do traditional access controls fail to protect sensitive data in cloud and AI environments?
- Why do AI systems make sensitive data harder to protect than traditional applications?
- Why do traditional DLP controls fail when sensitive data is shared through AI prompts and agent workflows?
- How should security teams govern sensitive data used by AI systems?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
