Microsegmentation · Principles

Why it matters for agentic AI

Microsegmentation is the network-security answer to a perimeter that has already failed: divide the interior into fine-grained, independently-authorised zones so that a compromise in one zone cannot reach the others. It is the spatial complement to Zero Trust, which handles the per-request authorisation check, and to Least Privilege, which handles the scope of what each credential can do. East-west traffic (lateral movement between components inside the perimeter) is controlled as tightly as north-south traffic at the edge. In NIST SP 800-207 this is a core Zero Trust tenet; in Saltzer and Schroeder’s vocabulary it is separation of privilege applied to the system as a whole.

For agents, the perimeter is long gone. The inside of an agent system is a mesh of orchestrators, sub-agents, tool servers, memory stores, and data pipelines, and every component is a potential point of injection or compromise. Microsegmentation for agents means controlling movement across five distinct planes simultaneously. Memory requires isolated namespaces per user, per task, and per trust level. A compromised agent must not be able to read or write another agent’s memory. Tools require capability tiers: a read-only research agent should be structurally incapable of calling a write tool, not merely instructed not to. Inter-agent communication requires an explicit, signed topology: if two agents have no declared reason to communicate, they have no route. Data domains such as PII, financial records, and intellectual property should live in separate stores with separate access controls, not in a single undifferentiated knowledge base. And execution requires one sandbox per instance, so a container escape or memory corruption in one agent cannot affect its peers.

The multi-agent case produces a failure mode with no classical analogue: fleet-wide behavioural drift from a single poisoned document. If ten agents share a vector store, and one agent retrieves a poisoned document that writes a persistent instruction back into that store, the instruction is now available to all ten agents. What started as a single point of compromise has become a fleet-wide instruction. Namespace isolation contains the blast radius: the poisoned write lands in the originating agent’s namespace and propagates no further.

The east-west problem is also about credential paths. In a dense multi-agent topology, the natural engineering shortcut is to give sub-agents the orchestrator’s credentials “so they can complete the task.” Each time that shortcut is taken, a new east-west path is opened: a compromise of any sub-agent is now a compromise of the orchestrator’s full privilege. Signed inter-agent messaging with per-hop token exchange (each hop receiving only the scope it needs, not the scope the calling agent holds) breaks the lateral credential path while preserving task functionality.

Scenario: the shared vector store infection

Ten agents in a customer support platform share a single vector store for product knowledge. One agent processes a support ticket containing a prompt injection that writes a poisoned document to the shared store using the agent’s write permission. In subsequent retrievals by the other nine agents, the poisoned document surfaces and alters their behaviour across unrelated customer interactions. Per-tenant namespaces (write access scoped to each agent’s own namespace, with read access only to the curated product-knowledge partition) contain the injection to one agent’s namespace. The other nine agents never retrieve it.

Scenario: the lateral credential path

A fintech orchestrator coordinates ten specialist agents: a payments agent, a fraud agent, a reporting agent, and so on. For convenience, all sub-agents are initialised with the orchestrator’s service account credential. A prompt injection in a low-privilege reporting task succeeds, and the attacker now holds the orchestrator credential, giving access to money-movement operations the reporting agent never needed. With per-agent capability tokens scoped to each agent’s declared function, a successful compromise of the reporting agent yields only reporting-scoped access: there is no lateral path to the payments agent’s capability tier.

How it fails

Agents share a RAG index or memory store without namespace isolation, so one poisoned write becomes visible fleet-wide.
Sub-agents are initialised with the orchestrator’s credential rather than a narrow per-task token, so any sub-agent compromise yields the orchestrator’s full scope.
No east-west policy governs inter-agent messaging: any agent can send instructions to any other, and rogue agents can impersonate legitimate ones.
Multiple agents run in the same container or execution environment; a container-level exploit affects all tenants simultaneously.
Data domains (PII, financial, IP) live in a single store; a breach of one category is a breach of all.

Why the mapped controls work

A memory access controller with namespace tokens makes the namespace boundary cryptographically enforced rather than a convention. A write to another agent’s namespace fails with an authorisation error, not a soft guideline. Container-per-instance (using hardened runtimes such as gVisor or Kata Containers) with an egress allow-list means the execution boundary is enforced by the kernel, not the application: a compromised agent literally cannot reach its neighbour’s memory or network endpoints. Capability tiers at the tool gateway implement the tool-plane boundary: a read-only agent’s token is structurally refused by write-tier endpoints, with no model instruction needed. A signed inter-agent communication topology on the message bus makes the allowed-communication graph an auditable artefact: undeclared message paths are rejected at the bus before the receiving agent ever processes them, closing the impersonation and lateral-instruction paths simultaneously.

First steps

Map your current inter-agent communication topology today: draw every agent node, every tool server, and every memory store, then draw an arrow for each permitted message path. Any arrow that is not explicitly documented is an implicit trust grant that needs to either be formalised or removed.
Create separate namespaces (collections, indices, or schema prefixes) in your vector or memory store for each trust tier. Configure write credentials so that an agent processing external input holds only a key scoped to the env namespace and has no write path to the system or operator namespaces.
Switch sub-agent initialisation from “pass the orchestrator’s credential” to per-hop token exchange. Using OAuth 2.0 token exchange (RFC 8693) or your agent framework’s delegation mechanism, mint a scoped token for each sub-agent that carries only the permissions required for its declared subtask.

Threats it governs

When this principle is absent, these threats become reachable.

T1
Memory Poisoning Adversarial content written into short- or long-term memory contaminates future decisions.
T12
Agent Communication Poisoning Inter-agent messages tampered with. The output of one becomes injection input of another.
T13
Rogue Agents in Multi-Agent Systems A malicious or compromised agent inside the system exploits trust to act unobserved.
T31
Insufficient Isolation Between Agent Actions Lack of isolation lets one vulnerability cascade across multiple agent actions.
T42
Cross-Client Interference via Shared Server Shared MCP server state leaks across client sessions, causing unintended cross-tenant interference.

Controls that advance it

Catalogue mitigations that strengthen this principle, grouped by the defence-in-depth stage they sit in.

Prevent

Cross-client isolation A shared MCP server that accepts connections from multiple clients is a concentration point where one client's session state, credentials, and resource budget are physically co-located with every other client's. Without enforced isolation, a malicious or compromised client can read another session's cached credentials, consume shared resources to the point of denying service to other clients, or exploit aggregate server permissions that exceed its own declared scope. Cross-client isolation is the set of structural controls that close those paths: per-session state scoping, per-client permission evaluation, and per-client resource quotas enforced at the server layer.
Session isolation An agent that serves multiple users stores conversation history, retrieved facts, and intermediate state in a memory layer. If that layer is not scoped to the originating session, one user's writes can reach another user's retrieval path. Session-scoped memory isolation prevents that by enforcing a hard boundary at the storage layer, so each session can only read and write its own state.
Shared-memory ACL When multiple agents share a single vector store, the access boundaries between them are not enforced by the store itself unless you configure them explicitly. Without per-namespace write and retrieval controls, an agent that can write to the shared corpus can insert crafted vectors into any namespace it can reach, and any agent that can query the store can retrieve another agent's confidential documents through embedding-space proximity. Shared-memory ACL addresses this by tagging every vector with a principal identifier at write time and filtering every retrieval query to the requesting agent's namespace, enforced at the gateway layer where the agent cannot bypass it.
Vector ACL A vector store returns results by embedding-space proximity, not by who is asking. Without a per-principal filter applied before similarity ranking, a query from tenant A can surface tenant B's vectors if the embeddings are close enough. Vector ACL closes that gap: every retrieval call is scoped to the requesting principal's namespace or payload partition before the store ranks any results, so cross-principal hits are structurally impossible rather than merely unlikely.
gVisor When an agent executes generated or retrieved code, that code runs as a process with access to the host kernel. A vulnerability in the generated code, or a deliberate exploit injected through the agent's prompt, can reach the kernel and affect other workloads or the host itself. gVisor prevents this by inserting a user-space kernel implementation between the container and the host: the container's syscalls go to the Sentry process, not to the host kernel, so the reachable attack surface from inside the container is structurally smaller.
Rate limits and quotas An agent operates without direct human oversight, autonomously scheduling tool calls, external API requests, and reflection loops. Without a budget, a single triggering event can fan out into hundreds of downstream calls. Per-agent rate limits and quotas assign each agent identity its own ceiling on call rate, token consumption, and cost spend, so a misbehaving or compromised agent cannot exhaust shared resources and its overconsumption becomes a visible, actionable signal.

Detect

No catalogued control.

Respond

No catalogued control.

In Helmwart

The Q2 cross-layer propagation analysis is microsegmentation’s threat-modelling counterpart: it traces how a compromise moves between MAESTRO layers.