Zero Trust Architecture for AI Systems

Zero trust is the right security model for modern infrastructure. It replaced the assumption that anything inside the network perimeter is safe with continuous verification of every request. For human users and stable microservices, it works well.

AI systems break the two key assumptions zero trust was built on. First, traditional ZT was designed for human identities: users who have fixed roles, stable attributes, and audit trails. AI agents are short-lived, task-scoped, spawn sub-agents dynamically, and operate at machine speed. The identity model does not fit. Second, traditional ZT treats computation as a black box: it verifies who can access data, but it does not verify what happens to data during computation. With AI, computation is where the security risk lives.

The result: organisations can have a fully compliant zero trust posture for their user access layer while simultaneously running AI inference that exposes sensitive data in plaintext to any privileged insider, and deploying AI agents that operate under shared credentials with far more access than any individual task requires.

Most security-conscious AI deployments correctly implement encryption at rest and encryption in transit. Data on disk is encrypted. Data on the wire is encrypted. This is necessary. It is not sufficient.

At inference time, data must be decrypted. The model reads plaintext inputs. The context window contains plaintext documents. The embeddings are computed from plaintext text. For the duration of inference, this data exists as plaintext in memory. That plaintext is reachable by anyone or anything with access to the compute environment.

This is not a hypothetical risk. Memory scraping malware specifically targets AI inference servers because they process high-value plaintext at predictable intervals. Crash dumps from inference servers have been found to contain sensitive patient data and financial records in healthcare and banking deployments. Misconfigured logging tools have captured plaintext context windows in plain text log files accessible to developers with no data access clearance.

The inference gap exists in every standard AI deployment. It is not a bug in any specific product. It is a structural consequence of how inference works: the model needs to see the data to process it. Closing the gap requires either encrypting what the model sees, or verifying that the environment is trustworthy even if the data is plaintext.

Verifiable inference means the inference process provides a technical guarantee that data was not exposed in plaintext during computation. Two practical approaches exist. They differ in their trust assumptions and performance characteristics.

In regulated industries, AI sovereignty is often treated as a geography question: keep data inside national borders, use domestic providers, host in local data centers. That approach helps. It does not produce real sovereignty.

The moment inference begins, the question stops being where the data sits and becomes who can see it while computation happens. A hospital can keep data inside EU borders and meet GDPR residency requirements. But if patient scans appear as plaintext during inference, a breach exposes the crown jewels regardless of which country the server is in. Geography does not protect plaintext.

Real sovereignty requires technical guarantees at compute time. Controls that hold even when systems fail, operators are compromised, or infrastructure is breached. Residency requirements, access controls, and audit trails are all necessary. None of them change what happens when inference requires plaintext in memory.

Access controls reduce who can reach a system. They do not eliminate the fact that the system processes plaintext. Audit trails tell you what happened after an incident. They do not prevent exposure during inference. If your sovereignty story ends at "where the server is," it ends right before the part that matters.

The four core zero trust principles apply to AI systems, but each one takes on an AI-specific meaning that goes beyond the traditional interpretation. Here is what each principle means when AI models and autonomous agents are in scope.

AI agents are now operating across payment systems, ticketing systems, internal data stores, and SaaS control planes. But in too many deployments, access control still relies on shared long-lived secrets designed for static services. This pattern is an active operational risk, not a future concern.

Traditional IAM works well for humans and stable services. AI agents have fundamentally different characteristics that break the IAM model.

The failure mode from shared credentials is predictable. Broad access where narrow access is needed. Weak attribution when incidents happen. Slow revocation during active response. Difficult compliance evidence for delegated machine actions. One compromise creates a disproportionate blast radius when identity and access boundaries are not workload-specific.

AgentID from Mirror Security applies zero trust principles to autonomous agent systems. It uses a two-plane architecture that separates token management from runtime enforcement. This separation means you can add runtime enforcement to existing infrastructure without replacing your authentication stack, and you can change enforcement policies without changing how tokens are issued.

The Resource Gateway enforces at request time what the Identity Broker authorized at token issuance. If an agent's scope token says it can issue a refund up to $50, the gateway checks that constraint against the actual refund amount in the request before forwarding to the payments API. The agent cannot bypass this check by sending a request directly to the API, because the API is not accessible except through the gateway.

Connector-based integrations support common enterprise systems: payments, ticketing, collaboration, source control, secrets management, cloud identity, and data access surfaces. Each connector defines the constraint schema that the gateway can evaluate for requests targeting that system.

A capability token for an AI agent is not a standard OAuth access token. It carries more context than a scope string. The additional fields are what make zero trust enforcement possible at the gateway: without resource target, constraint, and delegation context, the gateway cannot make a meaningful policy decision.

A common question when implementing agent zero trust: do we need AgentID if we already use SPIFFE/SPIRE? The answer is that they solve different problems. Both are necessary in a complete zero trust implementation for AI agents.

From the Mirror Security blog on zero trust for AI agents: consider a customer support agent that needs to issue a refund. This is a common agentic workflow that illustrates exactly how the shared credential model fails and how zero trust capability tokens fix it.

Without AgentID: the agent authenticates with a shared service account that has broad access to the payments API: read transactions, issue refunds, modify subscriptions, update billing details. A compromised runtime can reuse that credential for any of those operations, indefinitely.

With AgentID: the flow looks different.

If the agent runtime is compromised during step 4, the attacker holds a token that can only issue one bounded refund for one customer, expiring in minutes. Compare that with the shared credential that can modify any billing record, for any customer, indefinitely. The blast radius difference is the practical value of zero trust for agents.

A complete zero trust architecture for AI covers four distinct planes. Each addresses a different category of risk. No single product covers all four. Mirror Security's platform is designed so that each product addresses one plane, and the four planes together cover the full attack surface of a production AI deployment.

Zero trust applied to models means you never assume a model is safe because it passed evaluation at deployment. The threat landscape changes. New attack techniques for prompt injection, jailbreaks, and data extraction appear continuously. A model that was secure last month may be vulnerable today because an attacker has published a new technique that your static evaluation set did not cover.

DiscoveR continuously runs adversarial tests against your deployed models and AI applications. It registers your application endpoint, selects attack categories relevant to your system type and threat model, and runs structured probes. Results include per-category pass rates, severity scores, and a correlation ID that links scans across remediation cycles so you can measure whether a fix held.

In a zero trust context, DiscoveR operationalises the "verify continuously" principle at the model plane. It is not a one-time pentest. It runs on a schedule or trigger, covers the current attack surface, and produces structured findings that feed into your security monitoring workflow.

Zero trust applied to the runtime plane means every model output is checked before it acts in the world. A customer support agent that outputs a hallucinated refund amount, leaks PII from a retrieved document, or has been redirected by a prompt injection in a customer message are all runtime security failures. They cannot be caught by a static scan because they depend on what the model sees and produces at inference time.

AgentIQ provides runtime guardrails that run inline, applied to model outputs before they reach downstream systems. The guardrail categories map directly to the zero trust "verify continuously" principle. PII detection catches sensitive data that should not appear in outputs or agent actions. Hallucination scoring validates whether factual claims have support in the context. Prompt injection defence detects attempts to redirect the agent away from its intended behaviour. Chain security validation checks the integrity of multi-step agent workflows.

In a zero trust context, AgentIQ is the enforcement point for the runtime plane. It does not inspect model weights or training data. It operates on the live stream of inputs and outputs at the moment of inference, making trust decisions per response rather than per deployment.