Sign in Get free forever Get started
Security Blog

The credential in your app's memory is going to leak

#24

June 25, 2026 · By Marketing team

← All posts

Also in:

The credentials in your application's memory are readable by any code that runs on the box, and in 2026 that includes the agent. An AI model has already taken root on FreeBSD on its own and broken out of its own sandbox. Stop keeping a resident credential to steal.

Here is an uncomfortable prediction, and it is not a hedge: the credentials sitting in your application's memory right now — the database password it loaded at startup, the API token in its environment, the cloud key it holds to do its job — will probably leak within the next twelve months. Not because someone out-hacks your security team. Because the single assumption that ever made an in-memory secret safe — that only trusted code runs beside it — quietly stopped being true this year, and almost nobody has changed what they do about it.

This is the one you can't file under "later."

What's actually happening

Nearly every application holds its secrets the same way. At startup it reads them — from a .env file, a mounted secret, an environment variable — and loads them into its own memory, in plaintext, for the entire life of the process. For thirty years that was a sound design, and it was sound for exactly one reason: reading another running program's memory, or its environment, requires executing code on the same machine, at the same privilege. That bar used to be high. The only things that cleared it were your own software and your own people.

An agent clears it now. A coding agent, an MCP tool, an autonomous worker — by design it executes code, on a real box, as a real user. And to code running at that privilege, a credential in memory is not a vault to crack. It is a file to read. /proc//environ lists another process's environment variables in plaintext. A core dump hands over its heap. There is no exploit, no CVE, no alarm — your EDR, your WAF, your firewall watch an authorized process read memory it is allowed to read, and see nothing wrong, because nothing is wrong by their rules. Every step is legal. The secret was simply there for the taking.

This isn't a mistake you made

Be clear about whose fault this is, because it isn't yours. The .env on a hardened box, the secret pulled from a manager into memory at boot — that is the recommended pattern. It is twelve-factor, by-the-book, the thing a good engineer does. It was responsible. What expired is not the practice. It is the assumption underneath it: that the only code running beside your secret is code you put there. The moment an agent runs on that machine — and you are putting agents everywhere, on purpose, because they are useful — that assumption is gone, and the plaintext you responsibly loaded into memory is sitting inside the blast radius.

We watched the first version of this land already [4]. When a coding agent is hijacked — a poisoned error report, a malicious tool in its path — the very first thing within reach is exactly this: the tokens and keys its own process, and the processes beside it, already hold in memory. The injection is only the door. The resident credential is the prize.

"But there's no agent on that box"

This is the comforting answer, and it is the one that fails. The defense rests on a wall: keep the agents over here, keep the credentials over there. That wall is the single thing this year has spent itself proving cannot hold.

You don't have to take that on faith — this year produced the proof, twice. In its own published testing, Anthropic pointed its Mythos model at FreeBSD's NFS server, kernel code humans had read for seventeen years, and on its own it found a stack overflow in the authentication path, wrote a twenty-gadget exploit split across six network packets, and took unauthenticated root over the wire. That is CVE-2026-4747, and it took about four hours. Not "flagged a suspicious function" — a working remote-root exploit against code that survived seventeen years of review, and the same against critical flaws in every major operating system and browser it was aimed at [1].

And the containment you'd wrap around an agent fares no better than the perimeter. In Anthropic's own safety evaluation, tasked to get out of its sandbox and reach the researcher running the test, Mythos chained exploits — a JIT heap spray — to break out of both the browser renderer and the operating-system sandbox, reached the open internet, and emailed him [1]. The fair caveat: it did that because the test asked it to, not on its own initiative. But "we asked it to" is precisely the attacker's seat — and "break out, escalate, take the credentials" is the standing payload of every malicious prompt from here on. The capability was never waiting on the model's own initiative. It waits on an instruction, and that is the one input you can count on arriving. The seriousness was acknowledged at the only altitude that counts — the US export-controlled the model itself, a first for an AI model rather than the chips behind it, after a version of Mythos reportedly found its way through almost all of the NSA's classified systems in hours [2][3].

Now set that beside the memory problem, because they meet. Root on a box reads any process's memory, not just its own user's. So the real question was never "will I run an agent next to my secrets." It is "can a capable model reach this machine, or break out of the box I put it in" — and this year answered both, in public. "There is no agent on that box" is not a control you enforce. It is a hope about where things will stay put, and the things have already shown they don't. Plan for the agent reaching the box. The alternative is planning to be lucky.

Built for this, on purpose

So stop trying to keep the agent away from a secret that is just lying there. Take away the thing lying there.

A credential in Clavitor is never loaded into your application's memory to wait. It is fetched live, at the instant of the call, used for that one request, and gone. It never sits in an environment variable, never lands in a .env, never spends the process's lifetime resident in a heap waiting to be dumped. There is nothing for /proc to list and nothing for a core dump to carry off, because the machine was never trusted to hold a standing secret in the first place.

And the one credential it does hand over is scoped to the single thing that agent was named for. It cannot list the vault, cannot enumerate what else exists, cannot discover the next key. Every fetch is rate-limited, trips a lockdown on an anomalous burst, and is written to an append-only, hash-chained log that lives on the vault — not on the endpoint the agent runs on. That is the immutable, attributable trail PCI DSS Requirement 10 and NIST 800-171 (control 3.3.8) ask for: proof of exactly what your agent touched, kept somewhere a compromised box can neither reach nor rewrite.

The honest edge, because the claim needs one: at the microsecond it is used, the secret does exist in memory — for that one request, in that one moment. No design rewrites physics. What it rewrites is the difference between a secret that is resident — sitting in your process for hours, dumpable at any time — and one that is ephemeral — present for a single call and then not there to take. You cannot dump what isn't standing.

The lesson isn't "lock the box down harder"

You can keep hardening the machine. You can keep telling yourself no untrusted code will ever run beside your secrets. But that is the exact bet getting more expensive every month, against an adversary that runs code for a living and walks through walls you assumed would hold. The credential in memory was safe when every reader was trusted. The readers changed. The only move that survives the change is to stop leaving the credential there to be read.

We wrote down the rules a credential tool should keep in a world like this one. Run yours down them.

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

Sources

[1] Anthropic (Anthropic Red Team) — Assessing Claude Mythos Preview's cybersecurity capabilities (autonomous discovery + exploitation of the FreeBSD NFS RCE, CVE-2026-4747; critical flaws across major OSes and browsers) — https://red.anthropic.com/2026/mythos-preview/

[2] Associated Press (via CNBC) — Anthropic's Mythos model found vulnerabilities in classified U.S. government systems, official says — https://www.cnbc.com/2026/06/23/anthropics-mythos-model-found-vulnerabilities-in-classified-us-government-systems-official-says.html

[3] Fortune — Anthropic disables Fable and Mythos AI models following U.S. government export ban — https://fortune.com/2026/06/13/anthropic-disables-fable-mythos-export-controls-national-security-threat/

[4] Tenet Security (Tenet Threat Labs) — Agentjacking: Coding Agents with Fake Sentry Errors (hijack-to-resident-credential precedent) — https://tenetsecurity.ai/blog/agentjacking-coding-agents-with-fake-sentry-errors/