Why a Fleet Is Not a Bigger Single Agent
A threat model is a list of questions asked before the attack happens. For a single agent, the list is short: what can the agent access, what can it be tricked into doing, and how do we notice. For a fleet, the list changes shape. The access question becomes a graph problem. The trickery question becomes a trust problem. The noticing question becomes an accounting problem.
Most security writing treats multi-agent systems as if they were single agents with more memory. They are not. A fleet has handoffs, spawns, heartbeats, budgets, and a shared kanban board. Every one of those features is an attack surface that a single-agent threat model never enumerates. This article walks the actual threat model for the Council fleet — the one that drove the architecture documented in S7.1 through S7.3 — and shows where the boundaries really are.
The trust boundary is between agents, not around the system
In a single-agent deployment, the trust boundary wraps the process. Everything inside the boundary is “us.” Everything outside is “them.” The model is simple and mostly wrong for a fleet.
When agents hand work to each other — a parent spawning a child, a worker posting a result back to the board — the trust relationship exists between the two agents, not between the agent and some abstract system edge. A compromised child agent is not “outside the system.” It is inside, wearing a valid key, and handing forged summaries to a parent that trusts the handoff because it looks like normal work.
The Council threat model therefore treats every agent-to-agent boundary as a perimeter. That is the architectural reason for the signed task summaries in S7.3: a handoff is not a message, it is a claim about work done, and claims need verification. The ed25519 signature on every summary is not ceremony. It is the unit of trust in a system where trust lives at the seam between two agents.
What the attacker actually gets when they get one agent
The classic mistake is asking “what can this agent access?” The right question is “what can this agent cause?” A single compromised agent in a fleet can:
- Forge handoffs. Produce a signed-looking summary claiming work was done, escalating to the parent’s trust without ever touching the parent’s keys.
- Pollute shared state. Write plausible but false results to the kanban board, corrupting every downstream worker that consumes the board as source of truth.
- Burn collective budget. Trigger child spawns that consume token budget across the fleet, exhausting the credit-safety cap and halting unrelated work.
- Exfiltrate through legit channels. Route sensitive data out through the same publish pipeline that legitimate content uses, hiding in the noise.
Notice what is not on the list: reading the host filesystem or breaking out of a container. Those are single-agent concerns, and the container layer handles them. The fleet threat is lateral — movement across the trust graph, not upward through the OS. This is why the narrow gate (S7.1) inspects tool calls and why PSAA solid-keys (S7.2) scope each agent to a fixed geometry of capabilities. The container protects the machine. The gate and the keys protect the graph.
Attack surfaces unique to a fleet
Three surfaces deserve their own entries in the model, because each one is invisible in a single-agent deployment:
The spawn surface
Agents create other agents. An attacker with one compromised agent can spawn children under a stolen identity, and those children inherit scopes. The spawn protocol must therefore be a signed ceremony: the parent proves its key tier, the child’s scope is derived from the parent’s solid-key geometry, and the spawn itself is recorded in the audit log. Spawn without provenance is how a small compromise becomes a fleet-wide one.
The shared-state surface
The kanban board is the fleet’s memory. It is also the highest-value target. A board entry that looks like a completed task will be consumed by the next worker as ground truth. The defense is not to make the board read-only — that kills the workflow. The defense is to make every claim on the board verifiable: task summaries carry signatures, completions reference artifacts, and the board’s history is itself an audit trail. S7.7 documents the audit layer; the threat model is the reason it exists.
The heartbeat surface
Workers advertise liveness by heartbeat. An attacker can forge heartbeats to keep a dead or compromised worker “alive,” or suppress them to trigger a re-dispatch that doubles work. Heartbeats need the same signing discipline as everything else, and the dispatcher must treat a missing heartbeat as a signal to re-verify, not just to re-run.
What the model accepts as residual risk
No model eliminates risk; it prices it. The Council model explicitly accepts three residuals:
- Prompt injection within a single agent. If an agent’s context is poisoned, the gate cannot always detect it, because the poisoned agent may produce a valid signature on a bad decision. The defense is scope: the solid-key geometry limits what even a fully-poisoned agent can do. This is why S7.2 matters more than any filter.
- Key compromise at the root tier. If a top-tier key is stolen, the attacker holds the geometry. Detection shifts to anomaly: unexpected spawns, unusual budget flows, out-of-pattern publishes. The rotation discipline in S7.5 exists to bound the damage window.
- Collusion between two compromised agents. Two agents can sign each other’s forged handoffs and look legitimate to the rest of the fleet. The countermeasure is independent verification paths: the audit log, the graph ledger, and the external Cloudflare perimeter all observe the same events from different angles. Collusion that fools one observer gets caught by another.
From model to architecture
The threat model is not a document the Council writes and files. It is a constraint generator. Every architectural decision in the security series traces to a row in this model:
- S7.1 narrow gate ← the tool-call surface
- S7.2 solid-keys ← the scope surface
- S7.3 signed handoffs ← the trust seam
- S7.5 key rotation ← the key-compromise residual
- S7.7 audit layer ← the shared-state surface
- S7.8 DNS/DMARC perimeter ← the external surface
- S7.9 swarm persistence ← the durability surface
If a proposed feature does not map to a threat, it is either unnecessary or the model is incomplete. The model is the spec. The architecture is the implementation. And the audit log is the test suite — it records whether reality matched the model’s assumptions.
The payoff
Threat modeling a fleet is harder than threat modeling a single agent, and the payoff is proportionally larger. A single-agent model answers “did the attacker get in?” A fleet model answers “if one node is compromised, does the graph survive?” The difference is the difference between a lock on a door and a design where no door is the only barrier. The Council treats every agent as potentially compromised, and builds so that one betrayal is survivable. That is the honest definition of sovereign security: not invulnerability, but the property that a single failure does not cascade into total loss.
Grounded in wiki concepts narrow-gate-principle, platonic-solid-access-architecture, zero-trust, credit-safe-architecture, entity openfang, and the S7 security series. Design notes on a running system.
