A Security Review Template for Multi-Agent Systems

The OWASP Agentic Security Initiative catalogs the highest-impact failure modes for autonomous systems, and inter-agent trust sits inside several of them: goal hijack, tool misuse, identity and privilege abuse, and insecure inter-agent communication (the OWASP Agentic Security Initiative). The FINOS AI governance framework names the underlying mechanism directly. Multi-agent trust boundary violations occur when a compromise in one agent propagates through shared resources, communication channels, or corrupted state, and the framework lists the propagation patterns: horizontal spread between peers, vertical escalation from low-privilege to high-privilege agents, hub-and-spoke attacks on the orchestrator, and chain reaction compromises (the FINOS risk entry on multi-agent trust boundary violations).

For the review, write one trust boundary record per edge. It needs five fields:

1. Direction and authentication. Who calls whom, and how the callee verifies the caller. A shared API key across agents is a finding, not a configuration.
2. Credential scope. What token the callee receives and what it is restricted to. Credentials minted per delegation should be limited to the subtask, expire at completion, and never copy the orchestrator's full session permissions into the recipient (NHI Mgmt Group's analysis of inter-agent trust).
3. Content trust level. Whether the caller's message is treated as instructions, data, or both. Natural-language input from another agent is still untrusted input and should pass through the same prompt-injection defenses applied to user text (the OWASP guide to securing agentic applications).
4. Authorization decision point. Where the allow-or-deny check happens, and whether it runs per task or per session.
5. Provenance logging. Delegating agent, receiving agent, scoped credential, correlation ID, and verification state, so an investigator can reconstruct why a downstream action was trusted.

The hardest of these to get right is authorization at each hop, because most agent communication standards deliberately leave it out. The A2A protocol, which became a stable open standard for agent discovery and coordination, omits built-in authorization, and deployments that rely on broad OAuth scopes risk downstream data leaks and agent impersonation, since a wide token cannot constrain an autonomous sub-agent that recursively routes data through several services (Authzed's guide to agent-to-agent communication). The review should therefore treat every hop as needing its own decision, evaluated per task and per document rather than at the network edge.

Least privilege alone does not close this. An agent can stay entirely inside its authorized permission set and still behave in ways inconsistent with its declared purpose, which is the gap the "least agency" framing targets: scope what agents do, in what sequence, under what conditions, and with what oversight, not just what they can reach (Zenity on least privilege versus least agency). The concrete lever for multi-agent systems is a decision budget per delegation chain, so autonomy does not compound silently as tasks pass from planner to executor to reviewer.

Inter-agent communication is usually the least visible and least protected surface in a multi-agent system, because a sub-agent's output is consumed by the orchestrator without the scrutiny applied to a human's input (DeepTeam's agentic red teaming guide). The review fix is unglamorous: give every edge a schema and enforce it.

A schema that is actually useful at a trust boundary has four parts:

{
  "sender": "planner-agent",
  "recipient": "executor-agent",
  "task_id": "3f9c...",
  "intent": "issue_refund",
  "params": {
    "account_id": "string, must match ^AC-[0-9]{6}$",
    "amount_usd": "number, > 0, <= 500",
    "reason_code": "enum: duplicate_charge | service_outage | goodwill"
  },
  "provenance": {
    "originating_user": "u-8812",
    "delegation_chain": ["orchestrator", "planner-agent", "executor-agent"],
    "credential_scope": "refund:create:max500"
  },
  "content_trust": "data_only"
}

Three properties matter more than the exact fields. First, free-form natural language belongs in a designated field, clearly marked as data, never in the field the callee interprets as an instruction. Second, numeric and enumerated parameters carry ranges and allowed values in the schema, so a manipulated amount or an invented reason code is rejected at the boundary rather than at the payment API. Third, content_trust and delegation_chain travel with the message so the callee can check who actually asked, not just who forwarded.

The schema then becomes the test oracle. For each edge, run adversarial payloads through the caller and assert that the callee rejects anything off-schema, that instructions embedded in data fields do not change behavior, and that the provenance chain recorded in logs matches the one in the message. This connects directly to red teaming guidance: enumerate every tool and every delegation path to define blast radius, then test inter-agent communication specifically when the agent delegates to sub-agents (DeepTeam). Automated tooling can help run those probes at scale and report attack success rates per boundary, similar to how Foundry's red teaming agent scores attack-response pairs and produces a report across risk categories (Microsoft Foundry's AI Red Teaming Agent documentation).

The question that separates a multi-agent review from a single-agent one is not "what if this agent is compromised" but "what does the next agent do with a poisoned answer." FINOS lists cascade failure propagation as a first-class mechanism: failures in one agent cause cascading failures in dependent agents, potentially taking down an entire business process chain (FINOS).

Document two scenarios per edge and one blast-radius entry:

• Callee fails open or times out. Does the caller retry, escalate, or proceed with partial data? Proceeding with a default value on a high-impact action is a finding.
• Callee returns malicious or corrupted content. Does the caller treat it as data, and does it get re-injected into a prompt or shared memory? Contaminated memory is worse than a bad response, because every later run reads it.
• Blast radius of a compromised agent. List every tool, dataset, credential, and downstream agent reachable from that node, then state the worst plausible outcome in business terms, for example "can issue refunds up to the schema cap for arbitrary accounts."

Failure propagation maps well onto known unsafe behaviors. Goal hijack, where an agent quietly starts working for someone else after consuming a document or another agent's message, is the canonical cascade trigger; mitigations include treating all natural-language inputs including other agents' messages as untrusted, human approval for goal-changing actions, and alerting on sudden changes in tool-use patterns (Idan Habler's field guide to the OWASP agentic Top 10).

A practical priority score for edges: impact (1 to 5) multiplied by reachability (1 to 3, where 3 means the callee can cause an irreversible external effect) multiplied by verification weakness (1 to 3, where 3 means no per-hop authorization). An edge that scores at or near the top of that scale deserves a control before the system ships, not a note in the backlog.

This is the section most teams get wrong, because prompt edits feel like copy changes. They are not. An agent's behavior is part of every caller's attack surface, so a prompt change to a callee invalidates review results for the callee and for every caller that consumes its output. Agent behavior can also change after model updates or new tool additions, which is why red teaming has to be continuous rather than a one-time event (Fiddler's guide to AI agent red teaming).

Treat the following as review triggers for the changed agent and its immediate callers:

Review does not have to mean a full re-run every time. A defensible rule: any change to prompt, tools, model, or data access triggers the full edge review for that agent plus a regression suite of the recorded adversarial payloads for every inbound edge. Cosmetic changes trigger only schema conformance tests. The regression suite is the part that saves time later, which is why it pays to capture adversarial test cases as versioned artifacts from day one, the way red teaming programs keep rules of engagement and reusable templates (the AI Red Teaming Guide's templates).

Two operational habits make this sustainable. Version prompts like code, with the version pinned in the agent register and referenced in logs. And require a review record for every version bump, signed by the agent's named owner, since each agent should carry a unique identity and a named human owner rather than a shared service account (monday.com's AI agent security guide).

Prompt injection testing belongs inside this loop rather than beside it. Pre-launch checklists for injection testing already ask teams to test both direct and indirect patterns, including payloads hidden in retrieved documents and committed code, and to retest after defenses change (QAwerk's prompt injection testing checklist). Extending that checklist to inter-agent edges is mostly a matter of adding the sender as a payload channel. The OWASP prompt injection prevention cheat sheet is a useful reference for the payload categories themselves, covering direct, indirect, encoded and obfuscated, and markup-based attacks (the OWASP LLM Prompt Injection Prevention Cheat Sheet).

If your team is assembling this across several model providers and agent frameworks, the review is easier to run when every model behind those agents is reachable through one credential and one billing pool; Quanta Inference exposes text, image, video, audio and embedding models through a single OpenAI-compatible API, which keeps the agent register and the spend attribution in one place.

The deliverable is a document, not a conversation. One record per edge, each containing: the inventory entry for both agents, the trust boundary decisions, the message schema with its validation rules, the authorization decision point and credential lifetime, the two failure scenarios, the blast radius statement, the priority score, the adversarial test cases with their current pass state, and the prompt and model versions reviewed.

Then set the gate. A system ships when every edge above the priority threshold has a scored adversarial test that passes and a per-hop authorization check that has been exercised. Edges below the threshold are logged with an owner and a review date. This keeps the review proportionate: a ten-agent system with thirty edges does not need thirty deep reviews, it needs a defensible ranking and evidence that the highest-risk paths were tested.

For teams that want a second set of eyes on the trust boundary design before the next agent ships, a free 30-minute discovery call with Quanta Intelligence's consultants is a reasonable next step: bring the call graph and the capability matrix, and the conversation can go straight to the edges that score highest.