Zero Trust for AI Systems: Security Architecture Reference (2026)

Q: What is zero trust and why does it apply to AI systems?

Zero trust is the security posture in which no network location, no identity, and no prior authentication is treated as inherently trustworthy — every access decision is made fresh, against current context, on the principle of least privilege, with continuous verification rather than perimeter assumption. The framework was formalised in NIST Special Publication 800-207 in 2020 and has been the dominant enterprise security model since. AI systems inherited the assumption that classical perimeter security and standing service-account credentials would suffice, and that assumption has proven catastrophic in disclosed incidents where injected agents acted with the full authority of long-lived API keys. The model is an interpreter that executes untrusted natural-language input; agents amplify identity confusion by acting on behalf of users across multiple systems; model artefacts are part of the supply chain and can be tampered with. Zero trust addresses all three by refusing standing privilege, propagating user identity through every step, and verifying every artefact at load time.

Q: How does NIST 800-207 map onto AI components?

The Policy Decision Point becomes an AI access policy engine (OPA, Cedar, or equivalent) that evaluates every request against version-controlled policy. Policy Enforcement Points become gateways in front of every AI resource: a model gateway for every model endpoint, a retrieval gateway for every vector index, a tool gateway for every action-capable tool. Subjects include end users, agent runtimes, and fine-tuning jobs — non-humans receive workload identities via SPIFFE/SPIRE or cloud-native equivalents. Resources are model endpoints, vector indexes, tools, and artefacts, each with independent policy. Continuous diagnostics become behaviour analytics on prompts, outputs, and tool calls. Threat intelligence includes injection-signature feeds and model CVE feeds. Asset state covers model artefact integrity and prompt-template hashes verified at load time. Industry compliance — EU AI Act, NIST AI RMF, sector regulations — is encoded as policy and enforced at the PEP. The mapping is direct: the same primitives, applied to AI components.

Q: Why is workload identity essential for AI agents?

Every non-human principal in an AI system — every agent runtime, every tool worker, every fine-tuning job — needs a verifiable identity issued by an identity provider, attested at issuance, and bound to the workload's runtime properties (image hash, namespace, node attestation). SPIFFE/SPIRE is the open-standard choice; cloud-native equivalents exist. Identities are short-lived, with TTLs measured in minutes, and rotation is automatic and continuous. The shared API key as service-account credential is replaced by per-workload tokens that expire in minutes. This eliminates the entire class of standing-credential compromise: a stolen token is useful for the few minutes of its remaining lifetime and then becomes inert. Without workload identity, an agent compromise becomes a global compromise because the agent holds a long-lived high-privilege key that authorises whatever the attacker wants to do. With workload identity plus on-behalf-of token exchange to propagate the user's identity, the agent's blast radius is bounded by the user's actual permissions at the moment of the action.

Q: What are the realistic attack paths against AI systems?

Five paths cover the bulk of disclosed incidents. The compromised user account uses the agent as a proxy to perform actions the user is authorised for but the actor is not — a stolen credential issuing legitimate refunds. The poisoned document plants instructions in a corpus the retriever surfaces, executing on behalf of an unsuspecting victim through indirect prompt injection. The compromised tool endpoint returns adversary-controlled responses that the agent ingests as authoritative context — recursive injection. The tampered model artefact ships with backdoored weights or a poisoned system prompt that activates on a trigger phrase. The stolen API key uses a standing high-privilege credential to query the model and invoke tools across the entire blast radius the credential authorises. A zero-trust architecture must address all five; conventional architectures typically address only the first two. Insider risk is comparable to external risk — a developer with legitimate access to the prompt repository can ship an instruction change that exfiltrates data, so internal access must require multi-party review for production AI artefacts.

Q: What does a model gateway do in a zero-trust architecture?

The model gateway is the enforcement point that sits in front of every model endpoint — team-hosted models, model-as-a-service providers, fine-tuned variants, embedding models. Every call traverses the gateway. The gateway evaluates the call against the policy engine: is this user permitted to query this model, with this prompt, in this context, at this time, given this rate budget? It logs the call (prompt hash, retrieved context hashes, response hash, decision rationale) to the immutable audit store. It runs prompt-injection signature detection, enforces structured-output schemas, and applies output validation that refuses to release responses violating policy. It also handles credential brokerage — the gateway holds the credentials to the upstream model provider and issues per-call attestations rather than handing the agent the credentials. The model is downstream of the gateway; the gateway is the trust boundary. Without a model gateway, every team integrating with the model writes its own access logic with its own credentials, producing exactly the standing-privilege sprawl that zero trust exists to prevent.

Q: How does the tool gateway prevent damage from tricked agents?

The tool gateway is the highest-stakes enforcement point because tools are where agents perform irreversible real-world actions — issue refunds, send emails, modify records, invoke external APIs. Every tool call passes through the gateway, which performs scope checking (does the user have permission to execute this action against this resource), approval routing (does this action require human approval based on its risk class), and credential brokerage (the gateway exchanges the user's identity for a just-in-time scoped token to the downstream system rather than handing the agent a long-lived credential). High-impact tools — financial transactions, data deletion, communication sending — require either explicit user re-authentication for the specific action or human review before execution. Combined with comprehensive audit logging, the tool gateway means that even when other defences fail and the model executes an injected instruction, the tool layer either refuses the action (insufficient scope, missing approval) or logs it in a form that supports rapid investigation and reversal. This is the control that converts "the model was tricked" from a catastrophe to an audit-log entry.

Q: How does supply-chain attestation work for model artefacts?

Model weights, embeddings, prompt templates, and tool definitions are software artefacts that flow from a build environment into a production runtime, and a compromise at any point in the chain produces a compromised production system. Supply-chain attestation requires that every artefact is signed at build time by the responsible team and verified at load time by the serving runtime. The signature includes provenance metadata — build pipeline, commit hash, reviewer identities — that the policy engine evaluates: a model whose attestation is missing, expired, or signed by an unauthorised principal is refused at load. Drift detection runs continuously: the hash of the loaded artefact is compared against the registry's expected hash, and any divergence triggers an alert and a forced reload from the registry. This is the line of defence against supply-chain compromise that classical perimeter security cannot provide. Conventional package-signing tools (Sigstore, in-toto, SLSA) apply directly to model artefacts; the work is to integrate them into model-registry workflows and serving-runtime verification, which is engineering rather than research.

Q: What is just-in-time credential issuance and why is it important?

Just-in-time issuance is the practice of issuing credentials with very short lifetimes — typically 5 to 15 minutes — and requiring a fresh policy decision against current context for each renewal. Workloads, agents, and tools never hold long-lived credentials; they continuously refresh short-lived tokens, and refresh is denied if their risk score has increased. If the behaviour analytics pipeline flagged a workload's recent activity as anomalous, the next renewal is denied, and the workload's effective access ends within the existing token's TTL. This is the runtime mechanism that makes "continuous verification" a real property rather than marketing language: a workload that becomes suspicious loses access in minutes without operator intervention. Combined with workload identity, JIT credentials make standing-credential compromise impossible — there are no standing credentials to steal. The implementation cost is straightforward (modern identity providers support JIT issuance natively) and the operational benefit is profound: incident response collapses from "rotate every key in the organisation" to "wait for tokens to expire."

Q: What operational disciplines distinguish real zero trust from theatre?

Four disciplines separate working zero trust from a checkbox exercise. Quarterly access reviews for every AI resource: the set of users, agents, and workloads with access to each model, vector index, prompt template, and tool is reviewed on a schedule by the resource owner; access not used in 90 days is revoked. Red-team exercises against the policy architecture, not just the model: can a developer push an unsigned prompt template, can an agent renew a token after a risk-score breach, can a tool call execute after the user's session has expired? Run quarterly and treat policy bypasses as severity-one bugs. Key rotation as a continuous automated process: every signing key, encryption key, and workload identity certificate rotates on a cadence with no manual steps; keys older than their rotation window cannot sign or verify. Incident playbooks specific to AI compromise modes: how to invalidate a poisoned vector index, roll back a system prompt to a known-good version, disable agent autonomy while keeping read-only assistance available. Without these disciplines, the architecture exists on paper but degrades silently in production.

Q: What does zero trust not solve for AI systems?

Three limitations matter for honest planning. The model can still be wrong: zero trust constrains what an AI system is permitted to do but does not make the model accurate; a model that hallucinates inside a strictly scoped permission set is still hallucinating, and quality, evaluation, and human oversight remain orthogonal concerns. Capability concentration is not a zero-trust problem: a single highly-capable agent correctly authorised to perform a wide range of actions on behalf of a privileged user can still cause material damage if it acts on a misinterpretation; zero trust ensures the actions are auditable and bounded by the user's permissions but does not change the fact that highly-capable agents need rigorous behavioural review and rollback mechanisms beyond policy enforcement. Provider-side compromise of model-as-a-service: if the model provider is compromised, the customer's prompts and outputs are visible to the attacker regardless of the customer's zero-trust posture. The mitigations are confidential-compute deployment patterns, on-prem model serving for sensitive workloads, and contractual frameworks — not architectural patterns the customer alone can implement. Zero trust narrows but does not eliminate vendor-side risk.