Message forgery requires knowing the message format used by the pipeline. In many current implementations this is trivial — inter-agent messages are plain JSON or natural language text with no cryptographic binding to the sender. An attacker who observes a few legitimate messages learns the schema, then constructs a fake one.

What makes this easy in practice: Agent orchestration frameworks often use simple message formats like {"role": "orchestrator", "content": "deploy to production"}. The role field is just a string — any party that can write to the channel can set it to "orchestrator." There is no signed token, no certificate, no proof that the claimed role is genuine.

The agent's perspective: A forged message looks identical to a legitimate one. The agent has no mechanism to distinguish them. It acts on the content because the content arrived through a channel it trusts — the channel, not the sender, is what the agent is actually trusting.

Tampering differs from forgery: the attacker doesn't create a new message — they intercept a real one and modify it before forwarding it to the intended recipient. The message has genuine origin (it was really sent by the claimed sender) but compromised content.

Why integrity checks are separate from authentication: A message can be authenticated (the sender is verified) but not integrity-protected (the content can be changed between sender and receiver). Without a message authentication code (MAC) or digital signature covering the message body, an intermediary — any hop between agents — can modify content undetected.

Real example pattern: In 2024, security researchers demonstrated that MCP (Model Context Protocol) tool responses — returned by tool servers to an orchestrating LLM — could be tampered with in transit when the channel lacked TLS or integrity checking, causing the LLM to act on falsified tool outputs.