Most enterprise security teams have spent the past three years building Zero Trust architectures around users, devices, and network segments. The assumption was that continuous identity verification, least-privilege access, and micro-segmentation would cover the threat surface. Generative AI pipelines break that assumption in ways that deserve an open discussion.
The core problem is that Zero Trust was designed for data at rest or in transit between known endpoints. A generative AI pipeline introduces a third category: data in context. When a retrieval-augmented generation (RAG) system assembles a prompt by pulling fragments from a document store, an email archive, and a CRM record simultaneously, it creates a composite that was never explicitly authorized by any access control policy. Each individual retrieval may pass a Zero Trust check. The assembled prompt, carrying context from all three sources, may expose something none of those checks anticipated.
Where Zero Trust maps well:
- Continuous verification applies cleanly at the model API layer. Every call from an enterprise system to an external LLM endpoint should carry a verified identity, a scoped credential, and a short-lived token.
- Least privilege translates directly to retrieval scope. A RAG system answering HR queries should not have indexing access to financial planning documents, regardless of the user's combined role permissions.
- Assume breach is the most important principle and the least implemented.
- If you treat every LLM response as potentially adversarial, you start asking the right questions: could a prompt injection in retrieved content have altered the model's behaviour? Is the response leaking information the user should not have received?
Where the model breaks down:
Zero Trust has no concept of semantic risk. A credential, a patient diagnosis, and a board-level acquisition target look identical to a network packet inspector. They only become sensitive in context, and context is precisely what generative AI systems are designed to accumulate and synthesise.
Agentic AI compounds this further. When an LLM agent calls external tools, browses internal systems, and writes back to datastores autonomously, the identity doing all of that work is the agent, not the human who triggered it. Least privilege has no clean mapping to an agent that needs broad read access to be useful but whose write scope should be tightly constrained. Most frameworks do not yet provide the primitives to express this.
What I think is needed is a Zero Trust extension layer specifically for AI workloads, covering four things: prompt-level content inspection before external transmission, retrieval-scope enforcement independent of user identity, output verification against expected response profiles, and agent action logging with human-reviewable audit trails.
For those in regulated industries, this gap is not theoretical. It is an audit finding waiting to happen.
Questions for the community:
1. Has your organisation applied Zero Trust controls specifically at the LLM API or RAG layer, or are you relying on perimeter controls and user identity alone?
2. How are you handling the identity problem for autonomous AI agents that act on behalf of users but are not themselves users in any traditional IAM sense?
3. Is there appetite in the IET community to develop guidance around AI-specific Zero Trust controls, alongside what NIST SP 800-207 and CSA have started but not yet completed for GenAI workloads?
Keen to hear from practitioners deploying these systems in regulated environments.