An AI just found 271 dormant bugs in Firefox. Your credential vault is the softer target.

Recently Mozilla turned an AI agent loose on Firefox. Running Anthropic's Claude Mythos inside its own harness, it surfaced 271 previously unknown vulnerabilities in a single campaign: a 20-year-old flaw in the XSLT engine, a 15-year-old parsing bug, several ways out of the browser sandbox. Mozilla did this to fix them, and that is the part worth sitting with. If a defender's agent can find 271 latent bugs in one of the most-audited codebases on earth, an attacker's agent can do the same to yours. The capability is here now. It does not care who points it.

So point it at where you keep your secrets.

The math just inverted

Every centralized vault, CyberArk, HashiCorp, the whole incumbent generation, rests on an assumption that held for thirty years and stopped being true this year: that the master key sitting in process memory is safe because reaching it takes a skilled human, time, and luck. A frontier agent with code execution needs none of those. It does not crack the barrier. It reads the key out of memory the moment the vault unseals, then decrypts everything at once.

And the asymmetry is brutal. The defender has to be right every time, across an attack surface that only grows. The agent has to be right once. It probes tirelessly, in parallel, and it gets smarter every quarter. Salt Typhoon sat dormant in telecom networks for an average of 393 days before it moved. Patience like that, automated and cheap, aimed at a system that holds everything in one place.

Assume the agent gets in

Here is the premise the incumbents will not say out loud, so we will: in a real enterprise, an agent will eventually reach the box that holds the credentials. By accident, by misconfiguration, or by its own capability. Stop designing as if you can prevent that. You cannot, and the reason is where the vault lives: inside your own network, sharing a blast domain with every agent and every box you run. One tiny mistake, one breach, one lateral step, and the agent is in. That is a property of location, not of discipline. Infrastructure that is not yours does not share that fate.

The only question that matters is what happens at that moment. With CyberArk or HashiCorp, the same box the agent reached can decrypt the store. The battle was lost the instant access happened. And because these systems centralize by design, all secrets, all keys, all governance in one cluster, they are honeypots by construction. One dormant foothold yields the entire organization's secrets.

Short-lived and leased credentials help, but they do not change the geometry. They shrink the blast radius at the agent. They do nothing about the operator's own infrastructure, which still holds keys that can decrypt the store. As long as those keys live on the server, an agent that reaches the server wins.

The only architecture that survives

There is exactly one design that survives an attacker who will eventually get in: the decryption keys never live on the server at all. Compromise the entire backend and you get ciphertext. The keys sit at arm's length, on hardware the agent cannot reach.

That is not aspiration for us. It is the invariant Clavitor is built on. The vault itself cannot decrypt your credentials. The field keys are sliced from a secret that only your hardware key reconstructs, so the server, even fully owned, hands an attacker nothing but encrypted bytes. Our own design docs put it flatly: the attacker has every byte the server has, and the result is useless ciphertext.

The usual objection to arm's length is speed. Surely a vault you do not host locally is too slow, so you pull it inside your perimeter, and now it sits in the blast radius again. The rest of the architecture answers that:

• Nothing is cached. Credentials are fetched fresh per request and discarded on response. There is no decryptable copy at rest to read out of memory.
• Strangers cannot connect. Every call rides an authenticated Noise handshake keyed to an allowlist. Present a key that is not registered and the handshake never completes. The allowlist is not a filter bolted onto the edge. It is the cryptography.
• A compromised agent cannot drain. Per-agent rate limits and quotas cap what any single actor can pull, and a mass read trips an alert.
• It is fast without being local. The credential plane runs on its own globally distributed fleet, points of presence on every continent, so the nearest one answers in milliseconds. Fast enough that you never need it inside your network, and a separate blast domain, so your compromise is not ours.

Different infrastructure, different failure domain, no shared key. Take the whole of an enterprise and you still cannot take their secrets, because the thing worth stealing was never standing where the agent could reach it.

The honest edge

This does not make an agent unhackable. A compromised agent can still do, in the moment, the things it was authorized to do. What it cannot do is read the key, copy the store, or walk off and become the whole organization, because none of that was ever in its reach. We move the line to the one place a sufficiently capable attacker cannot follow: off the server entirely.

The incumbents were built for a world where the attacker was a person. That world is ending. We wrote down the rules we think a credential system has to keep once the attacker is an agent, starting with the secret never living where the code runs: clavitor.ai/rules.

The agent only has to be right once. So stop keeping the keys where it can reach them.

Clavitor (@clavitorai) is the credential vault built for AI agents, and against them. clavitor.ai

Sources

[1] Mozilla's agentic pipeline runs Claude Mythos and finds 271 unknown Firefox vulnerabilities (incl. a ~20-year XSLT bug, a 15-year parsing bug, sandbox escapes): https://the-decoder.com/mozillas-agentic-ai-pipeline-turns-claude-mythos-preview-loose-and-finds-271-unknown-firefox-vulnerabilities/

[2] Salt Typhoon: 393-day average dwell time across telecom networks before action: https://www.picussecurity.com/resource/blog/salt-typhoon-telecommunications-threat