Zero Trust LLM: How the Zero-Trust Principles Apply to AI Request Flows

Zero trust is the security model that treats every request as untrusted until proven otherwise, regardless of where the request comes from. The model has been the operational baseline for enterprise network and application security for the past several years. Applied to LLM traffic, the model produces three architectural requirements that current AI deployments often miss. Identity must be verified at every request, not at the session start. Authorization must be evaluated per request against the user, the agent, the role, and the resource. The audit record must be written independently of the application or the model that handled the request. The three requirements map to the inspection-layer pattern that closes the post-authentication gap and produces the contemporaneous record EU AI Act Article 12 and DORA Article 19 reviewers expect.

I want to walk through what zero trust looks like at the LLM boundary, why current AI deployments default away from it, what the inspection-layer pattern produces, and how the architecture aligns with both the zero-trust principles and the regulatory record-keeping mandate.

Zero trust as an architectural pattern

The conventional security model assumed a trusted internal network: once a request was inside the perimeter, it could call internal services with minimal additional verification. Zero trust collapsed the implicit trust. Every request, internal or external, is treated as untrusted. The request must carry verifiable identity. The request must be authorized for the specific resource and action. The record of the decision must persist independently of the service that handled it.

Applied to LLM traffic, the model produces three architectural requirements.

Identity is verified at every request

The conventional pattern authenticates the user at the application session start, issues a session token, and trusts the session for subsequent calls. The LLM call from the application carries the application's service credential, not the user's verified identity. The session-trust assumption fails for LLM traffic because the LLM call may carry sensitive content from the user that the application's service credential alone cannot scope.

Zero trust applied here requires the identity to attach to each LLM request, validated against the IdP at request time. The mechanism is JWT propagation, service-mesh identity, or SSO-aware proxy mode. The identity is the natural person and the role, not the application.

Authorization is evaluated per request

The conventional pattern grants the application a broad authorization to call the LLM provider. The application internally decides which user can call which model. The internal decision is not visible to the policy enforcement layer. Zero trust requires the authorization decision to be evaluated externally, at the request boundary, against the per-user, per-role, per-route, per-classification policy.

The authorization decision is contemporaneous. The decision considers the identity attached to the request, the prompt classification evaluated at request time, the role authorization scope, and the route policy. The decision is pass, redact, or block. The decision is committed before the model receives the request.

The audit record is written independently

The conventional pattern relies on the application's own audit log. The application records its own decisions. Zero trust requires the audit record to be written by a system independent of the application: the inspection layer commits the record before the LLM call reaches the model. The application does not control the record.

The independent record satisfies the write-path independence test that the EU AI Act, DORA, Fannie Mae LL-2026-04, and the NIST AI agent identity and authorization framework each expect.

Why current AI deployments default away from zero trust

Three failure modes show up across enterprise AI architectures.

Application service credentials hide the user identity

The application authenticates to the LLM provider with a single shared credential. The user behind the call is invisible to the LLM provider's logs and invisible to any policy decision the provider could apply. The session-trust pattern persists from the application layer through to the LLM call.

Authorization happens inside the application

The application's code decides which user can call which model. The decision is internal, undocumented in any external policy artifact, and unreviewable by an external policy decision point. The authorization model is the application's own logic, which the regulator does not accept as a policy decision point.

Audit logs are written by the application

The application writes the audit log. The log is the application's own self-attested record. The write-path independence test fails. The regulator sees a log produced by the system under audit, which carries less weight than a log produced by an external system.

What real zero-trust LLM control looks like

The architectural pattern that satisfies the three requirements operates as an inspection layer on the AI request path with four properties.

Property 1: identity attached at every request

The user identity, the role, and (where applicable) the agent identity travel with each LLM request. The propagation is verifiable: JWT signature against the IdP public key, service-mesh identity attestation, or SSO session validation at the inspection layer.

Property 2: per-request authorization

The inspection layer evaluates per-user, per-role, per-route, per-classification policy. The decision is contemporaneous: the policy version, the role scope, the route restrictions, and the classification result are bound together at the moment of the request. The decision is recorded with the policy version.

Property 3: independent audit record

The inspection layer writes the audit record. The record is committed before the LLM call reaches the model. The record persists regardless of the application's runtime state. The record carries a cryptographic signature that prevents post-hoc modification.

Property 4: fail-closed default

Under any uncertainty, the inspection layer denies. The denial is recorded with the failure category. The default-deny posture aligns with the zero-trust principle that nothing is trusted until verified.

Compliance angle

EU AI Act Articles 12, 19, and 26 expect zero-trust-aligned architecture for high-risk AI. DORA Article 19 expects per-action logs with retention. Fannie Mae LL-2026-04 expects disclosure on demand with contemporaneous records. The NIST AI agent identity and authorization framework codifies agent identity as the third pillar that closes the post-authentication gap. The architectural pattern that satisfies the regulatory regimes is the same pattern that satisfies zero trust for LLM traffic.

DeepInspect

This is the zero-trust enforcement layer for LLM traffic. DeepInspect sits at the AI request boundary as an external enforcement layer that operates as a stateless proxy between authenticated users or agents and any LLM endpoint. Every HTTP request is evaluated against per-user, per-role, per-route, per-classification policy using identity context the calling application supplies through JWT propagation, service-mesh identity, or SSO-aware proxy mode. The per-decision audit record is committed by the proxy, independent of the application and independent of the LLM provider, before the model response returns.

The record contains the verified identity, the role and authorization context, the agent identity where applicable, the data classification applied to the prompt, the model and version called, the policy version that governed the decision, the decision outcome, and a cryptographic signature that prevents post-hoc modification. The default decision under uncertainty is deny. The latency overhead measures under 50 ms in internal testing.

Book a technical deep dive at deepinspect.ai.