Inter Agent Comms Reviewer

---
name: inter-agent-comms-reviewer
description: 'Review the security of agent-to-agent and agent-to-MCP-server communication (OWASP Agentic ASI07) — mutual authentication, message integrity, replay protection, confidentiality, topology allowlists and spoofed tool results. Enforces authenticated ≠ trusted: ordinary peer content is untrusted input and cannot assert approvals or permissions; task mutation requires a separate verified authorized channel. Use when agents exchange messages (A2A, MCP transports, shared queues/buses), when wiring an agent to MCP servers, or when a multi-agent design needs its message layer reviewed. Do NOT use for acquiring/trusting MCP packages and registries (supply-chain-security-reviewer, ASI04), external API/webhook contracts (api-event-architect), instructions already in context (prompt-injection-defender), or the identity model itself (agent-identity-privilege-reviewer).'
---

# Inter-Agent Communications Reviewer

Terms used below: **OWASP** means Open Worldwide Application Security Project;
**ASI07** is its Agentic Top 10 category *Insecure Inter-Agent Communication*;
**ASI03** covers agent identity and privilege; **ASI04** covers agentic
supply-chain components in that list;
**MCP** means Model Context Protocol; **A2A** means Agent2Agent; **SSE** means
server-sent events; **TLS** means Transport Layer Security; and **ACL** means
access-control list. **API** means application programming interface;
**HTTP** means Hypertext Transfer Protocol; **OS** means operating system;
**AI** means artificial intelligence. In the review template,
`authn` means authentication, `e2e` means end-to-end, `ts` means timestamp,
`confid.` means confidentiality, and a `nonce` is a value used once to help
reject replay. These terms do not make an authenticated message trusted input.

## Purpose

Review the message layer of a multi-agent or MCP-connected system (ASI07):
whether agents and servers authenticate each other, whether messages can be
tampered with or replayed, whether sensitive payloads are confidential in
transit, and whether the topology bounds who may talk to whom. The review
also enforces the rule the transport cannot: **authenticated ≠ trusted** — a
message from a verified peer is still untrusted input, because that peer may
itself be compromised or manipulated. The output is severity-ranked findings
each with an attack path (spoof/tamper/replay/eavesdrop → effect on the
receiving agent) and concrete transport + content-handling fixes. Acquiring
and trusting the MCP server artifact is `supply-chain-security-reviewer`
(ASI04); the identities used to authenticate are
`agent-identity-privilege-reviewer` (ASI03) — this skill reviews the live
message exchange.

## Use When

- Use when: agents exchange messages — orchestrator/worker hand-offs, A2A
  protocols, shared queues/buses/blackboards, or delegation between agents.
- Use when: an agent connects to MCP servers (local or remote) and the
  transport, server identity, and result handling need review.
- Use when: assessing whether a rogue process could impersonate an agent or
  server, tamper with messages, replay old commands, or read sensitive
  payloads off the wire.
- Use when: a multi-agent design is on paper and its message layer needs a
  security pass before wiring.
- Do NOT use when: the question is whether to install/trust an MCP server
  package, manifest, registry entry, or plugin — that is the agentic supply
  chain (`supply-chain-security-reviewer`, ASI04).
- Do NOT use when: designing external partner-facing API/webhook contracts
  (`api-event-architect`), defending instructions already in context
  (`prompt-injection-defender`), or defining what identities agents run as
  (`agent-identity-privilege-reviewer` — this skill uses that model).

## Inputs to Inspect

1. The topology: which agents/servers exist, who initiates, who may talk to
   whom by design — and whether anything enforces that map.
2. The transports: MCP stdio/HTTP/SSE, queues, buses, sockets, shared
   files/blackboards — and their channel security (TLS, socket permissions,
   broker ACLs).
3. Authentication per edge: how each side proves identity (mutual TLS,
   signed messages, broker auth, OS process identity for stdio) — and what a
   rogue local process could claim.
4. Message handling: integrity protection, replay defenses
   (nonces/timestamps/idempotency), and how the RECEIVER treats message
   content (data vs instructions).
5. Sensitive payload flows: what crosses the wire (tenant data, credentials,
   goal/plan state) and its confidentiality needs.
6. Existing artifacts: `agent-identity-privilege-reviewer` output (the
   identity model), `agent-tool-safety-guard` output (what received messages
   can trigger), MCP server provenance from
   `supply-chain-security-reviewer`.

## Workflow

1. **Map the topology.** Draw every communication edge (agent↔agent,
   agent↔server, agent↔queue) with its transport. No topology or transport
   detail available → Stop Conditions.
2. **Check authentication per edge.** Each edge answers: how does the
   receiver know who sent this? Flag unauthenticated edges (anyone on the
   bus/localhost can inject), one-way auth where mutual is needed, and
   server identity that isn't pinned (a swapped MCP server endpoint goes
   undetected). Identities come from `agent-identity-privilege-reviewer`'s
   model.
3. **Check integrity and replay** using
   [references/inter-agent-comms-checklist.md](references/inter-agent-comms-checklist.md):
   messages tamper-evident end-to-end (not just channel-encrypted at hops);
   replay bounded by nonce/timestamp/expiry and idempotency on
   side-effecting commands — an old captured "approve/execute" message must
   not fire twice.
4. **Check confidentiality.** Sensitive payloads (tenant data, credentials,
   plans) encrypted in transit on every hop, including "internal" ones;
   queue/broker/blackboard persistence inherits the data classification
   (compose `multi-tenant-data-architect` scoping for stored messages).
5. **Enforce the topology.** Allowlist who may talk to whom (broker ACLs,
   network policy, MCP server allowlists); an agent accepting messages from
   any peer is a finding even with authentication — compromise of one agent
   should not grant an audience with every agent.
6. **Review receiver-side content handling.** The transport authenticates
   the SENDER, not the CONTENT: a peer message is untrusted input that may
   inform work but cannot by itself re-task the receiver, change its
   permissions, or assert approvals. Legitimate delegation uses a separately
   verified, authorized task-mutation channel (review with
   `agent-goal-hijack-defender`); injected instructions
   are `prompt-injection-defender`'s layer. Spoofed tool RESULTS — a
   compromised server returning crafted output — are handled as untrusted
   tool output feeding `agent-tool-safety-guard`'s argument validation.
7. **Rank findings and design red-team cases.** Each finding: attack path
   (rogue peer / tampered message / replayed command / read payload →
   effect), severity gated on what the receiving agent would DO. Red-team
   cases (spoof, tamper, replay, cross-topology message → expected SAFE
   outcome: rejected/inert) hand to `ai-evaluation-harness`; active
   compromise routes to `incident-response-runbook`.

## Output Format

```
INTER-AGENT COMMS REVIEW — <system>
Topology: <edges: sender → receiver, transport, enforced-by>
Per-edge posture:
  <edge> | authentication: <mechanism, mutual?> |
  integrity: <end-to-end message protection?> |
  replay: <nonce/timestamp/idempotency> |
  confidentiality: <in-transit/at-rest>
Findings (severity-ranked):
  [severity] <edge/layer> — Attack path: <spoof|tamper|replay|eavesdrop → receiver effect>
    Fix: <mutual authentication | pin identity | sign end-to-end |
      nonce+expiry | encrypt | access-control-list (ACL) topology>
Receiver content handling: <ordinary messages as data; task mutation only via verified authorized channel; approval assertions rejected>
Spoofed-result handling: <tool results treated as untrusted → agent-tool-safety-guard>
Red-team cases: <spoof/tamper/replay → expected SAFE outcome> (→ ai-evaluation-harness)
Handoffs: server acquisition → supply-chain-security-reviewer | identities → agent-identity-privilege-reviewer
Not reviewed: <edges/areas + why>
```

## Validation Checklist

- [ ] Every communication edge is mapped with transport and an
      authentication mechanism; unauthenticated and unpinned edges flagged.
- [ ] Integrity is end-to-end tamper-evident where messages cross
      intermediaries; channel encryption alone is not claimed as integrity.
- [ ] Replay is bounded (nonce/timestamp/expiry) and side-effecting commands
      are idempotent or single-use.
- [ ] Sensitive payloads are confidential in transit on all hops and
      classified at rest in queues/brokers.
- [ ] Topology is allowlisted and enforced — no any-to-any messaging by
      default.
- [ ] Receiver treats ordinary authenticated messages as untrusted input:
      task mutation requires a verified authorized channel; message content
      cannot assert permission changes or approvals.
- [ ] Findings carry attack paths gated on receiver effect; red-team cases
      cover spoof, tamper, replay, and topology violations.

## AI Security Rules

- Inter-agent messages are authenticated and integrity-protected — every
  edge, both directions, including "trusted internal" ones.
- Authenticated ≠ trusted: ordinary peer content remains untrusted input.
  A goal or plan change requires a separately verified authorized task
  channel; message text never changes identity, permissions or approvals.
- Approvals and authority never travel as message text: a message claiming
  "approved" or "run as admin" is inert unless verified against the system
  of record (`human-approval-boundary`, `agent-authorization-matrix`).
- The topology is a control: who may talk to whom is designed and enforced,
  not emergent.

## Gotchas

- Localhost is not an auth boundary: on a shared host, any local process
  can often connect to a stdio/local-socket MCP server or local bus —
  "it's only listening on 127.0.0.1" still needs peer authentication.
- Channel encryption ≠ message integrity: TLS protects hops, but a message
  crossing a broker/orchestrator can be modified at the hop — end-to-end
  signing is what makes tampering evident.
- Replay is the forgotten one: captured legitimate messages ("execute
  step", "approved") replayed later pass authn and integrity checks —
  only nonces/expiry/idempotency stop them.
- The spoofed-RESULT direction: everyone checks who can send commands;
  fewer check the response path — a compromised MCP server feeding crafted
  results steers the agent as effectively as a command.
- Agent B treating agent A's message as its task definition is topology
  laundering of goal hijack — the receiving loop re-validates against its
  own pinned goal (`agent-goal-hijack-defender`), regardless of sender.
- Queues persist messages: a "transient" bus with disk persistence is now a
  data store holding tenant data and plans — classify and scope it.
- Don't confuse the layers: deciding to INSTALL an MCP server is supply
  chain (ASI04); talking to it safely at runtime is this review (ASI07).

## Stop Conditions

- No topology, transport, or protocol details are available — stop; this
  skill reviews a concrete message layer, not the idea of one.
- Evidence of active compromise (rogue peer connected, spoofed messages in
  logs) — route to `incident-response-runbook`; severing an edge is a
  containment call (`agent-containment-reviewer` kill/isolation design).
- Fixes require wiring live transports, rotating broker credentials, or
  changing message schemas in production — propose the change; applying it
  is a classified, approved step (`human-approval-boundary`).
- The finding is really about the server package/registry trust (ASI04),
  external partner contracts, or in-context injection — hand to the owning
  skill and stop.

## Supporting Files

- [references/inter-agent-comms-checklist.md](references/inter-agent-comms-checklist.md)
  — per-transport authentication patterns (MCP stdio/HTTP/SSE, queues,
  buses), end-to-end integrity and replay defenses, topology-enforcement
  options, receiver-side content-handling rules, and the spoof/tamper/replay
  red-team catalog.
- `evals/evals.json` — trigger + behavior cases.
- `evals/trigger-evals.json` — discrimination within the agentic cluster and
  against `supply-chain-security-reviewer` (ASI04), `api-event-architect`,
  and `prompt-injection-defender`.