Multi-agent teams multiply your blast radiusFive agents, one bad day

By early 2026 the "agent team" pattern is standard advice. Anthropic's Claude Code supports sub-agents that spawn child sessions. Cursor shipped multi-agent mode. Custom orchestration stacks built around Hermes, Roundtable's council model, and open MCP servers let you run anywhere from three to fifteen coordinated agents against a single codebase. The pitch is parallelism: one agent works on the API layer while a second writes tests and a third handles migrations. You finish in a third of the time.

What the pitch skips is the credential side of that math. An AWS key that one agent holds is in one place. The same key held by five agents, plus an orchestrator routing tasks between them, is in six places simultaneously. Each of those places has its own process environment, its own context window, its own logging behavior, and its own set of state files written to disk. The surface where that key can leak is not constant. It scales with your team size.

This is a specific instance of a general rule from blast radius doctrine: the scope of a credential determines the scope of an incident when it misbehaves. A credential that lives in six concurrent processes is a credential whose blast radius just grew by 6x.

The short version

• Every agent process that holds a live credential is an independent leak point.
• Credentials propagate through multi-agent stacks via environment inheritance, task payloads, shared files, and sub-agent context.
• Each propagation step is a new exposure surface: logs, state files, wandb runs, MCP tool calls, any I/O the agent emits.
• GitGuardian's 2026 State of Secrets Sprawl report found AI-service token leaks up 81% year-over-year, with AI-assisted commits leaking around twice as often as baseline commits.
• The fix is isolation: one broker holds secrets, each agent gets a scoped grant for the operation it needs, grants expire when the operation ends.

The probability math is not reassuring

Say you have one agent running a task that touches a live credential. Call the probability of an unintended leak per agent per session p. In a single-agent setup, your overall leak probability is p.

Add four more agents, all holding the same credential. Assuming each is an independent risk (a reasonable assumption since they're separate processes with separate I/O), the probability that none of them leaks is (1 - p)^5. Flip that: the probability that at least one leaks is 1 - (1 - p)^5.

With p at 0.01, one agent gives you 1% exposure per session. Five agents gives you around 4.9%. Over a work week with daily sessions, one agent accumulates about 5% risk. Five agents accumulates about 22%.

These numbers are illustrative, not precise estimates. The actual value of p depends on your specific agent stack, what tools it calls, what logging runs beneath it, and how it handles errors. The point is directional: more agents holding the same credential means a nonlinearly higher chance of an incident than you get from any single agent.

The math does not require adversarial behavior to become relevant. Most credential leaks in AI coding contexts are accidents: a state file lands in a tarball, a debug line includes a token value, a wandb run captures a trace with an auth header. GitGuardian found that AI-assisted commits leak secrets roughly twice as often as baseline commits. That baseline risk, doubled, applied across five agents simultaneously, compounds fast.

MITRE ATLAS tracks adversarial threats against AI systems and consistently finds that credential theft and exfiltration through model outputs are the highest-impact attack classes. OWASP's Top 10 for Large Language Model Applications lists sensitive information disclosure as a top-tier risk. Neither framework addresses multi-agent amplification directly, but the underlying mechanism is the same: more outputs, more logs, more state, more paths for a secret to escape.

How credentials actually propagate in agent teams

When an orchestrator agent spawns sub-agents, it typically hands off context in one of four ways.

The first is environment inheritance. The sub-agent process is a child of the orchestrator. By default, it inherits the full process environment. Every variable the orchestrator can see, the sub-agent can see. This is the most common pattern and the most silent. Nobody explicitly passed the AWS key to agent three. The shell did it automatically.

The second is task payload. The orchestrator serializes the task into a prompt or a tool call and includes relevant context. If that context contains a credential ("here is the API key you'll need for the S3 step"), the credential lands in the sub-agent's context window. It can appear in logs, in MCP tool call arguments, in the sub-agent's own state files.

The third is shared files. Agent A needs to pass a large context artifact to agent B, so it writes a file and tells agent B where to look. If A's environment included a token and A wrote that token into the intermediate file for any reason (debugging, serializing state, building a config for the next step), agent B reads it. Agent C, if it reads the same directory, reads it too.

The fourth is explicit delegation through MCP. An orchestrator calls an MCP tool that calls another agent. The tool call arguments, the response, and any intermediate state the MCP server persists are all locations where a credential could appear if the orchestrator included it in the call context.

None of these paths require a deliberate mistake. They are the default behavior of how processes, files, and API calls work. A developer who treats a multi-agent system like a slightly more sophisticated single-agent system will hit these paths without noticing.

Real failure patterns from single-agent incidents, now scaled

The Knostic disclosure in February 2026 found that Claude Code's settings.local.json captured environment variables from agent sessions and shipped them in npm packages. That was one agent, one file, one propagation path. In a multi-agent setup, the same failure mode multiplies.

If each of your five agents writes its own state file to its working directory, and each inherits the same environment, you now have five state files, each potentially containing the same credential. If any one of them ends up in a publish tarball or a docker image that gets pushed, the leak is identical to the single-agent case. But you have five opportunities to make that mistake instead of one.

The same applies to logging. An agent that sends telemetry to a monitoring backend (Datadog, wandb, LangSmith, any structured logger) will occasionally include context that leaked into an error message or a trace attribute. One agent doing this produces one log stream to audit. Five agents produce five. If the credential appears in an exception trace in agent four's wandb run, that run is now a credential exposure you didn't know you had.

The cross-agent file-sharing pattern produces a specific failure that single-agent setups can't reach at all. Agent A copies a .env-adjacent artifact to a shared scratch path so agent B can read it. Agent C, running in the same project directory with broad file access, reads the scratch path incidentally while searching for something else. Agent C's context now contains a credential it was never meant to see, and agent C might emit that credential in its own outputs, to its own log stream, in its own state file.

There is no malice in any step of this chain. Agent A was doing its job. Agent C was doing its job. The credential reached agent C because nothing in the system constrained which processes could read which paths. The multi-agent setup traded that constraint for convenience, and the convenience cost showed up during an audit six weeks later.

What gets missed: the orchestrator is not a firewall

Most teams think about the orchestrator as a control layer. It decides which agent does what, routes tasks, aggregates results. If you control the orchestrator, you control the flow.

That framing treats the orchestrator as if it were a security boundary. It is not. The orchestrator is another process. It holds credentials too. It logs too. It writes state files too. And because it touches every sub-agent's inputs and outputs, it's actually a higher-value target than any individual agent. An attacker who can influence orchestrator prompts (through a prompt injection in a file the orchestrator reads, for example) can redirect credential handling across all downstream agents, not just one.

NIST's AI Risk Management Framework treats multi-component AI systems as having compounding risk profiles: a failure in any component can cascade through the system. The orchestrator is the highest-centrality node in a multi-agent graph. It is therefore the highest-risk location for a credential to sit.

The common mitigation instinct is to give the orchestrator everything and let sub-agents request what they need through it. That concentrates risk at the orchestrator rather than distributing it. Better to keep the orchestrator credential-free too and use a broker that's external to the agent graph entirely.

hasp sits outside the agent graph by design. The daemon holds the vault; neither the orchestrator nor any sub-agent process inherits the raw credentials. Each agent calls the broker at the point it needs a credential, receives a process-scoped grant, and the broker's audit log records which agent got what and when. Adding a sixth agent to the team does not widen the credential surface.

A pasteable checklist for multi-agent setups

## Multi-agent credential audit

- [ ] Inventory every agent process: what credentials does its environment contain?
- [ ] Map all credential propagation paths: env inheritance, task payloads, shared files, MCP tool calls
- [ ] Confirm each sub-agent gets only the credential it needs for its specific task
- [ ] Verify no credentials appear in orchestrator-to-agent prompt text
- [ ] Audit shared scratch directories: who reads them, what lands there
- [ ] Check every agent's log/telemetry output for credential-adjacent strings
- [ ] Confirm each agent's state files (.claude/, .cursor/, etc.) are excluded from git, docker, and publish artifacts
- [ ] Set credential grants to expire when the sub-task completes, not at end of session
- [ ] Run a post-session audit log review: which grants were issued, which processes used them
- [ ] Confirm the orchestrator itself holds no long-lived credentials

What this means for your stack

The root issue is not multi-agent systems. It is the ambient credential model: secrets living in shell environments, inherited by every child process, readable by any code that runs in that context. One agent in that model is a manageable risk. Five agents is not five times that risk; it is an exponential function of it, because each new agent adds a new set of I/O paths for the credential to escape through.

The fix is a credential broker that sits outside the agent graph. It holds secrets in an encrypted local vault, issues scoped grants to specific operations on request, and injects values into individual child processes at execution time. The agent's context window never sees the raw credential. Its state files contain references, not values. Its log stream has nothing to scrape. You can add a sixth agent to the team and the credential exposure surface stays constant, because the broker handles isolation for every member of the team equally.

hasp is one working implementation. curl -fsSL https://gethasp.com/install.sh | sh, hasp setup, connect a project, and issue each agent a scoped grant tied to its task. Source-available (FCL-1.0), local-first, macOS and Linux, no account, no telemetry.

The durable principle is simpler than the tooling: treat each agent as an untrusted process that gets exactly the credential it needs for exactly as long as it needs it. The process-tree model that works for a single agent works for a team of agents, provided you apply it per-agent rather than per-orchestrator.