Perimeter-based zero trust falls short because AI risk sits in the data pipeline, not only in the device or network. AI systems can consume, combine, and reuse data continuously, so the control point has to move to what the data is, where it comes from, and how it may be used.
Why This Matters for Security Teams
Perimeter-based zero trust works when a system can be reasoned about as a bounded network path, but AI programmes rarely stay inside that model. They ingest prompts, files, embeddings, logs, and third-party outputs across multiple services, which means the real risk is often data reuse rather than network entry. NIST’s NIST SP 800-207 Zero Trust Architecture is useful at the access layer, but it does not by itself solve what an AI model may retain, infer, or disclose once data is inside the workflow.
This is why NHI Management Group keeps pointing practitioners back to identity, secrets, and data flow governance, not just segmentation. The Ultimate Guide to NHIs – Standards frames the core issue clearly: non-human access is only safe when the credential, workload, and usage context are controlled together. In practice, teams often discover this after a model has already been trained on sensitive material or an agent has already reused a token outside its intended scope.
In practice, many security teams encounter the failure only after sensitive data has already been embedded into an AI workflow and cannot be cleanly removed.
How It Works in Practice
The practical shift is from perimeter-centric blocking to context-aware control over data, identity, and usage. For AI programmes, that means treating each model, pipeline, retriever, and agent as a distinct workload identity with narrowly scoped access, rather than assuming a protected subnet makes the whole system trustworthy. The Guide to SPIFFE and SPIRE is relevant here because workload identity gives a cryptographic way to verify what is requesting data, not just where traffic originates.
Current guidance suggests combining zero trust networking with controls that follow the data through the AI lifecycle:
- Classify training, fine-tuning, retrieval, and prompt inputs separately, because each has different exposure risk.
- Issue short-lived credentials and rotate secrets aggressively, especially for agentic workflows that chain tool calls.
- Use policy-as-code to evaluate access at request time, not only at connection time.
- Restrict what the model can retain or retrieve, including connectors, embeddings, and output sharing.
- Log model and agent actions with enough context to reconstruct which data was used and why.
For identity proof and session control, NIST SP 800-63 Digital Identity Guidelines is still useful as a reference point, but AI programmes usually need stronger workload-centric enforcement than human login assurance alone can provide. The same applies to secret hygiene: NHIMG research on The State of Secrets in AppSec shows how fragmented secret management and slow remediation make static trust assumptions brittle, especially when AI systems can repeatedly access the same backend resources at machine speed.
These controls tend to break down when AI systems are assembled from loosely governed SaaS connectors, shadow copilots, and shared service accounts because no single perimeter control can see the full data path.
Common Variations and Edge Cases
Tighter data control often increases operational friction, requiring organisations to balance model utility against leakage risk. There is no universal standard for this yet, especially where teams want broad retrieval access for experimentation but also need strict containment for regulated data. The best practice is evolving toward tiered controls rather than one blanket policy.
Edge cases matter. A closed internal model may still be exposed if its upstream ingestion pipeline pulls from unvetted sources. A supposedly isolated assistant may still leak information if it can call external tools or share context between sessions. This is why the DeepSeek breach is a useful reminder that AI failures are often configuration and data governance failures, not just network breaches. Perimeter zero trust also struggles with cached embeddings, vector databases, and long-lived chat histories, because those assets are durable even when the original request was legitimate.
For many programmes, the practical answer is to pair zero trust with data minimisation, short retention, workload identity, and request-time policy checks. Where AI agents can autonomously decide what to fetch, transform, or forward, perimeter logic alone cannot express intent, and the control model needs to move closer to the action 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 address the attack and risk surface, while NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST AI RMF | AI RMF centers governance and risk across the AI lifecycle, not just the perimeter. | |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero Trust network controls help, but they do not cover AI data reuse and inference risks. |
| OWASP Non-Human Identity Top 10 | NHI-03 | AI systems rely on secrets and workload credentials that outlive the perimeter. |
Map AI data, model, and deployment risks to AIRMF govern and map functions, then enforce lifecycle controls.
