Securing Enterprise AI Systems: A Zero-Trust Reference Architecture

Most organisations are bolting AI systems onto their estate faster than their security architecture can absorb them. The result is a familiar pattern: a chatbot in the DMZ, an agent framework with a service account that can touch everything, and a vector database nobody threat-modelled. This article summarises the reference architecture I maintain for securing enterprise AI systems - covering chatbots, agentic AI, and multi-agent (A2A) topologies - and the design decisions behind it.

The core stance: distributed PEPs, central PDP

The architecture applies classic Zero-Trust policy enforcement to the AI stack. Every plane - consumption, edge and DMZ, gateway, orchestration, execution and action, data and storage - carries its own Policy Enforcement Points, all deferring to a central Policy Decision Point. This is NIST SP 800-207 and XACML 3.0 thinking applied to a new workload class, and it matters because AI systems collapse traditional trust boundaries: a single prompt can traverse an internet-facing UI, an orchestrator, a model, a tool gateway, and a data store in one request.

Identity is the correlation key

The single most important control in the model is this: every event, at every plane, carries the agent identity and the delegated user identity as a correlation key. When an agent acts, it must be unambiguous which non-human identity performed the action and on whose behalf. Without that pairing, your SIEM cannot reconstruct a lineage from prompt to tool call to data access, and your incident response is guesswork.

Guardrails at three layers

• Agent guardrails - action allow-lists and scope checks before an agent is permitted to act, enforced as PEP calls to the PDP, not as prompt instructions.
• Runtime guardrails - input and output inspection, inference protection, and adversarial-input detection wrapped around the model itself.
• Human-in-the-loop approval - mandatory human sign-off for high-risk actions. Autonomy is a privilege granted per action class, not a default.

The MCP problem

Tool calling via protocols such as MCP is where agentic systems earn their risk rating. The model mandates an MCP gateway and registry: tools are signed, allow-listed, and their outputs checked before results re-enter the orchestration plane. Sandboxed execution is non-negotiable for anything that runs code or reaches external APIs.

RAG needs fine-grained access control

Retrieval-augmented generation pipelines routinely bypass decades of access control work by indexing everything into one vector store. The architecture requires tenant-partitioned, integrity-verified vector databases and row and field level filters derived from PDP obligations - so a retrieval on behalf of a user can only surface what that user is entitled to see.

Where to start

If you adopt one thing from the model, make it the identity correlation requirement. If you adopt two, add the PDP. Everything else - supply-chain provenance, secrets and KMS discipline, PKI and mTLS for service-to-service auth, immutable audit - hangs off those decisions. The full annotated diagram (v1.6) is shown above, aligned to NIST SP 800-207, XACML 3.0, the OWASP LLM Top 10 (2025), and MITRE ATLAS.