Insecure Inter-Agent Communication Detection

How the attack works

An attacker who can inject or intercept traffic between agents sends a message that lacks a valid authentication token, or reuses an old, previously valid message (a replay), or manipulates routing headers to make a message look like it came from a trusted source. Because the receiving agent does not properly verify sender identity or message freshness, it treats the forged or replayed message as a legitimate instruction. This can let the attacker insert commands into a delegation chain or confuse which channel a message is meant for, without needing to craft convincing prompt content — the weakness is in the plumbing, not the wording.

Netzilo detection

Why it matters

An attacker can get one agent to execute commands it never should have trusted, effectively hijacking part of a multi-agent workflow, which can lead to unauthorized actions, data exposure, or further compromise of downstream agents.

What you can do

• →Require authentication (e.g. signed tokens) on every inter-agent message and reject unsigned or unverifiable ones.
• →Add timestamps or nonces to messages and reject anything outside an expected freshness window to block replay.
• →Validate routing/header information at the receiving agent instead of trusting it as provided.
• →Log and alert on communication channels that carry commands without any authentication mechanism, and review debug logging so it doesn't mask these gaps in production.

Known benign look-alikes

• Agent frameworks logging communication debug info during development
• Security audit tools intentionally scanning for communication weaknesses
• Documentation or comments describing inter-agent security architecture
• Test harness messages with intentionally missing auth for unit testing

References

• https://agentthreatrule.org/en/rules/ATR-2026-00076

Related threats