Memory poisoning, multi-agent risk, and supply chain

Everything so far assumed a single agent in a single session. Persistence and multiplicity each add a category of risk.

Memory poisoning (ASI06) is injection that outlives the conversation. If an agent writes to durable or semantic memory, an attacker who influences one session can plant content that is retrieved and acted on later: in a different session, possibly for a different user.

• The payload is retrieved as trusted context, because the agent wrote it itself.
• Vector stores are a particular risk: poisoned documents are surfaced by relevance, so a well-crafted entry gets retrieved often.
• The gap between writing and triggering can be arbitrarily long, which defeats session-scoped monitoring.

Inter-agent communication (ASI07) adds spoofing and tampering. When agent A accepts a task from agent B, several questions need real answers: is B who it claims to be, is B authorized to ask, and does B's output enter A's context as data or as instruction?

• Authenticate agents to each other: identity, not just a network path.
• Authorize delegation explicitly, and have a human define it rather than letting agents arrange it between themselves.
• Bound the depth, so A delegating to B delegating to C cannot recurse indefinitely.
• Treat another agent's output as untrusted content, because it may be carrying an injection from its own inputs.

Cascading failure (ASI08) is what makes multi-agent systems hard to debug: a small error early in a chain is amplified by every downstream step that treats it as established fact.

Supply chain (ASI04) is the last piece. An agent's tools are its attack surface. An MCP server, a plugin, or a package can be malicious from the start or become malicious in an update.