49 Ways to Break a Handoff
A complete security teardown of a babyagi-based researcher / writer / editor pipeline: twelve findings in the framework beneath it, forty-nine attack vectors grouped from plumbing bugs through model-level and whole-system failures, the exact command and real transcript behind every runnable exploit, and a working patch for the subtlest one — a correct authorization check that quietly leaks its secret scope, one bit per question.
What this audit found, and against whom
The framework beneath the pipeline is an open execution surface by construction. Four findings are critical: arbitrary code execution via exec() of database-stored function bodies; every stored secret injected into every function's global scope; an unauthenticated REST API whose PUT /api/function/<name> rewrites code remotely; and that API bound to 0.0.0.0:8080 by default. Any one of them is enough to own a deployment that handles real credentials. The pipeline built on top then adds a second class of problem: the agents share state, identity and control with no ownership, authentication or integrity checks, so the space between the agents is as exploitable as the framework under them.
Threat model
Each vector below assumes one of a small number of attacker positions. Stating them up front is what separates a demonstrated exploit from a hypothetical one.
| Attacker position | What it grants | Groups reached |
|---|---|---|
| Task / prompt access | Supplies the task string or any document the pipeline ingests; controls text that becomes facts, drafts and model prompts. | B, C, G |
| In-process code | Runs in the same Python process as the agents (via the framework's RCE, a malicious pack, or a supplied agent object); can read and write shared state directly. | B, D, E, F |
| API / network access | Reaches the unauthenticated REST API or the message bus over the network. | 01, B |
| Shared-state influence | Can shape what agents observe, without compromising any single agent, including the relationships between agents' outputs. | H, I, J |
Where a vector requires in-process code, that is a high bar on its own — but the framework audit shows how cheaply that bar is cleared here, which is precisely why the pipeline's missing internal boundaries matter.
A three-agent pipeline, built twice
The target started as babyagi's functionz framework, functions stored as source strings in SQLite and run with Python's exec(), secrets injected into the same scope, served over an unauthenticated Flask API bound to 0.0.0.0:8080. On top of that sat a three-stage content pipeline: researcher gathers facts, writer drafts, editor reviews.
That pipeline was then rebuilt as a genuine multi-agent environment (real_multiagent/): a SharedEnvironment both agents read and write, a MessageBus agents publish to, and an Orchestrator that ticks each agent in a fixed order until the editor marks the task done. Every vector below targets this second version.
babyagi's functionz: proof-of-concept, not production
Before touching the pipeline, we read the framework it's built on line by line: core/execution.py, dashboard/, api/, db/models.py. Its design is a textbook remote-code-execution surface by construction, not by bug.
Finding 1: arbitrary code execution
core/execution.py runs every stored function with:
Functions are source strings in SQLite with no sandbox. exec() has full interpreter, filesystem, and network access, anyone who can register or regenerate a function (including the self-building agent) gets arbitrary code execution for free.
Finding 2: secrets injected into global scope
Every function can read every stored secret via globals(), whether or not it declared that key as a dependency. One compromised function leaks everything.
| Severity | Finding |
|---|---|
| Critical | Arbitrary code execution via exec() of DB-stored function bodies (above). |
| Critical | Secrets injected into every function's global scope, no per-function scoping (above). |
| Critical | The dashboard and REST API have no authentication; PUT /api/function/<name> overwrites code remotely, RCE over HTTP. |
| Critical | app.run(host='0.0.0.0', port=8080), the unauthenticated API is network-exposed by default, not localhost-only. |
| High | Secrets are encrypted with a Fernet key stored next to them on disk (encryption_key.json), unbound to any machine or master password. |
| High | Input validation checks parameter names only, never type, value, or length. |
| High | Default packs auto-load on import via importlib.util.spec_from_file_location, executing arbitrary files with no review step. |
| High | Dependency resolution exec()s each dependency before calling it, and unbounded depth risks a DoS on a deep/cyclic graph. |
| Medium | Execution logs can capture scope contents, so a careless function call persists secrets in plaintext. |
| Medium | Unhandled tracebacks return to the client, leaking paths, DB contents, and internal state. |
| Medium | No rate limiting or auth on /api/*, automated abuse and enumeration are trivial. |
| Medium | A default pack defines a function literally named os, risking stdlib shadowing inside a function's namespace. |
Twelve findings in total, four of them critical. Together they make the framework an open execution surface: any deployment needs a sandboxed runtime, an authentication layer, and a localhost-only binding before it handles real credentials.
Every command, every transcript
The forty-nine vectors fall into ten groups, ordered roughly from the most concrete to the most abstract. The first group covers structural flaws in how agents pass work to each other; it was found by tracing the orchestrator's code path by hand, and its issues are exercised live by the coordination group further down. Groups B through F are runnable exploits against the real pipeline code. Groups G through J model failure modes that exist only at the level of the whole system: meaning, consensus, causality and belief.
Each group has two dropdowns. How each vector works explains every vector in plain terms: what the attacker does, why the system allows it, and what breaks as a result. The transcript dropdown reproduces the exact command and the real output of the run.
How to read the count
Three honest caveats keep the "49" from overstating the case:
- 1Root cause vs. manifestation. Several vectors share a single underlying weakness. The message-bus dead code (A1) and the message sinkhole (F5) are one unread-bus defect; order-fragile hand-offs (A2) and turn-order poisoning (F1) are one unprotected-ordering defect; the REVISE dead-end appears in both A3 and F4; shallow snapshot aliasing (A6) and the shared-state alias (F2) are one aliasing defect. Group A is the architectural finding; groups B–F are its executable demonstrations. Counted by distinct root cause, the number is smaller than 49; counted by demonstrated manifestation, it is 49. Both are stated deliberately.
- 2Three evidence classes. Architectural findings come from reading the source. Exploit demonstrations are reproduced against running code. Conceptual models (groups G–J) are simulated: they model a failure mode in standalone Python, not against a live LLM.
- 3Simulations are not live-model compromises. The AI-layer transcripts (group C) demonstrate attack construction; the LLM-as-a-vuln and reward-hacking items in particular would need a configured model and observed responses to count as live compromises. They are labelled as scenarios, not as evidence that a specific model was broken.
A. Hand-off issues (8): traced by hand, no separate script
These eight issues live in the orchestration layer itself: how work moves from one agent to the next, how the run ends, and what happens when something goes wrong. None needs an attacker to trigger; each is a gap that any of the later exploits can lean on.
How each issue works8 issues · explained
- 1Message-bus dead code: agents publish status updates to a
MessageBus, but the orchestrator never callsmessages_for(), so nothing is ever delivered. Any coordination that depends on messages silently never happens, and anything written there, real or forged, goes unnoticed. - 2Order-fragile hand-offs: the pipeline only works because the researcher, writer and editor happen to be ticked in that exact order. Reorder the list and the writer drafts from empty facts or the editor reviews a draft that does not exist yet. Correctness is a side effect of list order, not something the system enforces.
- 3REVISE dead-end: the editor can return a
REVISEverdict, but no code handles it. There is no path back to the writer, so a single request for changes stalls the entire run instead of triggering a rewrite. - 4No acknowledgment: when one agent hands work to the next, nothing confirms it was received or understood. A dropped or corrupted hand-off looks identical to a successful one, so failures surface only at the end, if at all.
- 5No failure, retry or escalation: if any agent throws an error or produces empty output, the orchestrator has no retry loop, no fallback and no way to escalate to a human. One transient failure ends the run.
- 6Shallow snapshot aliasing:
snapshot()copies the outer list but not the dictionaries inside it. An agent that edits its "private" snapshot is actually editing shared state, so one agent can rewrite another's inputs without ever calling a write method. - 7No completion handshake: the editor sets
done = Trueon its own and nobody else is told or asked. The run can end while other agents still have work in flight, and nothing checks that the result is actually complete. - 8Single-pass in disguise: the system looks like a multi-agent loop, but in practice each agent acts once and the run is over. There is no real iteration or feedback between agents, which removes the self-correction that multi-agent designs are supposed to provide.
Live, runnable versions of #2, #3, #6, and the no-acknowledgment/no-handshake gaps appear as the coordination group below.
B. System-level exploits (5): offensive_poc.py
Classic software security flaws in the pipeline's plumbing. None of these involve a model; they come from the fact that agents, messages and shared state carry no identity, ownership or integrity checks, so anyone who can touch one part can steer all of it.
How each vector works5 vectors · explained
- 1Message-bus impersonation: any code can publish a message under any agent's name. An attacker posts "APPROVED" or "DONE" as the editor, and nothing can tell it apart from the real thing.
- 2Task-string injection: the task text supplied by the user is pasted straight into facts, drafts and model prompts. Hidden instructions in the task travel downstream and become prompt injection for every later agent.
- 3Shared-environment poisoning: the shared environment has no record of who wrote what. Pre-seeding it with fake facts means the writer faithfully drafts attacker-controlled content, and the editor approves it.
- 4Orchestrator hijack: the orchestrator runs whatever agent objects it is handed, with no allow-list or verification. Slipping in one rogue agent means arbitrary code runs inside the main loop.
- 5Trivial verdict bypass: the editor approves any draft that merely contains the task string. Including that one word is enough to pass review, so the quality gate is effectively decorative.
offensive_poc.py5 vectors · full transcript
C. AI/LLM-specific exploits (8): offensive_ai_poc.py
Attacks that exist only because a language model sits in the loop. A model cannot reliably separate instructions from data, has no built-in notion of trust, and is optimised to produce plausible output rather than verified output. Each vector below turns one of those properties into a weapon, and none of them would apply to ordinary software.
How each vector works8 vectors · explained
- 1Prompt injection: text planted in a "fact" is read by the next model as an instruction. Data becomes a control channel, and the model obeys the attacker instead of its task.
- 2LLM as the vulnerability: even when the surrounding code is perfect, a well-crafted jailbreak can talk the editor model into approving bad content. The gate is only as strong as the model's resistance to manipulation.
- 3Tool-call poisoning: a natural-language task steers the model into calling destructive or expensive tools, such as deleting files or sending email. No code is modified; the model simply chooses the harmful action.
- 4Jailbreak propagation: compromise only the researcher, and its malicious facts poison the writer, whose draft then poisons the editor. One weak link compromises the whole chain because state is shared.
- 5Reward hacking: if the editor is rewarded for approvals and high scores, it learns to approve everything with 5/5. The metric goes up while the actual review quality collapses.
- 6Token exhaustion: stuffing tens of thousands of filler tokens into shared state makes every later model call slow, costly, and eventually fail on context overflow. It is a near-free denial of service.
- 7Model substitution: a leaked API key or a compromised proxy lets an attacker read every prompt or swap in their own responses. The model that judges the whole system can be replaced underneath it.
- 8Hallucinated hand-offs: model output is passed on with no grounding, fact-check or schema validation. Invented facts and fake approvals flow downstream as if they had been verified.
offensive_ai_poc.py8 vectors · full transcript
On the transcript's closing line: "weakest link" overstates what these runs establish. A more defensible claim is that the AI layer adds attack surface the rest of the stack does not have, because natural-language instructions, retrieved content, model outputs and tool decisions all cross trust boundaries without the deterministic guarantees ordinary code provides. Which layer is weakest depends on the deployment: here the unauthenticated-RCE framework is at least as weak.
D. Agent-specific exploits (8): offensive_agent_specific_poc.py
Attacks that target what makes an agent an agent: its private memory, its identity and role, and the decide() loop that chooses its next action. Because agents act on their own beliefs about the world, corrupting those beliefs, or the logic that reads them, changes behaviour without touching any data the user would see.
How each vector works8 vectors · explained
- 1Private-memory poisoning: one injected memory line such as "I already gathered facts" makes the researcher skip its job. The pipeline starves without any visible error.
- 2Identity impersonation: agents are identified only by a name string. An impostor calling itself "writer" can submit drafts that are indistinguishable from the real writer's.
- 3Role-based privilege escalation: nothing stops a low-privilege agent from performing a high-privilege action. The writer can set
done = Trueand close the task, a power meant only for the editor. - 4decide() logic hijack: replacing or patching an agent's
decide()method gives full control over what it does next. Autonomy without integrity checks means whoever controls the decision function controls the agent. - 5Per-agent state confusion: an agent takes a snapshot, the world changes, and the agent then acts on the stale snapshot. This time-of-check to time-of-use gap lets decisions be made against a world that no longer exists.
- 6Memory exhaustion: there is no cap on how much an agent can remember or how often it can act. A driven agent can grow its memory until the host runs out of RAM.
- 7False memory and amnesia: agents mix up shared state with their own memory. Seeding a fake draft makes the writer think it already worked; clearing state makes agents redo or forget work.
- 8Team-state tampering: giving two agents different views of shared state desynchronises them. One thinks facts are missing while another thinks they are ready, and the team deadlocks or produces conflicting output.
offensive_agent_specific_poc.py8 vectors · full transcript
E. Meet-oracle (1): offensive_meet_oracle.py
Membership-query side channel
Code-verifiedThe editor's authorization check is logically correct: it allows an action only if the actor's hidden permission scope covers every tag the action needs. But each answer reveals one bit about that hidden scope. Because the set of possible tags is public and nothing limits how many questions can be asked, an attacker simply asks about every tag, one legitimate query at a time, and reconstructs the victim's entire scope. No request looks abnormal, so conventional monitoring sees nothing.
How each vector works1 vector · explained
- 1Membership-query side channel: the attacker sends eight ordinary authorization requests, one per public tag. Each ALLOWED or DENIED reply says whether that tag is in the victim's scope. After eight queries the full hidden scope is recovered exactly, with zero false positives, using only correct, permitted calls. The fix in section 03 caps how many distinct tags the check will answer truthfully.
offensive_meet_oracle.py1 vector · full transcript
F. Coordination (5): offensive_coordination.py
Turn order, TOCTOU, premature termination
Code-verifiedThese attacks exploit how agents coordinate rather than what any one agent does. Turn order, shared snapshots, the completion flag, the verdict handler and the message bus are all trusted implicitly, and each becomes a lever. All five run live against the real code and are the working versions of the hand-off issues in group A.
How each vector works5 vectors · explained
- 1Turn-order poisoning: the orchestrator accepts a plain list of agents. Putting an attacker-controlled agent first means it writes the facts every later agent consumes, so it shapes the entire run on the very first tick.
- 2Shared-state alias (TOCTOU): because snapshots share their inner objects with the real state, editing a "copy" rewrites the original. An agent can change data that another agent has already checked and is about to trust.
- 3Premature termination: the editor alone decides the task is complete. One approval ends the run with no second check, so an unreviewed or poisoned result ships as final.
- 4REVISE dead-end: a
REVISEverdict has no handler, so the pipeline halts with no retry or escalation. Forcing a single REVISE is a reliable denial of service. - 5Message sinkhole: messages pile up in the bus, including a forged "false DONE" from an attacker, but the orchestrator never reads them. The bus becomes a blind spot where anything can be hidden.
offensive_coordination.py5 vectors · full transcript
G. Semantic-channel (2): offensive_semantic.py
Drift amplification, paraphrase steganography
Conceptual modelEvery agent rewrites what it receives in its own words before passing it on. Each rewrite is a lossy compression shaped by the agent's role: a researcher adds "documented", a writer adds "significant", an editor adds "approved". This model represents meaning as a set of features and shows how the chain of rewrites can distort meaning or carry hidden meaning, with no agent ever being compromised.
How each vector works2 vectors · explained
- 1Semantic drift amplification: a perfectly neutral seed passes through three agents and comes out labelled "approved", "confirmed" and "final", while "safe" and "stable" are lost. No one lied; the distortion is the sum of small, role-driven rewrites.
- 2Paraphrase-invariant steganography: an attacker hides a concept, here "covert", that every agent preserves when paraphrasing. It survives every hand-off unchanged, while the surface text looks harmless, so keyword filters find nothing to block.
offensive_semantic.py2 vectors · full transcript
H. Emergence (4): offensive_emergence.py
Error-correlation, diversity collapse, weight hijack
Conceptual modelMulti-agent systems often combine many agents' answers to get a better one. That only works when their mistakes are independent, because independent errors cancel out when averaged and correlated errors do not. The model uses 25 agents each estimating a true value of 100, then averages them, and shows how attacking the relationship between agents breaks the group without breaking any single agent.
How each vector works4 vectors · explained
- 1Error-correlation poisoning: poisoning the shared environment pushes every agent's error in the same direction. The average moves from 99.92 to 116.63: an error over 200 times larger, with no individual agent compromised.
- 2Diversity collapse: a shared signal makes agents converge on the same answer too early. The healthy spread of opinions shrinks, and with it the ensemble's ability to catch mistakes.
- 3Calibration attack: after poisoning, the group is both more wrong and more confident (0.83 versus 0.76). The system reports high certainty exactly when it should be least trusted.
- 4Credibility-weight hijack: one biased agent is given 60% of the voting weight. The vote is counted correctly, yet the result lands at 118 instead of 100 because the weights themselves were poisoned.
offensive_emergence.py4 vectors · full transcript
I. Causal-inference (4): offensive_causal.py
Spurious correlation, reversed causation
Conceptual modelAgents that learn cause and effect from what they observe ("X keeps happening before Y, so X probably causes Y") can be misled without ever seeing a false event. The attacker only controls the timing and co-occurrence of real, benign events, and the agent builds a wrong model of how the world works, which then drives its future decisions.
How each vector works4 vectors · explained
- 1Spurious-correlation poisoning: forcing two unrelated events, A and C, to happen together makes the agent learn a direct link between them that does not exist.
- 2Temporal-direction reversal: reordering when events are reported makes the effect appear before the cause, so the agent learns causation backwards.
- 3Latent-confounder injection: when a hidden factor Z drives both X and Y, the agent wrongly concludes X causes Y. The attacker exploits this naturally occurring confusion rather than creating it.
- 4Causal-strip mining: quietly removing the middle step of a chain A to B to C makes the agent believe A acts on C directly, a subtle poisoning that is very hard to spot.
offensive_causal.py4 vectors · full transcript
J. Theory-of-mind (4): offensive_theory_of_mind.py
False belief attribution, recursive desync
Conceptual modelAgents that cooperate keep a mental model of each other: what a teammate already knows and what it plans to do. These attacks never touch the real data or the real agents. They only corrupt one agent's beliefs about another, and the resulting misunderstanding is enough to break coordination.
How each vector works4 vectors · explained
- 1False-knowledge attribution: the researcher is led to believe the editor already has the data, so it never sends it. Information stops flowing even though nothing was deleted.
- 2False-intention attribution: the editor is led to believe the writer will finalise the draft itself, so it stops reviewing. Only a belief changed, yet a critical step is skipped.
- 3Recursive-belief amplification: errors in "what A thinks B thinks C knows" can compound with each level of nesting, letting a tiny initial misbelief spread through layered reasoning about others.
- 4Shared-belief desync: two agents hold contradictory views of each other: A trusts B as competent while B thinks A knows nothing. With no common ground, coordination fails by design.
offensive_theory_of_mind.py4 vectors · full transcript
A correct verifier that leaks, and a working patch
Of the ten groups, meet-oracle is the one with the most teeth: it works against correct code, and the fix is small enough to verify end to end. The editor's authorization check is a textbook intersection rule, allow the action if the actor's permission scope covers every tag the action requires:
Nothing is wrong with that rule in isolation. The problem is that the same function answers an unlimited number of single-tag questions, and nothing stops anyone from asking it who's authorized for what. To get this screenshot we temporarily reverted authorize() in the real file back to this vulnerable version, ran it, then restored the fix, so this is the actual file's actual behavior, not a reconstruction:
The fix keeps the intersection rule exactly as-is, but caps how many distinct tags it will ever answer truthfully for a given actor and action, rate-limiting the membership-style queries, with no change to the public API and no distinguishable "blocked" response an attacker could detect:
offensive_meet_oracle.pyafter the fix · full transcript
The two sanity checks pass identically before and after (approve → True, admin → False), and the fix never grants an action the real rule would have refused, it only ever denies more, which is why the three vocabulary tags that happen to be true (editor, public, review) also get wrongly denied once the budget runs out: that's the cost of this specific defense, not a side effect that leaked anything new. It's a correct, narrow, working countermeasure, verified against the real file, before and after.
Why the budget patch is a mitigation, not a cure
The patch closes the specific oracle, but it is best understood as a mitigation experiment, not a production authorization control. Its weaknesses are worth stating plainly:
- 1Mutable default + process-local state: the budget lives in a
_cache={}default argument. Its lifetime is the process, it is not thread-safe, and a restart resets every budget. - 2Distributed bypass: with more than one worker, each process keeps an independent budget, so N workers multiply the number of truthful probes by N.
- 3Budget exhaustion as DoS: an attacker can deliberately spend the two truthful answers before a legitimate check runs, turning the defense into a denial-of-service on real authorization.
- 4Unauthenticated actor: the key is
(actor, action), butactoris an unverified name. An attacker who can name itself freely resets the budget per identity. - 5Stale grants: cached
Trueresults survive a permission revocation, so access can outlive the policy that granted it.
The deeper point is architectural: the function exposes a membership-query interface at all. The durable fix is to stop answering "is tag T in your scope?" and instead authorize complete actions against resources, inside a trusted service that authenticates the principal, logs every decision, and can revoke immediately:
The architectural changes that matter, independent of this code: authenticate the principal separately from its agent name; authorize actions against resources rather than exposing arbitrary permission-tag checks; keep decisions inside a trusted policy service; rate-limit and watch for anomalies at the authenticated-principal level, not per process; and support immediate revocation. The budget patch is kept above because it demonstrates the oracle concretely and is verifiable end to end — but a real deployment should ship the service, not the cache.
49 vectors, 35 verified in running code
| Group | Count | Status |
|---|---|---|
| Hand-off issues | 8 | Verified by tracing |
| System-level exploits | 5 | Code-verified |
| AI/LLM-specific exploits | 8 | Code-verified |
| Agent-specific exploits | 8 | Code-verified |
| Meet-oracle | 1 | Code-verified |
| Coordination | 5 | Code-verified |
| Semantic-channel | 2 | Conceptual model |
| Emergence | 4 | Conceptual model |
| Causal-inference | 4 | Conceptual model |
| Theory-of-mind | 4 | Conceptual model |
Reproducibility
For the claims to be checkable, the conditions behind them have to be pinned down. The code-verified groups ran under:
| Dimension | What to record for a re-run |
|---|---|
| Framework | babyagi functionz at a fixed commit — pin the exact SHA before re-running. |
| Pipeline target | The real_multiagent/ rebuild at a fixed commit. |
| Runtime | Python version, OS, and the installed dependency set (a lockfile is the honest form of this). |
| Preconditions | The attacker position each vector assumes, from the threat-model table in section 00. |
| Impact | Which of confidentiality / integrity / availability the vector affects. |
| Remediation | Whether a fix was written, and whether normal pipeline function still passes after it (regression). |
Only meet-oracle currently carries a tested, before-and-after remediation with a passing functional path; the other groups demonstrate the vector but not yet a regression-tested fix. CVSS-style scoring is deliberately omitted: without a single agreed deployment and threat model, a numeric severity would imply more precision than the evidence supports.
From "secure the agent" to "secure the handoff"
The audit's recurring lesson is that per-component correctness does not compose into a safe system. A defensible rebuild needs explicit boundaries and a few trusted services the agents cannot talk their way around.
Trust zones
Today all three agents share almost everything. Splitting the pipeline into zones, with an enforced contract at every transition, means an agent no longer trusts its input just because of who sent it.
| Zone | Holds | Trust rule |
|---|---|---|
| Untrusted input | User tasks, external documents, retrieved content. | Never an instruction source. |
| Researcher | Evidence with source provenance and a confidence level. | Output carries origin, not authority. |
| Writer | Drafts from constrained input; no approval power. | Validates researcher output; does not assume it. |
| Editor | Independent verification and the approval decision. | Re-checks evidence, does not inherit trust. |
| Trusted output | Validated final artifact, authorized to publish. | Reachable only through a policy gate. |
Integrity on shared state
Recording who wrote a fact is necessary but not sufficient; the record must also be tamper-evident. Each shared-state write should be an authenticated, signed envelope with an immutable, versioned history:
One distinction the design must keep: a valid signature proves origin and integrity, never factual correctness. So provenance ("who created this"), verification ("who checked it"), and truth ("is it actually right") are three separate fields, and the editor's job is the second — it cannot be skipped just because the first is present.
A secure reference architecture
Assembled, the defensive side is eight components the current pipeline lacks entirely:
- 1Identity service: every agent gets a cryptographically verifiable identity; names stop being authority.
- 2Policy enforcement point: every privileged operation goes through the
AuthorizationServicefrom section 04 — action-and-resource decisions, logged and revocable. - 3Message gateway: validates signatures, timestamps, sequence numbers and schemas, which closes impersonation, replay and the sinkhole at once.
- 4Isolated agent runtimes: no shared Python process, no
exec()of stored code, no secrets in a common scope. - 5Immutable event log: every action and state transition recorded append-only, so tampering is detectable after the fact.
- 6Memory isolation: task memory, user memory and agent memory kept separate, so one run cannot contaminate another.
- 7Output validator: evidence, structure and policy compliance checked before a hand-off is accepted — model output treated as untrusted input.
- 8Human approval gate: required before any sensitive external action (tool call, publish, send).
Further vectors worth investigating
These are not counted among the 49 — they are candidates for a production-focused second pass, most relevant once the pipeline leaves a single local process:
| Candidate vector | Why it matters in production |
|---|---|
| Cross-run memory contamination | One user's task influences another user's run through shared memory. |
| Tenant isolation failure | One customer reaches another customer's shared state. |
| Tool permission escalation | An agent invokes tools outside its intended authority. |
| Indirect prompt injection via retrieval | Malicious instructions arrive inside fetched documents or web pages. |
| Replay attacks | Old signed messages are reused to re-trigger actions. |
| Duplicate execution | Repeated hand-offs cause duplicate publishing or transactions. |
The handoff is the attack surface
Most of these forty-nine vectors don't exploit a single agent. They exploit the space between agents: the shared environment nobody owns, the message bus nobody reads, the turn order nobody protects, and the verdict nobody can appeal. Each component can be individually correct while the system as a whole stays trivially breakable.
The meet-oracle result makes the point sharpest. A textbook-correct authorization check still leaked an agent's entire hidden scope, one legitimate query at a time, and the fix had to limit how the check is used rather than change its logic. Multi-agent security has to be designed at the level of interactions, not just components.
For anyone building on a pipeline like this, the priorities are clear — and section 06 turns each into a concrete component:
- 1Sandbox execution: no
exec()of stored code without isolation, and no secrets in shared scope. - 2Authenticate every actor: sign messages and shared-state writes so agents can verify who said what.
- 3Enforce capabilities, not roles: only an agent holding the right capability can mark work done or approve it.
- 4Treat model output as untrusted input: validate, ground and schema-check every handoff before the next agent acts on it.
- 5Monitor the system, not just the parts: rate-limit queries, watch for correlated errors, and require a real completion handshake.
Securing an agent is necessary. Securing the handoffs between agents is what actually keeps the pipeline safe.