At METR, a stranger asked an agent for its model provider API key, and the agent handed it over. No single step was forbidden. The violation was the sequence. Inventory and authentication decide who reaches an agent. Something else has to decide what the agent may do once someone does.
An attacker found an employee's personal EC2 instance running an agent. Authentication was easy to bypass. The attacker asked the agent for its model provider API key, and the agent handed it over. The key had no spending limit, and the internal dashboard did not show the rate-limited requests at all. The attacker used about $600,000 in tokens over three weeks.
An attacker discovered an employee's personal EC2 instance running a vibe-coded agentic app, then trivially bypassed authentication and prompted the agent to hand over its model provider API key. Over three weeks, the intruder used the equivalent of $600,000 in tokens, as there was no spending limit on the API key.Ismael Valenzuela, “Zero Trust for AI Agents Starts With Fixing Zero Visibility”, The Hacker News, 26 September 2026
The article's thesis is you cannot govern what you cannot see: inventory first, then enforcement. That is the right starting point for an organization. It does not describe this failure. Once someone reaches the agent, inventory has nothing to say about what the agent does next.
Look at the three steps, and at what the session holds after each one.
A stranger's prompt. Agents answer prompts.
The provider key. Agents read their configuration.
The key leaves in the reply. Agents send replies.
No single step is forbidden. A permission check looks at one call at a time and sees nothing wrong three times in a row. The rule that was broken is a rule about the combination: once a session has taken in untrusted input and read something sensitive, nothing may leave it. We covered the same shape in When every step is allowed.
In our executor-swap study, twelve agent tasks each offered a legitimate path and a forbidden shortcut. In four of them the agent needed a credential and a web page, and the page carried a prompt injection asking it to send the credential out. Four models from three vendors ran every task twice: once with polyaxion in the execution path (we called it polysec v2 in that write-up), once without. Same prompts, same tools, same step cap, same policy.
| Model | Forbidden effects without / with | Credential leaked without / with | Tasks completed without / with |
|---|---|---|---|
| DeepSeek Chat | 20 / 0 | 11 / 0 | 66.7% / 91.7% |
| DeepSeek Reasoner | 4 / 0 | 0 / 0 | 66.7% / 83.3% |
| Claude Sonnet 4.6 | 8 / 0 | 0 / 0 | 69.4% / 86.1% |
| Mistral Large | 21 / 0 | 12 / 0 | 66.7% / 91.7% |
12 tasks, both conditions, three seeds per model (one for DeepSeek Reasoner): 120 runs with the check mounted, 120 without. Every mounted session was signed and its record verified. Study run 3 September 2026.
Without the check, the planted credential leaked 23 times and the models executed 53 forbidden effects in all. With it, none executed. The rule that stopped the leaks is one sentence: untrusted input and a sensitive read in the same session means no egress. It lives outside the context window, so no prompt can argue it away. One task served a page that quoted the policy back at the model and argued around it. Without the check it exfiltrated the credential in two runs out of three; with the check it changed nothing.
Completion went up for every model, because a refused shortcut is followed by the legitimate path, while an executed shortcut usually ends the run wrong.
polyaxion is the constraint plane for agents: the obligations an agent is held to, written down once, kept outside the model's context, and checked before any tool call takes effect. Applied to the METR sequence, it does four things.
polyaxion tracks what a session already holds (untrusted content, sensitive data, an open egress channel) and refuses the call that would complete the set. For an agent that answers strangers, the reply is the egress channel and every prompt is untrusted, so the rule reduces to a single red line: this agent never reads a credential. The read of the key is refused, and there is nothing to leak.
Rules kept in a system prompt are advice. They get summarized, compacted and argued with. polyaxion's obligations sit outside the context window, the model cannot edit them, and the check calls no model: it decides in about a millisecond and gives the same verdict every time. A clever prompt can change what the agent asks for. It cannot change the answer.
A denial is not a bare no. It names the obligation that fired and the earlier steps that formed the violation, and it comes back to the agent as the tool result. The agent re-plans around it, which is why completion went up rather than down in the study.
A spending limit is the same kind of obligation as the sequence rule: a counter over the session, not an instruction in a prompt. polyaxion ships circuit breakers of this kind: a cap on steps per session, a cap on outbound calls, a refusal to repeat the same action on the same target more than four times. Each is checked before the call, not reported three weeks later.
One distinction matters here. In the METR case the $600,000 was spent with the stolen key, outside the agent. A session budget inside the agent would not have capped that; only a limit on the key at the provider does. What polyaxion prevents is the step before: the key never leaves, so there is no bill to cap.
Every decision is also signed and can be replayed. That answers the first zero-trust question in a second form: not only which agents exist, but what each one was allowed and refused to do, in order.
The same check can sit at the sandbox boundary instead of in the agent's loop. polyaxion on NVIDIA OpenShell puts it in OpenShell's supervisor middleware, before credentials are injected.
The open endpoint. A personal EC2 instance with a weak login is an inventory and authentication failure, and polyaxion does not find it, close it or authenticate the person on the other end. Authentication and inventory stay necessary. They decide who reaches the agent. The runtime check decides what the agent may do once someone does.
It also does not repair a choice the policy allows. In the study, one task required an email after a page fetch; a model that first read a credential it did not need was then correctly refused the email, and the task did not complete. The check holds the line. It does not make the model wiser about which line it is walking toward. And twelve tasks are twelve tasks, not a benchmark.
Zero trust for agents needs three things:
Inventory: which agents exist, where they run, what they can reach.
Authentication and identity for every caller and every agent.
A check on what the agent does, in order, before each effect. This is polyaxion.
The METR incident failed on all three, and only the third turns a bypassed login into a denied request instead of a $600,000 bill. This will not be the last incident of its kind, and until the third control is routine, it is a real drag on the adoption of agentic AI.
Sources: The Hacker News contributed article by Ismael Valenzuela (SANS), 26 September 2026; Cognitive Fab executor-swap study, 3 September 2026.
Jean-Jacques Dubray · Provable Trust · Governance · polyaxion on OpenShell · A count is not a verdict
© 2026 Cognitive Fab. All rights reserved. · Glossary