Helmwart
← Atlas · Mitigations Tier 2 · Real-composable

MITIGATION · m-shared-memory-acl

Shared-memory ACL — per-agent, per-namespace read/write access control on shared vector stores

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.

Last reviewed 2026-05-14 · Status: published · Evidence →

At a glance

MATURITY
Tier 2
Available off-the-shelf or as a documented pattern, but newer or less broadly proven. Expect integration work and some operational nuance.
PLACES ON
node · edge
Restricted to node kinds: shared-memory, document-store
COVERAGE
4 threats
T18 · T27 · T28 · T49
TRADE-OFFS
LAT
low
COST
low
UX
low
DEV
medium
Latency · cost · UX friction · dev effort.
TL;DR
  • Every vector write to a shared store must be tagged with the producing agent's identity at the ingestion gateway, never as a caller-supplied parameter, which would allow namespace spoofing.
  • Every retrieval must filter on the requesting agent's namespace; embedding-space proximity is not a security boundary and will return another agent's confidential vectors without this filter.
  • Write-path ACL must be enforced at the API gateway layer, not the application layer; a compromised agent can bypass application checks but not a gateway-level policy engine.
  • This control covers the write-side ACL pattern and namespace isolation for shared memory; retrieval-time ACL for single-agent deployments is covered by m-vector-acl.

How it behaves

Agent requests a write to the shared vector store (embedding + metadata)
Gateway authenticates caller identity (SPIFFE SVID or equivalent) and compares it against the target namespace in the write request
Vector written to caller's namespace with principal tag; retrieval from other namespaces is filtered out at query time
Write rejected. Log denial with agent identity, target namespace, and reason. Namespace tag absence is treated as a policy violation, not a configuration warning.
The namespace is set by the gateway, not the calling agent. Any write path that lets the agent supply its own namespace parameter is a spoofing surface.
Pair with m-mem-validation at the write boundary (content quality) and m-vector-acl for retrieval-side enforcement in single-agent deployments.

What it is

A shared vector store is a common architecture in multi-agent systems: multiple agents write embeddings and retrieve context from a single index, typically to reduce infrastructure cost. The store itself does not know which agent should be allowed to read or write which documents. Without explicit access controls, the partition boundaries between agents are enforced only by application code, and that enforcement can be bypassed.

The two failure modes are distinct. On the write side, an agent that has been compromised or manipulated can insert adversarially crafted vectors into any namespace it can reach in the shared index. Those vectors are then retrieved by downstream agents as though they were legitimate memory content, which is the RAG input manipulation attack path (OWASP MAS T18, T27). On the read side, a retrieval query that is not filtered to the requesting agent's namespace will return documents from other namespaces when a query embedding is semantically close to them. Embedding-space proximity is not a security boundary, so confidential documents belonging to one agent are reachable by another through ordinary similarity search (T28).

The control closes both paths. Three enforcement layers are required together for complete coverage: namespace tagging at write time, principal-scoped filtering at retrieval time, and write-path ACL enforcement at the ingestion API gateway. The namespace tag must be assigned by the gateway from the authenticated agent identity, never passed as a caller-supplied parameter, because a caller-supplied namespace is a spoofing surface. The retrieval filter must be enforced at the storage layer or the query gateway, not only in application code, because a direct storage query or a framework bypass can circumvent application-layer filtering.

Sibling control m-vector-acl covers retrieval-time ACL for single-agent deployments. This page covers the write-side ACL pattern and namespace isolation for shared multi-agent memory.

Detection signals

  • Cross-namespace write denials per agent identity. A non-zero rate from an unexpected identity points to a misconfigured ingestion path or an active attempt to write outside the agent's permitted namespace.
  • Namespace tag absent on write. Any write that reaches the store without a principal tag is a policy violation indicating a gap in the ingestion pipeline, not a configuration warning.

Threats it covers

  • T18 RAG Input Manipulation Leading to Policy Bypass −2 severity steps

    WHY IT HELPS RAG Input Manipulation requires write access to the shared retrieval corpus. Per-namespace write ACL removes that access from agents whose identity does not map to the target namespace, so a manipulated agent cannot insert adversarial vectors into a downstream agent's retrieval path.

  • T27 Vector Database Poisoning with Malicious Smart Contract Data −2 severity steps

    WHY IT HELPS Namespace-scoped write ACL constrains a blockchain-integrated agent's write surface to its own partition, so malicious smart-contract data cannot be written into a namespace used by a different agent. Retrieval-side ACL prevents a separate agent from reading poisoned financial-instrument embeddings across namespace boundaries.

  • T28 RAG Data Exfiltration −2 severity steps

    WHY IT HELPS RAG Data Exfiltration depends on embedding-space proximity returning documents the requesting agent was not authorised to read. Retrieval-side namespace filtering is the structural control: a query filtered to the requesting principal's namespace cannot return records written to a different namespace.

  • T49 Semantic Drift in Embeddings −1 severity step

    WHY IT HELPS Namespace isolation contains semantic drift within the affected agent's partition. An agent whose memory corpus has drifted cannot propagate that drift into the namespaces of agents operating in separate partitions.

Principle coverage

Defence-in-Depth stage: Prevent — and it advances:

  • Microsegmentation Namespace ACL is microsegmentation applied to the shared vector store: each agent identity is confined to its own partition of the index, so a misbehaving or compromised agent cannot read from or write into any adjacent agent's namespace regardless of what it requests.
  • Memory & RAG Integrity Namespace-scoped write ACL is the primary structural control for memory integrity in shared stores: only the agent whose identity is bound to a namespace can write to it, so adversarial vectors cannot enter a namespace through a different agent's write path.
  • Data Minimization & Privacy Retrieval-side namespace filtering enforces data minimisation at the query layer: each agent's retrieval results are bounded to records written under its own namespace, so the agent never receives documents from other agents' corpora that it has no legitimate reason to access.
  • Least Common Mechanism Namespace isolation reduces the shared mechanism surface of the vector store: each agent operates on its own partition rather than a common namespace, limiting the structural coupling between agents at the storage layer.

Design & governance principles (open design, economy of mechanism, accountability, …) are architectural, not advanced by a single placed control.

Implementation options

Five implementation options covering native multi-tenancy APIs, RBAC layers, payload-based partitioning, key-namespace ACLs, and a self-build namespace-per-agent pattern. The right choice depends on your vector store. Weaviate multi-tenancy and Weaviate RBAC compose as the most complete write-side ACL stack; Qdrant requires application-layer enforcement for writes; Pinecone namespaces provide partition isolation but API key scoping is project-level, not namespace-level on standard plans.

Weaviate multi-tenancy + RBAC Enable multiTenancyConfig on collection creation; each tenant is stored on a separate physical shard. Pair with Weaviate RBAC (GA v1.29) to restrict which agent identity may write to which tenant, at collection x tenant granularity.

Why choose it: Best when your vector store is Weaviate and you need write-side ACL enforced by the database, not the application. Weaviate RBAC supports 12 distinct permission resource types including a dedicated Tenants resource and a Data Objects resource; roles can be scoped to specific collection patterns and tenant patterns simultaneously. "Data stored in one tenant is not visible to another tenant" is a storage-level guarantee, not a query-filter convention. The RBAC layer adds write-side enforcement so an agent whose role does not include create/update for a target tenant receives a database-level denial.

More details:

Pinecone namespaces Pinecone namespaces partition a single index so that upsert and query operations are scoped to a named partition. API key scoping is project-level on standard plans; namespace-level write ACL must be enforced by an authenticated write gateway in front of the Pinecone index.

Why choose it: Best when your vector store is Pinecone and you can tolerate an application-layer write gateway for ACL enforcement. Pinecone namespaces provide strong retrieval-side isolation: a query scoped to namespace A cannot return vectors from namespace B. The gap: Pinecone API key permissions are project-level, not namespace-level, on Starter and Builder plans; Enterprise plans support custom permissions but the namespace dimension is not explicitly scoped per key as of mid-2026. The write gateway pattern (authenticate agent via SPIFFE JWT-SVID; derive namespace from authenticated identity; never pass namespace as a caller parameter) is the production workaround. Target your index by host, not by inference endpoint, when enforcing custom permissions.

More details:

Qdrant payload partitioning Qdrant's recommended multi-tenancy pattern uses a group_id payload field on every vector. Queries filter on group_id to enforce per-tenant retrieval. Write-side access control has no native database-level RBAC; it relies on application-layer logic routing upserts with the correct group_id.

Why choose it: Best when your vector store is Qdrant and you accept that write-side ACL must live in your ingestion gateway rather than in the database. Qdrant v1.16.0+ supports tiered multi-tenancy: dedicated shards for large tenants, fallback shards for small tenants sharing resources. Write isolation must be enforced upstream; the gateway must authenticate the calling agent and set group_id from the authenticated identity, never from a caller-supplied parameter. Qdrant collection-level RBAC is not available; the documented isolation mechanism is payload filtering at query time. The absence of native write-side ACL means a misconfigured gateway can silently write to the wrong partition.

More details:

Redis Vector ACL Redis ACL (ACL SETUSER) binds a user identity to a key-pattern prefix. An agent assigned ~vector:agent1:* can read and write only keys under that prefix; keys under vector:agent2:* return NOAUTH. RediSearch / Redis Stack vector indexes inherit the same key-pattern ACL.

Why choose it: Best when your vector store is Redis Stack or Redis Enterprise Vector and you want write-side ACL enforced at the server, not the application. The ACL SETUSER command maps a username to a key pattern (e.g. ~vector:agent1:*) and a command allow-list (e.g. +FT.ADD +FT.SEARCH). Because Redis enforces the key-pattern constraint at the server level, a misconfigured application that passes the wrong key prefix gets a server-level NOAUTH, not a silent write to the wrong namespace. Pair ACL SETUSER with short-lived credential issuance so agent credentials rotate on the same TTL as SPIFFE SVIDs.

More details:

Self-build write gateway Assign each agent a stable namespace identifier at provisioning time. Run a write gateway that authenticates the calling agent via SPIFFE JWT-SVID, derives the target namespace from the SVID subject, evaluates an OPA or Cedar policy that maps SVID to permitted namespace(s), and injects the namespace tag before forwarding to the vector store SDK.

Why choose it: The only option when your vector store has no native write-side ACL and you need a consistent pattern across multiple stores. The pattern works with any vector store because the enforcement lives in the gateway, not the store. The write-allowlist policy in OPA or Cedar is the authoritative mapping of agent identity to namespace(s); it can be updated without redeploying the gateway. Cross-namespace read for legitimate shared corpora (a shared knowledge base all agents read) is expressed as a whitelist exception in the policy, not a structural exception to the ACL. Budget one to two engineer-weeks for the authenticated gateway, SPIFFE integration, and OPA policy; namespace tagging in the SDK is a one-line change per write call.

More details:

Trade-offs

  • Weaviate RBAC + multi-tenancy is the most complete write-side ACL stack because enforcement lives in the database; the cost is that Weaviate RBAC requires v1.29+ and adds role and user management operational surface.
  • Pinecone and Qdrant require application-layer write gateways because their native ACL does not reach the namespace level on standard plans; every ingestion path through the gateway must be audited, as a path that bypasses the gateway silently removes the ACL.
  • Redis ACL key-namespace enforcement is server-side and strong, but Redis is less common as the primary vector store for large embedding corpora; it is more natural as a short-term or session memory store where namespace ACLs are especially valuable.
  • The self-build gateway pattern adds infrastructure to operate; the gateway is a single point of failure for writes and must be highly available. The benefit is vendor-agnostic enforcement and a single policy file that covers all stores.
  • Cross-namespace read whitelists (for shared knowledge bases) increase the policy surface that must be audited; maintain a separate audit cycle for whitelist exceptions distinct from the main namespace ACL review.

When NOT to use

  • Skip this control when each agent has its own dedicated vector database instance with no shared access path; namespace ACL on a shared index is solving a problem that does not exist in that topology.
  • Do not use namespace ACLs as the only safety layer when agents legitimately need broad cross-namespace read access; the whitelist exceptions required to support that pattern erode isolation and must be audited at higher frequency than the base ACL.
  • Do not rely on application-layer namespace tagging alone when the vector store supports gateway-level or server-level ACL enforcement; always prefer the enforcement point closest to the storage layer.
  • This control does not address intra-namespace content quality; a compromised agent can still poison its own namespace. Do not skip m-mem-validation on the assumption that namespace isolation prevents write-side content manipulation.

Limitations

  • ACLs protect namespace boundaries, not intra-namespace content. A compromised agent can write adversarially crafted vectors into its own namespace; pair with m-mem-validation for write-time content validation.
  • Qdrant and Pinecone (on standard plans) have no native write-side ACL at the namespace level; enforcement depends on the correctness of the write gateway. A gateway misconfiguration or bypass is silent: the vector store accepts the write regardless of which agent supplied it.
  • Namespace granularity is a policy decision; coarse namespacing (one namespace per team) provides weaker isolation than per-agent-identity namespacing. The threat model should drive the choice, not operational convenience.
  • There is no cross-vendor standard for namespace ACL expression; the write-gateway policy must be re-expressed per vector store SDK. This is the primary reason the composed pattern stays at Tier 2.

Maturity tier reasoning

  • Tier 2 fits because the underlying primitives (Weaviate multi-tenancy + RBAC, Pinecone namespaces, Qdrant payload partitioning, Redis ACL key patterns) are all production-available with documented APIs.
  • What keeps the pattern at Tier 2 is the absence of a cross-vendor write-side ACL standard and the fact that two of the five major vector stores (Pinecone standard plans, Qdrant) require application-layer enforcement for write-side ACL rather than database-level enforcement.
  • Weaviate RBAC (GA v1.29, early 2025) is the first major vector store to expose write-side ACL at the tenant granularity as a database-native primitive; the others follow the retrieval-filter convention established by Pinecone namespaces.

Last verified against upstream docs: 2026-05-30.