A Zero Trust Architecture for Enterprise LLMs and AI Agents

A zero trust architecture for enterprise LLMs treats every request, retrieved document, model output and tool call as untrusted until a policy check allows it. In practice, that means placing enforcement points at five boundaries in the request path, giving each AI agent its own identity and narrow permissions, and keeping policy outside the model itself. The model is a component to be governed, not a security control.

What does zero trust mean for LLMs and AI agents?

Zero trust is a security model that grants no implicit trust based on network location. Every request is authenticated, authorised and assessed in context, every time. A large language model (LLM) is a system that generates text from an input, and an AI agent is software that uses an LLM to plan and take actions through tools such as APIs, databases and ticketing systems.

Classic zero trust needs adapting because LLMs blur the line between data and instructions. A retrieved document, an email or a web page can contain text that the model reads as a command. This is the basis of prompt injection, where untrusted content steers the model into behaviour its owner did not intend.

That produces two working rules. Anything that enters the context window is untrusted input, and anything the model emits is untrusted output until it has been checked.

Two terms worth fixing early

• Policy decision point (PDP): the service that evaluates a request against policy and returns allow, deny or allow-with-conditions.
• Policy enforcement point (PEP): the component that applies that decision, such as a gateway, a proxy, a retrieval filter or a tool wrapper.

Which trust boundaries exist in an LLM request path?

Most enterprise LLM applications cross five boundaries between a user’s question and a finished action. Each one needs its own enforcement point, because a control at one boundary does not cover the others.

The context boundary is the one most teams miss

Many retrieval systems index documents with broad service permissions, then return whatever matches the query. The user’s own access rights disappear at that point. The fix is to carry the user’s identity into retrieval and filter results against the source system’s permissions before anything reaches the model.

Embeddings, the numerical representations used for semantic search, can themselves reveal sensitive content. Apply the same access rules to vector stores that you apply to the documents they came from.

The output boundary is more than content filtering

Model output often feeds another system: a database query, a script, a customer message. Validate it against a schema, reject anything outside the expected shape, and never pass raw output to an interpreter with real privileges.

How do policy decision and enforcement points fit together?

Use one policy decision point and many enforcement points. The gateway, retrieval layer, tool wrapper and output checker each ask the same PDP for a decision, so policy is written once and applied consistently. This is the same idea that underpins an AI control plane, where models, agents and data are managed from a single layer.

A useful policy decision draws on several inputs rather than one:

• The identity of the human user and of the calling agent or application.
• The classification of the data involved.
• The stated purpose of the request.
• The target model and where it runs.
• The risk level of the action requested.

Keep policy as versioned code that is tested and reviewed like any other change. Log every decision with its inputs so that auditors and incident responders can reconstruct what happened.

Do not encode permissions in system prompts. An instruction such as “never reveal customer data” is a request to the model, not an enforced rule, and a determined input can override it.

How should AI agents be treated under zero trust?

Treat every agent as a non-human identity with the least privilege needed for one defined job. An agent that can read, write and send on behalf of a whole department is a standing risk, however well its prompt is written. The detail of this is covered in our guide to AI agent identity and access control; the architectural requirements are these.

1. Give each agent its own identity. Shared service accounts make attribution impossible and widen the damage of any compromise.
2. Issue short-lived, scoped credentials. Tokens should expire quickly and cover only the tools and records the current task needs.
3. Intersect user and agent rights. When an agent acts for a person, its effective permission should be the overlap of what the agent may do and what that person may do, not the union.
4. Allowlist tools. Agents should see only the tools registered for their role, with each tool validating its own inputs.
5. Tier actions by impact. Reading is low risk, reversible writes are medium, and irreversible or financial actions need explicit human approval.
6. Set limits. Cap call rates, spend and chain length so a looping or hijacked agent fails safely.

This design counters the confused deputy problem, where a privileged component is tricked into using its authority on behalf of someone who lacks it. Injected text in a document can only cause harm if the agent holds permissions worth abusing. Narrow rights shrink that blast radius, which complements the detection and filtering described in our layered prompt injection defence guide.

Does zero trust change depending on where the model runs?

The principles do not change, but the threat assumptions do. Running models in a private environment narrows who can reach them, yet it does not make the internal network trustworthy. Compromised credentials, misconfigured services and insider misuse all occur inside the perimeter.

• Public or sovereign cloud: rely on strong tenant isolation, customer-controlled keys and contractual clarity on logging and retention. Confirm where prompts, outputs and telemetry are stored.
• On-premises: segment inference servers from general networks, and authenticate service-to-service traffic rather than trusting the data centre.
• Edge: devices may be physically accessible, so verify device integrity, limit the data held locally and assume a model on the device can be extracted.

For sensitive workloads, confidential computing, which protects data while it is being processed, adds a further layer of assurance. For UAE and wider GCC enterprises in regulated sectors, placement also affects data residency obligations, so confirm requirements with legal and compliance teams before fixing the design. Our comparison of cloud, on-premises and edge deployment sets out the trade-offs.

These placement and trust questions are among the topics technical leaders will be discussing at Enterprise Private AI UAE 2027 in Dubai, and the summit programme and agenda shows how the sessions are organised.

What is a practical rollout sequence?

Do not attempt the whole architecture at once. The order below delivers risk reduction early and avoids rework.

1. Inventory. List every model, agent, data source and tool in use, including unofficial ones.
2. Classify data. Decide which data classes may reach which models and locations.
3. Route through a gateway. Make one enforcement point the only path to any model.
4. Establish agent identities. Replace shared accounts and add tool allowlists and action tiers.
5. Secure context and output. Add retrieval-time authorisation, output validation and log redaction.
6. Test and assume breach. Run red-team exercises with injected content, review decision logs and rehearse containment.

Which mistakes weaken a zero trust design?

• Authenticating the user at the front door but running retrieval and tools under a broad service account.
• Relying on prompt wording as a security control.
• Applying policy at the gateway only, leaving tools and retrieval unchecked.
• Logging full prompts and outputs without access controls, creating a new store of sensitive data.
• Giving agents standing credentials rather than tokens issued per task.
• Skipping measurement, so denied requests and policy drift go unnoticed.

Next steps for security and platform leaders

Start with a one-page map of your largest LLM application showing the five boundaries, and mark which ones have a real enforcement point today. The gaps will usually be at context and action. Close those first, then move the remaining model traffic behind a single gateway.

Then agree with your CISO and platform owners who owns the policy engine, who approves new agent permissions and how decision logs are reviewed. Finally, test the design with injected content before an attacker does.

If you have built or tested a zero trust pattern for agents, consider sharing it: you can submit an abstract for Enterprise Private AI UAE 2027, taking place in Dubai on 17–18 March 2027.