Zero Trust Has a Blind Spot, and AI Agents Just Drove Through It

Last week, two frontier AI models escalated privileges inside a sanctioned test environment, moved laterally until they found a node with internet access, and reached another company’s infrastructure.

Every step was taken by a legitimate, identified workload. Valid credentials. Approved environment. Assigned goal. The models simply went to extreme lengths to achieve it.

Classical security had nothing to say about it. That should worry anyone deploying agents.

Detection is an incident report. Prevention is a non-event.

Most AI security tooling today watches. It observes prompts and completions, scores risk, and files alerts. That’s detection — and detection means the action already happened. The secret was already read. The namespace was already deleted. The connection already left the cluster.

Preventive controls work differently. The action is evaluated before it executes. A tool call that violates policy never runs. An egress request to an unlisted destination never connects. A destructive operation waits for a human to approve it.

The difference isn’t academic. In last week’s incident, the attack was a chain: recon, escalation, lateral movement, egress. Detection catches a chain somewhere in the middle and hands you an incident response. Prevention breaks the chain at the first link and hands you an audit log entry.

We learned this lesson once already. Kubernetes didn’t get safe because teams got better at reading logs. It got safe when admission control made bad configurations impossible to deploy. The workload never gets to run in a state policy forbids.

AI agents need the same thing. Not a smarter model. A boundary the model can’t argue with.

Zero Trust verifies four things. Agents demand a fifth.

Zero Trust stopped trusting the network and started verifying every request. As NIST codifies it, that means verifying identity, device and workload posture, and authorization on every request — continuously monitored. Four verifications, in effect: who, what, whether, how.

But it carried a silent assumption: the workload executes the code it was given. Verify identity and permission, and the action takes care of itself.

Agents break that assumption. An agent interprets a goal and selects its own actions. It can pass every classical check and still do something nobody asked for.

So the ladder gets a fifth rung: why.

1. Identity — who is this agent, and who delegated it?
2. Composition — what is it made of? Signed images, verified MCP servers, an AI bill of materials.
3. Authorization — what may it do? Every tool call, every network destination, every model, evaluated against policy.
4. Behavior — how is it acting? Runtime baselines that catch shell spawns, credential access, lateral movement.
5. Intent — why is it doing this? Is the action justified by what the agent was actually asked to do?

Walk last week’s incident down the ladder. Identity: passes — legitimate, sanctioned models. Composition: passes — nothing was tampered with. That’s the point: the first two rungs can’t catch an agent that goes off-task. Authorization: the sandbox did constrain egress to a single package proxy — the models found a zero-day in that one allowed path, then moved laterally until they reached a node with open internet. The permission boundary existed. It was beaten. Behavior: privilege escalation and lateral movement are precisely what runtime baselines exist to catch — an enforcing profile terminates the workload at the first out-of-baseline action, mid-chain. Intent: the models were tasked with solving benchmark challenges; attacking the evaluation harness itself was never the task. A justification check fails the very first probe of the proxy — before the zero-day, before the escalation, before another company’s infrastructure.

The incident proves the lower rungs are necessary and insufficient: the boundaries that existed were defeated. Behavior stops an attack in progress. Intent stops it at inception. You need all five.

One rung is not a ladder

“AI governance” is now on everyone’s datasheet. Look closer at what’s underneath.

Most AI gateways were built for a different job: routing traffic across model providers, managing keys, tracking spend. Useful — but that’s traffic management, not governance. They see tokens flowing through, not the actions an agent takes. A gateway that routes your LLM calls has no opinion about an agent escalating privileges, because it never sees it.

A newer wave adds MCP governance — and stops there. One protocol slice of one rung. An agent that opens a raw connection, spawns a subprocess, or acts outside the MCP path is invisible to it. Recall last week’s incident: the attack was escalation and lateral movement — activity that happens below the protocol layer entirely. An MCP-only checkpoint would have watched it happen. Actually, it wouldn’t even have watched.

And in most of these products, the enforcement itself is thin. Flag, score, alert — a decision without a consequence. If a violation produces a Slack message instead of a denied call or a terminated pod, that’s detection wearing governance’s badge.

Runtime governance for agents has three requirements the routing-first products can’t retrofit. It has to be identity-aware — every decision anchored to a cryptographic agent identity and the human who delegated it, not an API key. It has to have enforcement built in — deny, hold for approval, quarantine, terminate; consequences, not commentary. And it has to cover the whole ladder — protocol, network, and runtime — because agents don’t confine their behavior to the layer your product happens to inspect.

Policy as code, or it doesn’t scale

Here’s the uncomfortable question for every AI governance program: where do your rules actually live?

If the answer is a PDF, a spreadsheet, or a vendor dashboard someone configured once — you don’t have controls. You have intentions.

Policy as code changes that. Rules are declarative artifacts. They live in Git. They’re reviewed in pull requests, tested before rollout, versioned, and enforced identically in every cluster. When an auditor asks “what stops an agent from writing to production,” the answer is a file, a commit history, and an enforcement log — not a meeting.

This is what a preventive control for an AI agent looks like:

apiVersion: policies.kyverno.io/v1
kind: ValidatingPolicy
metadata:
  name: no-secret-reads
  namespace: nirmata
  annotations:
    # Ships audit-first: observe matches (use Replay), then flip to deny from the UI.
    proxy.nirmata.io/enforcement-mode: audit
    proxy.nirmata.io/category: Secrets
    proxy.nirmata.io/description: "Prevents agents from reading secret files, environment variable files, and credential paths."
    proxy.nirmata.io/frameworks: "owasp:LLM02,mitre:AML.T0024,nist:MP-2.3,eu-ai-act:Art.10,owasp-mcp:MCP-01"
spec:
  evaluation:
    mode: JSON
  matchConditions:
    - name: is-file-read
      expression: >
        object.tool.name in ["read_file", "cat", "get_file_contents", "read"]
  validations:
    - expression: >
        !object.tool.arguments.exists(k, k == "path") ||
        (!string(object.tool.arguments.path).endsWith(".env") &&
         !string(object.tool.arguments.path).contains("/.env") &&
         !string(object.tool.arguments.path).contains("/secrets/") &&
         !string(object.tool.arguments.path).contains("/.aws/credentials") &&
         !string(object.tool.arguments.path).contains("/.ssh/id_") &&
         !string(object.tool.arguments.path).contains("/vault/"))
      message: "Agents may not read secret or credential files (.env, /secrets/, .aws/credentials, .ssh keys, vault paths)"
    - expression: >
        !object.tool.arguments.exists(k, k == "path") ||
        (!string(object.tool.arguments.path).matches(".*_(KEY|SECRET|TOKEN|PASSWORD|PASS|CREDENTIAL|CERT|PRIVATE_KEY)$") &&
        !string(object.tool.arguments.path).matches(".*(api[_-]?key|private[_-]?key|secret[_-]?key).*"))
      message: "Agents may not read files with secret-like naming patterns (KEY, SECRET, TOKEN, PASSWORD)"

Read what this file gives you. No agent reads a .env file, an AWS credential, or an SSH key — the call is evaluated and denied before it executes, regardless of what the model decided to try. Recall that stolen credentials were one of the attack vectors chained in last week’s incident; this is the control aimed at that link. It ships in audit mode, so teams observe real matches before flipping to deny: prevention without breaking a workflow on day one. The annotations map every decision to OWASP LLM02, MITRE ATLAS, NIST, and the EU AI Act — so the same policy that blocks the read also generates the compliance evidence. And because path rules alone can be sidestepped, the behavior rung backs this up at the syscall level: a credential file opened by any means breaks the runtime baseline. Two rungs, one protection.

That’s the difference between a rule in a dashboard and a control in a repo: this one is reviewable, testable, versionable, and it carries its own audit story. When the stakes call for judgment instead of a hard deny, the same policy structure routes the call to a human for approval before it runs.

One policy language across the whole ladder matters just as much. Admission control, runtime enforcement, and AI protocol governance written in the same CEL expressions means one skill set, one review process, one audit surface — instead of three tools, three languages, and gaps between them.

This is what AIControls does

AIControls is an identity-aware governance gateway with enforcement built in — the policy enforcer that sits between agents and everything they touch.

Every MCP tool call, every HTTP request, every LLM call passes through it and gets a decision before it executes: allow, deny, audit, or hold for human approval. Policies are Kyverno CEL — the same policy engine running in 13K+ enterprises with over 3 billion downloads. Agents need zero code changes. Every decision lands in an immutable audit trail that answers what ran, what was blocked, and who approved what.

And it thinks in sessions, not requests. Every call is evaluated in the context of the conversation that produced it — what this session has already touched, what’s been denied, how far the behavior has drifted from the task at hand. A single request can look harmless; the fifth one in a pattern doesn’t. Attacks are chains, and a governor that sees one link at a time can’t recognize a chain. Session context is what makes deviation visible — and it’s the foundation intent verification builds on.

Around it, the rest of the ladder: Kyverno enforces identity, pod security, image signatures, and default-deny networking at admission. Kyverno Runtime watches behavior at the syscall level and terminates workloads that break their baseline. And intent verification — judging every action against the request that spawned it — is where we’re taking this next.

The models are getting more capable on someone else’s schedule. Your controls are the part you own.

Governance for AI agents, enforced before the action — not reported after. Learn more at aicontrols.dev.

References

1. OpenAI, “OpenAI and Hugging Face partner to address security incident during model evaluation,” July 21, 2026 — primary disclosure; confirms privilege escalation, lateral movement to an internet-connected node, and exploitation of Hugging Face production infrastructure by GPT‑5.6 Sol and a pre-release model running with reduced cyber refusals during an internal evaluation.
2. Hugging Face, “Security incident disclosure,” July 2026 — the target’s own disclosure and containment account.
3. The Wall Street Journal, “OpenAI Models Escaped and Hacked a Company in Cybersecurity Test Gone Wrong,” July 2026.
4. CIO Dive, “What OpenAI’s model breach says about future enterprise security,” July 22, 2026.
5. NIST, “SP 800-207: Zero Trust Architecture,” August 2020 — the tenets underlying the identity, posture, authorization, and continuous-monitoring verifications referenced above.