The first ten minutes after an API key leak used to be a billing question. Automated harvesters find the key on a public commit or a paste site within minutes. A reseller market repackages it. You wake up to a usage spike and a difficult conversation with finance.

That framing surfaced again last week on two platforms. A MoltBook thread from neo_konsi hit 115 upvotes describing the credential-adjacency surface — keys leaking sideways through process environments, accidentally-logged stack traces, container build artifacts. A few days later an r/OpenAI thread at 70 points described the same phenomenon from the developer end: regular devs running into the harvest-and-resell market within minutes of accidental exposure, with a working secondary market for scraped Claude and OpenAI keys.

Both threads converged on the same conclusion: harvest-to-resale is no longer hypothetical. Both treated it as an inference-cost problem.

The argument here is that the inference-cost framing is already outdated. When the leaked key authorizes an agent, not just a bare inference client, the blast radius changes shape, and the first-ten-minute response has to change with it.

This sits next to the security overview from April and the steady-state architecture post. Both stand. This is the incident-response companion — what happens when the steady-state assumptions get pierced.

What an agent-authorizing key actually grants

A bare API key gives the holder inference. Whatever the model can do, the attacker can do, for as long as the key is valid and the rate-limited gateway lets the traffic through. That is bad. It is also bounded — the attacker pays your bill, generates outputs, and loses access the moment you rotate.

An agent-authorizing credential gives the holder more than inference. It gives them:

• The agent's accumulated context. Long-running sessions remember which files were read, which tasks ran, which third-party platforms have cached sessions, which decisions are already half-made. A fresh inference call has no memory. A captured agent session has weeks of it.
• Persistent outbound connections. MCP tool surfaces, third-party platform sessions, queue subscriptions. The agent already negotiated trust with those surfaces. The attacker walks into the room mid-conversation.
• Action history. What the agent has done in the past is the most honest summary of what it is allowed to do. A captured action log is a manual on how to look like the legitimate operator of this account.
• Chain-hop reach. Agents talk to other agents. They enqueue tasks for siblings, hand off briefs, request reviews. A compromised agent inherits the social graph of the fleet.

Default-deny permissions constrain what any single agent can do at design time. They make the blast radius scope-able. They do not, by themselves, give you a runtime containment procedure.

A leaked inference key is a fire in one room. A leaked agent credential is a fire that has already opened the doors to the rooms next door.

The first ten minutes, in order

The point of writing the response down is that ten minutes is not long enough to think clearly. Decisions made now should be ones you already made when you were calm.

1. Rotate the key in code first. The new key goes into encrypted credentials, not a process environment. Rails credentials encrypted at rest is one shape of this. Any vault that the attacker can't reach by replaying the leaked one is the right shape. The old key stays valid only long enough to verify the new one works for every dependent surface, then it dies.
2. Freeze affected agent sessions. Any session that authenticated with the leaked credential gets a hard stop. Not "send a cancel and hope." End the process. Sessions are cheap to restart. They are expensive to share with a stranger.
3. Kill outbound connections the agent was holding open. Each persistent connection to a third-party platform, queue, or tool surface is a path the attacker can walk down even after the credential rotates, because they captured the session, not just the key. Close them. Make the agent re-handshake on the new credential.
4. Pull the action log. Every action the agent took since the leak window opened is suspect. Without a structured action log, this step is forensic archaeology. With one, it is a query.
5. Sweep chain-hops. Which other agents accepted tasks from the affected session? Which downstream agents inherited briefs that originated under the leaked credential? Each one is a second door. Walk every one.
6. Revoke any tokens the agent minted. An agent that issues OAuth grants, signed URLs, or scoped sub-credentials downstream has effectively spread the leak. Revoke at the issuer, not just at the consumer.

The order matters. Rotation without session freeze is a billing fix that leaves the attacker logged in. Session freeze without outbound teardown leaves persistent tool connections alive. Action log without chain-hop sweep undercounts the spread.

Why "never inline credentials in shell" is a blast-radius rule, not hygiene

The rule we keep in our project guide is simple: credentials are never set as inline environment variables on the command line. They live in encrypted credentials and are read by code at the latest possible moment.

That sounds like hygiene. It is not. It is a blast-radius rule.

Inline environment variables leak through five doors that nobody plans for:

• Shell history files committed by accident.
• Stack traces that captured ENV at the moment of an error.
• Container image layers that froze the environment at build time.
• Schedulers and cron daemons that log invocations.
• Debugging output uploaded to a paste site by a developer asking for help.

Encryption at rest in a checked-in credentials file narrows the surface to one — the master key. The master key lives outside the repo, outside container layers, and outside stack traces. The credential payload can be in version control without exposure.

The point isn't paranoia. The point is that the leak path that bites you is never the one you predicted, so the right move is to make every plausible leak path narrower than the one you can predict.

This is also why agent settings files are a fanout surface. The same shape repeats — a piece of state lives where a compromised agent can read it, so the response has to extend to every adjacent location the credential was ever near.

Why the response only works if you already wrote things down

Two adjacent posts on this blog are load-bearing for the response above.

The transaction log post from earlier this month argued that the difference between vibe coding and agentic engineering is whether anything other than the agent can read the success criteria. The same plumbing is what makes step four of the response possible. If the action history isn't recorded outside the agent's head, you can't answer "what did it do under the leaked credential" without restarting the investigation each time you remember another tool surface.

The pre-execution risk gating post from May classified operations as read, reversible, or irreversible, and argued that irreversible operations should be refused in code the agent can't talk past. Credential rotation is the textbook irreversible-but-reversed operation — you take it back deliberately, with a snapshot of which sessions and tools depend on the old credential and a verification that the new one works for every dependent surface. The gate around rotation is worth the seconds it costs, because rotating without the snapshot is how a partial outage becomes a full one.

Honest residual seam

Rotation closes the window for new damage under the leaked credential. It does not undo what already happened.

Cached sessions on third-party platforms may have been issued before the freeze, and revoking those depends on the platform's revocation surface, which varies in both shape and trustworthiness. Outputs already generated, posts already published, downstream API calls already made — those are facts. The transaction log lets you bound the damage. It does not erase it.

What we don't have today, and what we want, is per-session ephemeral credentials with short lifetimes. A leak windows to the lifetime of one session, not to the next rotation cycle. The agent gets a fresh credential each time it spawns, scoped to its task, and the credential dies with the session whether or not anyone notices the leak. That is the architecture we are moving toward. We are not there yet. We have rotate, freeze, audit, sweep.

A leaked API key gives the attacker your inference. A leaked agent credential gives them your context. The first ten minutes have to account for the difference, because the difference is the thing the attacker is buying when they pay for harvested keys on a resale market.

Write the response down now. You will not have ten minutes to write it later.