Slide 11 of 28
Part 2 — Vulnerability TypesSlide 11
Slide 11 · Types 3 & 4
Type 3: Claiming the orchestrator's identity to command the fleet. Type 4: Replaying a valid past message at the wrong time.
Type 3 — Orchestrator impersonation

The orchestrator is the most privileged agent in a pipeline. It directs sub-agents, delegates tasks, and defines scope. An attacker who can successfully impersonate the orchestrator inherits this authority over every downstream agent that trusts orchestrator messages.

Why orchestrator impersonation is particularly dangerous: Sub-agents are often designed to be obedient to the orchestrator — their system prompts instruct them to execute tasks assigned by the orchestrator without independently verifying whether those tasks are within scope. This is a deliberate design choice for efficiency. It becomes a vulnerability when the "orchestrator" sending instructions isn't the real one.

How it happens in practice: In agent frameworks that use role-based message channels (a common pattern), the orchestrator role is identified by a field in the message, not by cryptographic proof. Any component that can write to the orchestrator channel — including a compromised logging sidecar, a malicious plugin, or an insider with queue access — can issue instructions with orchestrator authority.

Google A2A and Anthropic MCP context: Both protocols include agent identity mechanisms, but the security properties depend heavily on implementation. An orchestrator "identity" that is just a claimed string in the message body — without a verifiable cryptographic credential — provides no real protection against impersonation.

Type 4 — Replay attacks

A replay attack re-sends a previously legitimate message that was valid at the time it was sent. The classic example: an "approve transaction" message from last week is re-sent today. If the receiving agent has no replay protection, it cannot distinguish the replayed message from a fresh approval.

What replay protection requires: Every message must carry a unique identifier (nonce) or a timestamp with a narrow validity window. The receiving agent tracks seen nonces or checks timestamps and rejects messages that have already been processed or that fall outside the validity window. Without this, captured messages become reusable attack tokens.

← Back Types 5 & 6 →