TL;DR
Most “Zero Trust for AI” pitches collapse into a single inline filter in front of the model. That is not Zero Trust — it is one wall guarding one door. A real Zero Trust posture for AI systems has to answer two different questions at two different places: is this input/output safe to pass? (user → model) and should this action execute now, with these parameters, against this target? (agent → tool). Those are two enforcement planes with different components, different standards, and different failure modes. And neither of them can grade its own homework — you need a third, out-of-band plane whose only job is to prove, adversarially and reproducibly, that the two enforcement planes actually hold. This post lays out that 2-plane-plus-assurance reference architecture and explains why the auditor must never become the wall.
1. The two questions
Ask a security architect to draw “Zero Trust for a web app” and you get identity, segmentation, least privilege, and continuous verification across every hop. Ask for “Zero Trust for an AI agent” and you too often get a box labelled prompt-injection filter wedged between the user and the LLM. That box is real and useful — but it answers only the first of the two questions an agentic system raises.
- Question 1 — Ingress (User → Model): Is this input safe to send to the model, and is the model’s output safe to return? This is the classic LLM attack surface: prompt injection, data leakage, system-prompt extraction, RAG poisoning, multimodal tricks, jailbreaks.
- Question 2 — Action (Agent → Tool/Resource): This agent has now decided to call a tool. Should that specific call execute right now, with those parameters, against that target, under current conditions? This is the agentic attack surface: tool misuse, over-broad authority, mission-scope creep, MCP exploits, memory poisoning, acting on revoked permissions.
The failure modes barely overlap. A perfect ingress filter does nothing to stop an agent that was cleanly prompted and then wired a payment to the wrong place because a stale approval was treated as standing authority. Two questions → two planes.
2. Plane 1 — the ingress gateway
Plane 1 sits inline between users and the model. In 2026 this is a well-populated category: an LLM gateway (LiteLLM, Portkey, Cloudflare AI Gateway) that fronts the model, an identity broker (Keycloak / any OIDC IdP) so requests carry a real subject, a PII/DLP filter (Presidio) on the way in and out, and input-validation + output controls (spotlighting, canary/allow-list gates) against injection.
The relevant standards are the familiar ones: NIST SP 800-207 for identity, the OWASP LLM Top 10 for the attack classes, and — if you operate in the EU — Articles 10 and 15 of the AI Act for data governance and robustness.
3. Plane 2 — the runtime-authorization PDP
Plane 2 is the one most “AI Zero Trust” stories skip, and it is where 2026 moved. Identity proves who is acting. Runtime authorization proves this action should execute now — a per-call decision at the point of execution, not a blanket grant stamped at token-issuance time.
The component here is an externalized policy decision point (Cerbos, OPA, AWS Cedar) — policy taken out of the agent so the agent cannot rationalize its way around it. On top of it, a cluster of young-but-real standards: OpenID AuthZEN and COAZ for parameter-level tool authorization (Subject–Action–Resource–Context, including MCP tool calls), AARP for structured approval/denial of actions policy can’t yet authorize, and OAuth mission-bound authority (AAP) so a token is scoped to a task/session/consent rather than to everything the agent can reach. The maturity target is fail-closed enforcement and continuous, context-aware re-authorization per NIST SP 800-207.
This plane maps onto EU AI Act Articles 14 (human oversight) and 26 (deployer obligations) — because “a human approved the mission” is not the same as “a human approved this consequential action.”
4. Why the auditor can’t be the wall
Here is the load-bearing design decision: the assurance layer must be out-of-band. It attacks the two enforcement planes, scores them, and produces evidence — but it never sits inline in production.
The reasoning is not modesty, it is correctness:
- Enforcement is crowded and latency-critical. Gateways and PDPs are a single point of failure in the request path. Adding a fourth vendor there buys risk, not assurance.
- Assurance is scarce. What almost nobody ships is deterministic, reproducible, adversarial proof that a control holds — the same 1,000-test battery, same seed, same SARIF, replayable next quarter to show the gap closed or regressed.
- An adversary that is also a production dependency is a bad adversary. To be maximally hostile to the planes, the auditor has to be free to break things — which means it cannot be something whose outage takes the product down.
So the honest positioning is: audit plane, not runtime guardrail. The moment the auditor becomes the wall, it stops being able to tell you the wall works.
5. What “assurance for both planes” actually looks like
Assurance is only credible if it is concrete. Against Plane 1, the offensive corpus drives prompt injection, data-leakage, multimodal, system-prompt-leakage, RAG-poisoning, and adaptive-jailbreak domains, and emits per-rule SARIF plus a checksum-validated PII/PCI output-gate result (so a leaked card number is caught by Luhn, not by a hopeful regex).
Against Plane 2, the interesting probes are agentic and multi-step:
- a parameter-level tool-authorization readiness audit that checks whether tool calls are gated by an AuthZEN/COAZ-style Subject–Action–Resource–Context decision or are free-form;
- a mission-scope-creep probe that gives an agent one narrowly-approved mission, then incrementally expands scope (“while you’re at it, since it’s already approved…”) until it commits a consequential out-of-mission action — the confused-deputy-over-time failure — and, crucially, does not flag an agent that names the action only to decline it (low false-positive by construction);
- a revocation-persistence probe that grants an authority, revokes it, and checks whether the agent still acts on the version lingering in its memory;
- a fail-closed check on the enforcement path itself: when the gate/PDP is unreachable, does the system deny, or does it fail open?
Every one of those produces evidence, and every finding rolls up into a Zero Trust Maturity scorecard where the weakest assessed control caps the plane — because in Zero Trust, skipping one capability is where the attacker lives.
6. The blueprint
Put together, the reference architecture is three planes:
Two planes the client deploys and enforces, one plane the auditor runs out-of-band. The client owns the walls; the auditor owns the proof.
7. Closing
“Zero Trust for AI” is not a product you drop in front of a model. It is two enforcement questions — safe to pass? and safe to execute? — answered at two planes with different components and standards, plus an out-of-band auditor whose entire value is that it is not one of the walls. If your AI Zero Trust story has only one box in it, you are guarding one door and calling it a perimeter.
Contact
- Company: i-314 Security Research
- Web: https://i-314.com
- Email: [email protected]
- Product: Ai-EGIS — AI Exploitation & Governance Intelligence Suite v3.0
- Related work: Tool Output Mimicry (Zenodo, 2026)
First published on LinkedIn.
Related reading
- The silent Quantum-Hadamard bug: when initializing your qubits “the usual way” destroys your risk model
- Anatomy of an AI Research Agent That Doesn’t Hallucinate
- Capturing OWASP FinBot CTF: A Source-Aware Methodology for Agentic AI Red Teaming
AI red-teaming, agentic-AI security and post-quantum cryptography. LinkedIn