DEV Community

TerminalBlog
TerminalBlog

Posted on • Originally published at terminalblog.com

Your Background Subagents Can Leak Secrets — Build the Isolation Model

Developers flagged a freshly filed, reproducible issue that should make anyone running background agents pause: Claude Code's background Opus subagents intermittently stall on their first turn and, instead of producing useful work, emit system-prompt fragments — including text shaped like authorization data — as their only output. It's labeled a security issue, it has a reproduction, and it's open. That's enough to treat it as a real, if intermittent, class of failure.

Here's the mental model that matters: a subagent is not a trusted subprocess. It's an autonomous loop with access to a context window, a toolset, and — too often — the same credentials as its parent. When that loop stalls and dumps its prompt instead of its result, anything that was in context is now in output. Authorization-shaped text leaking is the canary: if the prompt carried a token, a session string, or an internal endpoint, that's what surfaces.

The fix is structural, not reactive. Three rules:

1. Scope credentials per subagent, not per session. A background agent that only needs to read a repo shouldn't hold deploy keys. Hand it the narrowest token that completes its task and revoke it when the task ends. If the tooling can't scope credentials, that's a gap to close before you scale subagents.

2. Treat subagent output as untrusted. Anything a subagent returns — including error text, logs, and especially "stalled" dumps — should be parsed and sanitized before it touches shared state. Don't pipe raw subagent output into a context that feeds other agents or into any log that leaves your machine.

3. Separate the system prompt from the working context. The leak happened because authorization-shaped content sat in the same window the subagent could echo. Keep credentials and internal routing data out of the prompt that a stalled loop might surface. Put them in a side channel the model can call, not text it can print.

The deeper lesson is about failure modes, not one bug. Most agent setups assume the happy path: subagent starts, thinks, returns a result. The dangerous path is the silent one — stall, then echo. You don't get an error you can catch; you get output that looks like output. Build for the stall. Assume every background agent will, at some point, speak its prompt aloud, and design the boundary so that what it says can't hurt you.

For solo developers this is a config discipline: separate keys, minimal scopes, sanitized logs. For teams it's an architecture requirement. Either way, the model is the same — untrusted loop, scoped credentials, isolated prompt. Do that and a leaked fragment is annoying. Skip it and a leaked fragment is an incident.

Top comments (0)