Data Separation Guarantees in Shared Agent Infrastructure

A vendor's contract says what they promised not to do. The architecture says what the system can't do, full stop. That gap is where the real risk sits in shared agent infrastructure, and most operators never bother to check which side of it they're actually on.

Here's the concrete version. A platform can hold a SOC 2 certificate, pass an outside audit, and still pool every customer's knowledge base into one shared vector store, kept apart only by a metadata tag on each record. Nothing in that audit stops a query bug from returning another tenant's documents. The certificate says the vendor follows good practice; it says nothing about whether cross-tenant leakage is possible in the first place.

Young infrastructure is the reason that gap exists. Agent platforms are maturing rapidly, and the paperwork has gotten written faster than the plumbing has. The question every operator should be asking is what the system is built to make impossible. Most people read the compliance page, feel reassured, and stop. That's the mistake this piece is about.

What shared agent infrastructure actually looks like at each processing layer

An agent doesn't run in one box. It runs across a stack, and each layer in that stack can be shared or walled off on its own, no matter what's happening one layer up or down.

Five layers matter here, and the fifth is the one operators skip constantly:

• Compute, where the agent process runs and takes action
• Storage, filesystem snapshots, intermediate files, context history
• Knowledge and retrieval, vector stores, RAG indexes, document corpora
• Tool credentials, OAuth tokens, API keys, connections to outside services
• Model inference, the LLM call itself, including the KV-cache state that carries context between turns

A platform can give every tenant a dedicated compute sandbox and still dump all their documents into one shared vector store. Or flip it: isolated knowledge bases sitting on top of shared compute. Neither setup is automatically wrong, but the risk profile is completely different, and a vendor's marketing page rarely spells out which combination you're actually buying.

The 2025 paper Infrastructure for AI Agents (updated June 2025) puts a name on this: "agent channels," dedicated pathways that keep agent traffic separate from everything else moving through the system. It draws a direct line to analogous separation patterns in other regulated industries, where dedicated infrastructure boundaries are standard practice. Those industries solved their separation problem in the infrastructure itself. Most operators evaluating agent vendors right now couldn't tell you which of the five layers above are actually split apart at the infrastructure level versus which ones are just filtered in software. That distinction is the whole ballgame, and getting it wrong is the norm, not the exception.

Where metadata filtering fails as a substitute for real separation

Metadata filtering looks like isolation, and the gap between the appearance and the reality is where most breaches start. Here's how it actually works: every tenant's data sits in the same store, and every query carries a tag, a tenant ID, meant to restrict what comes back. On paper, tenant A never sees tenant B's data. In practice, that guarantee rides entirely on the filter never failing, and filters fail in a few predictable ways.

A bug in how a query gets built can drop the tenant filter entirely. When that happens, the system doesn't throw an error; it just returns the wrong data, silently, and nobody notices until a customer does. Prompt injection makes this worse: an agent can be talked into issuing a retrieval query that skips the filter on purpose, whether the attacker meant to hit a specific tenant or just stumbled into it. Rate limits and quota checks run into the same trap when they live only in the application layer, since a bug or a clever prompt walks right past them. Real enforcement for that kind of control belongs in an API gateway or a service mesh, somewhere the application code has no path around.

A 2026 workshop paper from the ACL/IEEE community, AI Agents Need Both Hardware-Backed Security and Application-Level Guardrails, makes the point bluntly: software guardrails alone aren't enough. Secure agents need hardware-backed protection stacked underneath application-level controls, working together instead of standing in for each other.

When a vendor says "we isolate tenant data," push back with one follow-up: what happens, technically, the moment a tenant identifier goes missing or gets attached to the wrong query? A shrug for an answer is your signal to walk.

The enforcement patterns that actually make cross-tenant access structurally impossible

A sound enforcement pattern for multi-tenant agent platforms centers on one rule: tenant identity travels as a signed, validated claim through every layer of the stack. Every service call, every inference request, every retrieval, every tool execution, every read and write to state, carries that signed claim — and enforcement happens at the layer itself.

At the storage layer, this closes one of the ugliest failure modes: the misconfigured shared mount. The fix is ensuring each tenant's storage is architecturally separated from every other tenant's, with no shared mount points between them. Where a shared filesystem can't be avoided, mount paths get filtered by tenant ID at the infrastructure level. Where storage accounts do have to be shared for cost reasons, separate encryption keys per tenant limit the blast radius of any single breach.

At the knowledge layer, the pattern is a separate vector store per tenant, with isolation enforced at query time by the retrieval system itself. Credentials follow the same logic: scoped per tenant, held in a vault, never sitting in a prompt or an environment variable where a stray log line could expose them. At the inference layer, sharing an endpoint across tenants is a reasonable cost tradeoff, but inference-layer context must not bleed across tenant boundaries — cached state from one user's session should never surface in another user's response.

The signed-claim approach does double duty. It closes the security gap, and the per-layer enforcement it requires also produces structured, auditable records of what each tenant actually consumed.

How the agents operators are actually deploying differ in their default isolation posture

Four agents dominate production deployments right now: OpenClaw, Hermes, Claude Code, and Codex. They are not interchangeable on isolation, and picking between them is a governance decision as much as a features decision. Treating it purely as a features decision is how a security review blows up months into a deployment.

The axis that matters most: does the agent run as a message-driven harness on infrastructure the operator controls, or does it ship code and context off to a cloud VM the vendor controls?

OpenClaw, the open-source runtime with 369,000 GitHub stars, is self-hosted. Deployed on an operator's own infrastructure, the data never has to leave that environment. Its power as a meta-orchestrator, though, means a security review before deployment isn't optional; a misconfiguration here has a wider blast radius than in a narrower tool. Hermes, from Nous Research with 140,000 GitHub stars, is also self-hosted, keeping data inside the operator's own environment.

Claude Code sits on the other side of that line. For production engineering teams, it's arguably the strongest option on reasoning quality and harness maturity, but operators should verify its data residency and infrastructure arrangements directly with Anthropic. Codex, OpenAI's coding agent, open-sourced April 16, 2025, and folded into the ChatGPT desktop app on July 9, 2026, runs tasks in a vendor-managed cloud environment. The environment itself is vendor-managed, and the operator doesn't own that boundary.

Tool connectivity options vary across the four, and operators should verify protocol support for their specific integration requirements. The real differences show up in reasoning quality, how customizable the ecosystem is, and, critically, who controls where the data actually lives. For regulated industries, compliance requirements should outrank feature preferences, not just tie with them.

What per-user sandboxing means in practice and why it is the right unit of isolation

A sandbox, in this context, is an isolated place where an agent can act, run code, touch files, without those actions reaching the host system or spilling into another tenant's environment. The unit that matters is per-user, not per-customer-account and not per-application. Each individual user gets their own sandbox, and that sandbox has to hold state across turns of conversation. Isolation plus persistence, together, is what makes this the right building block for agent products. Anything coarser than per-user is a compromise dressed up as a design choice, and vendors selling per-account sandboxing as equivalent are selling you something weaker than they're implying.

Each sandbox should own its own disk, its own URL, its own credential context, its own session state. Get that right, and a failure or a leak or a runaway action in one sandbox has nowhere to go. It stays contained.

The open-source Agent-Sandbox project is a useful reference for what production-grade sandboxing actually takes beyond the isolation boundary itself. Projects in this space address allocation speed, state management across turns, and cost control as distinct engineering problems. Observability matters because nobody can manage a system they can't see into.

None of that replaces a hardened runtime underneath it, though. CNCF's analysis of the runc container breakouts disclosed in November 2025 flagged serious vulnerabilities in multi-tenant container environments, a reminder that the runtime underneath the sandbox matters as much as the boundary itself. Per-user sandboxing is necessary, but on its own, it is not enough. Ask any vendor which container runtime sits under their sandboxes and exactly how they responded to that November 2025 disclosure. The answer tells you whether the isolation boundary is real or just assumed.

Tiered isolation as a product and pricing decision, not just an engineering one

Isolation isn't a switch. It's a spectrum, and the practical move for a platform is to build tiers that match how much a customer needs against how much they're willing to pay for it. Selling one-size-fits-all isolation, at any price point, is a mismatch waiting to surface in a compliance review, and it's the wrong call even when it's the cheaper build.

A workable structure looks something like this. A shared sandbox tier, fine for low-sensitivity work, leaning on metadata filtering backed by strong runtime controls. A dedicated sandbox pool tier, with per-user compute and storage kept apart, the sane default for most B2B SaaS customers. A dedicated inference endpoint tier, which removes the KV-cache cross-contamination risk entirely and matters for any customer pushing sensitive conversations through at volume. A fully dedicated infrastructure tier, where the customer eats the full infrastructure cost in exchange for maximum data residency and compliance guarantees, the pattern financial institutions and healthcare organizations tend to require.

Customers should self-select based on what they actually need and what they can afford. The operator's job is to make the isolation posture of every tier plainly legible, so the customer's compliance team can make an honest call rather than guess. The signed-claim architecture described earlier is what makes accurate billing by tier and by usage possible in the first place. Operators building on managed infrastructure don't have to engineer this tier structure from scratch: a well-designed infrastructure layer's isolation model turns into a feature the operator can sell, not just a cost center to absorb, Agent37, for instance, is a hosted agent deployment platform where each customer gets a provisioned, isolated agent automatically, so the tier structure is inherited rather than hand-built.

How integration credentials introduce a cross-tenant risk surface that most operators don't audit

Agents wired into Gmail, Slack, GitHub, or WhatsApp are holding OAuth tokens and API keys on behalf of real users. Those credentials are a data-separation problem in their own right, one that gets audited far less than storage or compute. That gap in scrutiny is exactly why it deserves a closer look.

Here's the failure mode: OAuth tokens sitting in one shared credential store, matched to the right user through an application-layer lookup instead of being cryptographically scoped to that tenant from the start. A bug in that lookup, or a storage-layer misconfiguration, and one user's agent starts acting with another user's credentials. This is what happens when credential storage gets treated as an afterthought, which is exactly how most teams treat it.

The right pattern keeps each user's connected accounts in a vault, scoped individually, so the agent acts on behalf of the right person without a developer or operator ever touching an individual token by hand. Composio, an integration layer for connecting agents to outside SaaS tools, handles this by keeping each user's OAuth credentials inside a "connected account" scoped to that specific user. Composio holds SOC 2 and ISO 27001:2022 certifications, which matters here precisely because the integration layer is so often the weak link in an agent architecture that's otherwise well-isolated everywhere else.

Operators should be asking one audit question: where, exactly, do your users' OAuth tokens live, at what layer are they scoped, and what, specifically, stops a lookup error from handing the wrong user's credentials to the wrong agent?

The evaluation framework: questions that distinguish architectural isolation from contractual filtering

Everything above points to one habit: ask what a vendor's architecture makes impossible. Here's how that plays out layer by layer.

On compute: is each user's agent process running in its own isolated sandbox, or is multi-tenancy handled inside a shared process at the application layer? What container runtime enforces that boundary, and what did the vendor actually do about the November 2025 runc disclosure? On storage: are per-user volumes attached exclusively to one user's sandbox, or is there a shared filesystem filtered by path? What happens if a tenant ID goes missing from a storage request? On knowledge and retrieval: separate vector store per tenant, or shared index with metadata filters, and what's the failure mode if a filter gets dropped? On inference: is KV-cache disabled across tenant boundaries, or could cached context from one session leak into another user's answer? On credentials: are OAuth tokens scoped cryptographically per user, or matched up through an application-layer lookup that could point the wrong way? On quotas: are rate limits enforced at the API gateway or service mesh, where the application can't route around them, or only inside the application itself?

Then there's the certification question, and it deserves closer reading than most operators give it. A SOC 2 Type I report only certifies that controls were designed correctly at one point in time; a Type II certifies they operated effectively over a stretch of months. Neither one certifies that isolation is architectural rather than a matter of policy and good intentions. Treating either as proof of structural separation is the single most common mistake in this whole evaluation, and it's the one worth fixing first.

Last, the training-data question deserves the same treatment. Most vendors answer it contractually: "we don't train on your data." The architectural version of that question cuts sharper: is there any pipeline, any batch job, any path at all through which a user's conversation could reach a shared fine-tuning process, and what technical control stops it?

Operators who can answer every one of these questions about their own infrastructure are in a position to make an honest data-separation claim to their customers. Those who can't have just found the list of gaps they need to close before they make that claim at all.