// Field note
Your Multi-Agent Graph Has No Boundaries
Your Multi-Agent Graph Has No Boundaries
The scariest thing about multi-agent systems isn't any single agent. It's that most deployments are one flat graph — every agent can reach every other agent's memory, tools, and credentials. Compromise one node, and you've compromised the whole system.
Why this matters now
The research keeps pointing at the same conclusion: agents are being compromised, and the damage spreads through the graph. Tenet's June 2026 analysis of agentjacking — MCP injection that hijacks coding agents — reported 85% exploitation success across Claude Code, Cursor, and Codex CLI. MITRE's audit of 2,890+ agent skills found 41.7% contained serious vulnerabilities. And the confused-deputy problem is structural: an agent with broad credentials doesn't need to be "hacked" — it just needs to be tricked into using the access it already has.
The uncomfortable part: most of these failures are preventable with boundaries. Not better models — boundaries.
The four boundaries
A multi-agent deployment needs four distinct boundaries. Each one answers a different question, and each one is checkable.
1. Trust boundaries — can one agent act as another?
Every agent should be its own trust domain: its own identity, its own credentials, its own network path. If agent A can reach agent B's memory, tools, or credentials, then a prompt injection in A is a prompt injection in B. The test: compromise one node in a red-team exercise and measure how far it can actually reach. If the answer is "everything," you don't have a multi-agent system — you have one system with extra steps.
2. Shared-state isolation — can poisoned context spread?
Shared memory is the classic cross-agent attack channel. One agent writes a poisoned summary, every agent that reads it inherits the compromise. The fix is provenance: tag every write with its source agent and trust level, partition stores by trust domain, and re-validate anything read from a shared store before it can trigger a privileged action. If agents must share state, make the sharing explicit, audited, and read-only where possible.
3. Capability scoping — does each agent hold only what it needs?
The tool list is the attack surface. An agent that can read and write anything is a finding, not a feature. Scope tools per agent, scope permissions per tool (read-only vs. write), and scope data access per role. You should be able to enumerate, for any agent in the graph, exactly which tools and data it can reach — and that capability map should be documented and current, not reconstructed from memory after an incident.
4. Blast-radius containment — what happens when one agent falls?
Assume one agent will be compromised. The question is what happens next. No single agent should hold credentials that unlock the graph's most sensitive systems. No agent should have a path to the full dataset. And the graph should roll back to a known-good state — configs, memory, permissions — without a rebuild. Containment isn't a design goal you hope for; it's a property you test.
The five-minute check
Run through these five questions on your current deployment:
- Can any agent reach another agent's memory or credentials? If yes, that's your first finding — it's the difference between one compromised agent and a graph-wide compromise.
- Is shared state tagged with provenance? If a poisoned entry appears, can you trace it to its writer and roll it back?
- Does any agent hold a blanket auto-approve or always-allow? That's a standing permission that removes the human gate for every tool call.
- Is the capability map documented? Can you enumerate, right now, what each agent can reach?
- Have you tested the containment? A red-team exercise that compromises one node and measures the reach is the only way to know the boundaries actually hold.
Score your deployment against all four boundaries with the Agent Boundary Assessment — 16 questions, in your browser, nothing uploaded. It gives you a per-section score and a written recommendation for each boundary that isn't yet solid.
The pattern
Boundaries are the cheapest security control in agentic AI — they're architecture, not tooling. You don't need a new product to enforce them; you need to stop treating the graph as one trust domain. Compromise one node, and the question is whether that's an incident or a catastrophe. The answer is decided by the boundaries you drew before it happened.