Tenant-Isolated Agent Memory: Why App-Level Filters Fail

Benchling runs more than 600 agent code-execution sessions a day across 250+ tenants a week with zero security incidents — and they got there by rejecting the approach most teams default to. That result, from Benchling’s AWS case study, is the sharpest evidence I’ve seen that tenant-isolated agent memory is an infrastructure problem, not an application problem. If your isolation strategy is a tenant_id column and a WHERE clause, you’re building on a control that agents are specifically shaped to bypass.

Here’s the core issue. Traditional SaaS multi-tenancy assumes a stateless request path: authenticate, filter rows, return. Agents break every part of that assumption. They hold state across sessions, retrieve semantically rather than by key, call tools with real credentials, and run background jobs long after the original request context is gone. Each of those is a path around your app-level filter. What I call the layered agent tenancy pattern — isolation enforced at every layer of the stack, from vector index to credential vault — isn’t paranoia. It’s the only architecture that matches how agents actually behave.

Why doesn’t a tenant_id filter protect agent memory?

Because vector search doesn’t work like a SQL query, and the order of operations determines whether your isolation is real or statistical. When you run an approximate nearest neighbor (ANN) search over a shared index and then drop other tenants’ rows afterward — post-filtering — two things go wrong, and only one of them is obvious.

The obvious one: the request serving tenant A read and scored tenant B’s vectors before discarding them. That’s a leak, full stop. The subtler one is worse in practice. If the global top-ten results contain only three of your tenant’s rows, the agent gets three memories and no error. You don’t get a permission denied. You get a quietly worse answer, and nobody files a bug report because nothing crashed. As the HackerNoon analysis of vector search isolation puts it, this is a filtering problem, not a ranking problem — two tenants in the same vertical will write near-identical facts (“we deploy to eu-central-1,” “primary datastore is Postgres”), and those embed to nearly the same vector. Ranking cannot separate what semantics can’t.

The fix is pre-filtering: making the tenant constraint part of the search itself, so the candidate set only ever contains rows the caller may see. The good news is that every serious vector store supports pre-filtering — Qdrant, pgvector, and the managed stores all have a mechanism. The bad news is that nothing forces you to use it. That’s a discipline gap your infrastructure should close, not a code review checklist item.

Supermemory’s multi-tenant memory guide states the invariant plainly: a request authenticated for tenant A must never return tenant B’s context, even when B’s data is the better semantic match. If your current setup can’t pass that test with two tenants holding similar conversations, you don’t have isolation — you have a hope.

What does infrastructure-enforced memory isolation actually look like?

It looks like authorization that lives below your application code, derived from identity rather than supplied by the caller. Per Supermemory’s guide, multi-tenant agent memory requires authorization on every read and write operation, with a stable scope attached to the data — and a container tag or namespace helps select the right memory but is never a substitute for checking which tenant and user the caller may access.

The implementation details matter more than the principle:

• Derive scope on the server. Resolve the tenant-user pair from a trusted session or service identity, then map it to an application-owned scope ID. Never accept an arbitrary container identifier from a client request and pass it through with a privileged API key — that’s the single most common way “scoped” systems become unscoped.
• Enforce at every entry point. Supermemory’s checklist covers write/import, search, fetch by document ID, update/delete/export, background processing, and cache lookup. That last pair is where teams get burned: a background job that loses the original authorized scope, or a cache key that omits tenant context, bypasses everything upstream.
• Don’t trust ingestion stamps. Stamping a tenant ID at write time does nothing for an unscoped read. The check has to happen at retrieval, every time.

Zoom out one level and memory is only one of the surfaces. Gravity’s isolation guide enumerates six layers an agent platform must isolate: authentication, request routing, storage, retrieval, cache and trace logs, and tool credentials. Their line on retrieval is the one I’d tape to the wall: cross-namespace queries should be an API-level impossibility, not an application-level filter. The consensus across OpenLegion’s multi-tenancy analysis is similar — agent platforms must isolate credentials, memory, execution context, and audit records at the infrastructure layer, because agents hold live API keys and accumulate persistent state in ways web apps never did.

Shared store or per-tenant indexes — which should you choose?

This is where the research genuinely disagrees, and the honest answer is: it depends on your threat model and your tenant count, not on a universal best practice.

The case for shared infrastructure is real. The widely held view, articulated in Supermemory’s guide, is that a shared store with enforced authorization and scoped queries can support logical separation — separate databases become appropriate when contractual boundaries, recovery requirements, or resource isolation demand them, not as a default. If you’re running a few hundred tenants with similar risk profiles, per-tenant databases are operational weight you don’t need.

The case against is also real, and it’s about physics as much as security. Precisely’s S3 Vectors case study explains why they went the other way: Amazon S3 Vectors supports thousands of independent vector indexes per bucket, so they created one per tenant. A tenant’s vectors enter the query path only when that tenant is active, request limits are enforced per index, and an ingest burst from one customer is contained to that customer’s index. In a shared index — even a sharded one — a handful of active tenants pulls everyone’s data into the query path, and you end up sizing for aggregate peak instead of actual demand.

Here’s how the main approaches stack up:

Approach	Isolation mechanism	Pricing signal	Best for
Shared store + pre-filtering	Tenant constraint inside the ANN search	—	Hundreds of tenants, homogeneous risk, cost-sensitive
Per-tenant indexes (S3 Vectors)	Physically separate indexes, per-index request limits	Billed on data stored and processed per AWS’s Precisely writeup	Thousands of tenants, uneven activity, noisy-neighbor concerns
AgentCore Memory + FGAC	Gateway-enforced Cedar policies on OAuth identity	—	AWS-native teams wanting managed authorization
Google Memory Bank	Managed memory with per-revision storage billing	$0.30/GiB-month on total data including revisions	Gemini Enterprise shops already on the platform

One wrinkle worth noting on that last row: Google’s meter counts stock, not flow — revisions accumulate silently, and memories carry no default TTL, so your October invoice can reflect a configuration decision made in April. If you’re weighing self-hosted against managed memory more broadly, our cost breakdown of Postgres + pgvector versus paid agent memory stores found the self-hosted baseline runs 2-6x cheaper at scale, with no independent evidence that paid tiers retrieve better.

What are the managed platforms actually shipping?

The managed layer moved fast in late August 2026, and the direction is telling: authorization is moving out of application code and into the gateway. AWS shipped fine-grained access control for AgentCore Memory, which fronts a Memory resource with AgentCore Gateway, authenticates callers via OAuth/JWT, and attaches Cedar policies that restrict access based on token claims — per-user and per-tenant isolation enforced with cryptographic proof of identity rather than an actor-ID check you remembered to write. The managed connector exposes 12 Memory operations as Cedar actions, so you can allow or deny specific operations per caller.

Alongside it, flexible namespace variables let you scope long-term memories by organization, tenant, team, or environment using up to five custom keys per memory resource, with runtime values substituted into namespace templates during extraction. The design intent is explicit: the tenant boundary comes from a trusted identity source, not from request input.

But the more interesting story is what Benchling rejected. Their security team explicitly ruled out per-tenant IAM roles — at thousands of tenants, role sprawl becomes unsustainable — and instead combined VPC isolation, Route 53 DNS Firewall, and VPC endpoint policies to enforce per-job data access without individual roles. That’s the counterweight to the “dedicated everything” instinct: attribute-based controls on shared infrastructure can pass a strict threat model if the enforcement point is the network and the policy engine, not the app. The broader silo-versus-pool-versus-bridge decision maps closely to what we covered in the tenant-isolated agent tools field guide — pick based on regulatory exposure and platform capacity, not on default settings.

What leaks beyond the memory store?

Memory gets the attention, but the layers around it fail quietly. Three deserve specific mention.

The inference layer itself. Zylos Research’s multi-tenant architecture analysis documents that KV-cache sharing — a standard LLM serving optimization — creates a measurable timing side channel: time-to-first-token is detectably faster on a cache hit, and an adversary can exploit that to reconstruct another tenant’s cached prompt tokens. This isn’t theoretical; it appeared as a documented attack class in 2025. If your serving stack shares KV-cache across tenants, no amount of vector-store hygiene closes that hole.

Credentials. An agent calling tools holds live API keys, and a shared key means shared rate limits, commingled billing, and revocation blast radius. Gravity’s guide treats per-tenant credentials — vaulted, rotated, no shared keys — as a mandatory control. Benchling’s counterexample shows the operational cost of taking that literally at scale, so the pragmatic reading is: isolate the authorization decision per tenant, even where you can’t isolate every credential object.

Prompt instructions. The consensus in Naïve’s tenant isolation writeup is blunt: isolation is structural, with every resource attached to exactly one tenant user and scoping enforced by the platform on every call. A system prompt that says “only act for the current user” is not a control — prompts can be injected, and platform boundaries can’t. Production platforms have converged on the layered defense Zylos describes: namespace or container isolation for runtime, vector-namespace or separate-database isolation for memory, credential vaulting with per-tenant scopes, and per-tenant rate limiting. If you’re also evaluating where the execution side of this lives, our piece on agent execution engines and runtime lock-in covers how the memory layer has become the real switching cost.

How do you decide where your tenancy boundary lives?

Work from your failure modes backward, not from vendor features forward. Three questions, in order:

1. What’s the blast radius of a cross-tenant read? If you’re in a regulated domain or your tenants are competitors, post-filtering on a shared index is disqualifying — the silent degradation problem alone should end that conversation. Pre-filtering is the floor; per-tenant indexes or gateway-enforced policies are the ceiling.
2. How many tenants, and how uneven is their activity? Below a few hundred homogeneous tenants, a shared store with server-derived scope and pre-filtered retrieval is defensible and cheap. At thousands of tenants with spiky usage, the Precisely topology — physically separate indexes with per-index limits — starts paying for itself in contained blast radius alone.
3. Where does your team have operational depth? ABAC-style shared infrastructure (the Benchling path) demands strong policy engineering. Dedicated-per-tenant infrastructure demands strong provisioning automation. Pick the complexity you’re staffed to operate, because the control you can’t maintain is the control that fails during an incident.

The one position I don’t think is defensible anymore is treating tenancy as an application feature — a column, a filter, a prompt instruction. Agents are stateful, autonomous, and semantically driven, and each of those properties routes around app-level checks. Enforce the boundary in the infrastructure, test the negative cases deliberately (attempt cross-tenant reads, writes, and deletes in CI), and assume that whatever you don’t test is already leaking. The open question I’d put to your team this week: can you name the exact layer — index, gateway, or policy engine — where your tenant boundary is enforced on a memory read? If the answer is “the application code,” you already know what to fix first.