Multi-Agent Security Architecture Guide
When you chain AI agents together, new security problems emerge. Inter-agent authentication, trust boundaries, blast radius limitation, and audit logging for multi-agent SOC systems.
🎯 Multi-Agent Threat Model
📊 Attack Surface by Agent Topology
| Topology | Description | Primary Attack Surfaces | Risk Level |
|---|---|---|---|
| Sequential pipeline | A → B → C — each agent processes and passes to next | Poisoned output from any agent propagates forward. No feedback loop to catch errors. | Medium |
| Orchestrator + sub-agents | Central orchestrator delegates to specialist agents | Orchestrator compromise controls all sub-agents. Sub-agents trusted by orchestrator may be over-privileged. | High |
| Peer-to-peer mesh | Agents communicate directly with each other | Every agent is an attack surface. No central control point. Circular trust loops possible. | Very High |
| Human + agent collaboration | Human in the loop with AI agents handling subtasks | Prompt injection in agent output presented to human. Human may trust agent output uncritically. | Medium |
| Hierarchical with sub-orchestrators | Orchestrator → sub-orchestrators → workers | Trust hierarchy complexity. Privilege escalation through sub-orchestrator manipulation. | High |
🔐 Inter-Agent Authentication
Each agent-to-agent message must be authenticated. Agent B must be able to verify that a message claiming to come from Agent A actually did, and that the message was not modified in transit.
Option 1 — JWT-based agent identity (recommended for most SOC systems)
Option 2 — HMAC message signing (simpler, for internal pipelines)
🏰 Trust Boundaries & Least Privilege
Every agent should have only the permissions it needs for its specific role. A triage agent that can also execute containment actions has unnecessary blast radius. Define a capability set per agent and enforce it at the tool layer.
Agent capability matrix — SOC pipeline example
| Agent Role | Allowed Tools | Forbidden Tools | Can Delegate To |
|---|---|---|---|
| Triage Agent | query_siem, get_alert_details, get_asset_info | ALL write/action tools | Enrichment Agent only |
| Enrichment Agent | virustotal_lookup, whois, shodan, get_threat_intel | ALL write/action tools | None — outputs only |
| Correlation Agent | query_siem, get_historical_alerts, get_user_activity | ALL write/action tools | None — outputs only |
| Response Agent | block_ip, quarantine_host (HITL gated), create_ticket | account_disable, data_delete, cert_in_notify | None |
| Reporting Agent | create_ticket, send_email (draft only), update_wiki | ALL security action tools | None |
| Orchestrator | delegate_to_agent, read_agent_output, manage_workflow | Direct tool execution (delegates only) | All sub-agents |
Enforcing capability boundaries in code
📝 Audit Trail for Multi-Agent Pipelines
Every agent action must be logged with enough context to reconstruct exactly what happened and why. Without structured audit trails, investigating an agent-caused incident is nearly impossible.
Required fields per audit log entry
| Field | Type | Purpose | Example |
|---|---|---|---|
trace_id | UUID | Links all log entries from a single pipeline run | a3f7-4b2c-9e1d |
span_id | UUID | Unique ID for this specific agent action | 7e21-8f3a-1c9b |
parent_span_id | UUID | ID of the action that triggered this one | 3d41-2a5c-8f7e |
agent_id | String | Which agent took the action | triage-agent-v1 |
tool_called | String | What tool was invoked | query_siem |
tool_args | JSON | Parameters passed to the tool | {"query": "EventID=4625..."} |
tool_result_hash | SHA256 | Hash of result (not raw result — may be sensitive) | 3f2a9b... |
model_reasoning | String | Why the agent decided to call this tool | "Checking failed logons for..." |
confidence | Float | Model's self-reported confidence | 0.87 |
hitl_required | Bool | Was human approval required for this action | true |
approved_by | String | Analyst who approved (if HITL) | analyst@org.com |
timestamp_utc | ISO8601 | When the action occurred | 2025-07-15T09:32:11Z |