Agents Have Boundary Issues. Your Infrastructure Shouldn't.

Why the five isolation boundaries in agent security research all point to the same conclusion: enforcement has to live outside the model.

Agent security research has been fragmented — organized around attack types, benchmarks, and application domains — which makes it hard to explain why prompt injection, tool misuse, and memory poisoning keep rhyming with one another. A new survey, "Isolation as a First-Class Principle for LLM-Agent System Safety", fixes that by asking one question of every attack and defense in the literature: where does the loss of isolation first occur?

The answer, the authors argue, always lands on one of five boundaries. And their core claim should sound familiar to anyone who has spent time in zero trust:

"Agent safety improves when system boundaries are explicit and enforced structurally, rather than left to prompt instructions alone."

That single sentence is the difference between soft guardrails and hard boundaries. System prompts, model training, and refusal behavior are probabilistic — a sufficiently motivated adversary can talk them out of their behavior. Hard boundaries are structural: policy engines, scoped credentials, and egress controls that sit outside the model and do not care how persuasive the injected text is.

The five boundaries

The paper places the agent core — policy, planning, memory — at the center, surrounded by five interfaces where isolation can fail:

User-agent: does user content remain data, or does it become control? This is the home of direct prompt injection, multi-turn steering, and memory poisoning that persists after the original interaction ends.

Agent-tool: how external capabilities are accessed. The failure set is broader than most teams realize — the system can fail "by choosing the wrong tool, passing unsafe arguments, trusting malicious output, or composing plausible calls into an unsafe workflow." In MCP-style ecosystems, the model sees tool descriptions and metadata before it ever invokes anything, and that metadata "can shape preferences, change routing, and bias decisions before real tool output even appears."

Agent-execution: the point where internal decisions become real actions. This boundary "turns control errors into operational impact." The research here is sobering: refusal training that holds up in a chat box degrades once the same model is clicking, navigating, and submitting through an interface.

Agent-agent: communication across multiple agents. The paper's memorable line — "a message is not just information. It can also be a carrier of control" — describes how one compromised agent turns ordinary coordination into an attack channel.

System-environment: how the agent reads the outside world. Webpages, retrieved documents, and interface elements should remain observations, not hidden commands. The conclusion: "web environments are active adversarial surfaces, not passive information sources."

Three of these boundaries converge at the access layer

Here is the practical observation the taxonomy makes possible. You cannot enforce the user-agent boundary from the network — that is a model and application problem. You cannot fully sanitize the system-environment boundary either — content scanning is a different layer.

But the agent-tool, agent-execution, and agent-agent boundaries share a property the other two do not: every violation crosses the network. A poisoned tool call, an unsafe execution, a malicious inter-agent message — each one is, mechanically, a request to a system you control, and each one can be evaluated before it lands.

That is where Pomerium sits. As an identity-aware gateway in front of your MCP servers, APIs, and internal applications, it enforces exactly what the paper says these boundaries need:

Agent-tool: make capability scope explicit. The authors conclude that safer tool use "depends less on the model inferring the right behavior from natural language, and more on interfaces that make capability scope, trust level, and action semantics explicit." That is least privilege for agents, and it is expressible in a route policy:

routes:
  - from: https://github.localhost.pomerium.io
    to: http://localhost:3020
    policy:
      allow:
        and:
          - domain:
              is: example.com
          - mcp_tool:
              in: ["search", "fetch"]

This agent, acting for this user, can call search and fetch on this MCP server — and nothing else. Not because the agent was asked nicely. Because the proxy refuses everything else, regardless of what the tool metadata convinced the model to attempt.

Agent-execution: govern the transition from reasoning to action. The paper's bottom line is that execution must be treated "as a governed interface, not as the automatic continuation of model output." Decoupling the brain from the hands means the model that decides never directly holds the credentials to act. Pomerium terminates external identity and issues short-lived, scoped tokens per request — so even a fully jailbroken model composes requests that a deterministic policy engine evaluates, denies, and logs.

Agent-agent: no implicit trust between peers. If every agent — including spawned sub-agents — must authenticate as a distinct identity and route calls through the same enforcement layer, a compromised message stops being a carrier of control. The paper warns that "collaboration is not automatically a safeguard. Without isolation, it can become a mechanism for amplification." Per-agent identity and per-request authorization is what keeps one bad agent from becoming a cascade.

And because the paper is emphatic that real attacks cross boundaries — the unit of analysis is "the full control path, not a single prompt or tool call" — the audit trail matters as much as the enforcement. Every allow-or-deny decision Pomerium makes is logged with full context, which is precisely the trace-level observability the authors call for.

What this doesn't solve

No access layer will make a model less persuadable, detect a poisoned RAG corpus, or strip hidden instructions from a webpage. Those live at the user-agent and system-environment boundaries, and they need their own defenses.

The mental model is containment: assume perception, reasoning, and memory can be compromised, and architect so that compromise cannot translate into unauthorized action. The researchers call this isolation-by-construction. Zero trust practitioners have been calling it something simpler for years: never trust, always verify — now applied to a client that can be talked into anything.

Agents will keep having boundary issues. The question for every deployment is whether those boundaries are enforced by the model's good intentions or by your infrastructure. Only one of those survives contact with an adversary.

Ready to put a hard boundary between your agents and your systems? Get started with Pomerium or read the MCP docs.