EVIDENCE TRAIL
Shared-memory ACL
Verbatim excerpts from the upstream sources cited on the mitigation page, with what each source does and does not prove. This control covers write-side ACLs and namespace isolation on shared vector stores. The sibling control m-vector-acl covers permission-aware retrieval in single-agent deployments.
Last cross-checked against upstream sources: · 10 sources
References
Each entry shows what the source supports and what it does not prove.
OWASP Top 10 for Agentic Applications 2026
§ASI06 Memory & Context Poisoning — Attack Scenario 5
"Cross-tenant vector bleed: Near-duplicate content seeded by an attacker exploits loose namespace filters, pulling another tenant's sensitive chunk into retrieval by high cosine similarity."
Supports: Names "loose namespace filters" as the structural gap that enables cross-tenant data leakage through embedding-space proximity. Verbatim definition of the threat that per-namespace retrieval ACL closes.
Does not prove: Describes the attack, not the mitigation mechanism. Does not specify how namespace filters should be enforced at the write or retrieval boundary.
OWASP Top 10 for Agentic Applications 2026
§ASI06 Memory & Context Poisoning — Prevention and Mitigation Guideline 7
"Where you operate shared vector or memory stores, use per-tenant namespaces and trust scores for entries, decaying or expiring unverified memory over time and supporting rollback/quarantine for suspected poisoning."
Supports: Direct upstream prescription of per-tenant namespaces on shared vector or memory stores. Closest OWASP match for the write-side ACL pattern this control implements.
Does not prove: Bundles namespace isolation with trust-scoring and expiry as one combined guideline. Does not separately articulate write-ACL enforcement at the API gateway layer or SPIFFE identity binding.
OWASP Agentic AI — Threats & Mitigations v1.1
§Introduction — RAG and Agentic AI (cross-reference to LLM08:2025)
"Readers should refer to that section and implement necessary mitigations, including permission-aware vector databases, data validation pipelines, and continuous monitoring for poisoning or embedding inversion risks."
Supports: Names "permission-aware vector databases" as a required mitigation for RAG threats in agentic systems. Establishes that access control on the vector store is an expected control, not an optional hardening step.
Does not prove: Delegates the detailed control definition to LLM08:2025 rather than specifying the ACL mechanism. Does not distinguish write-side from retrieval-side enforcement.
OWASP Agentic AI — Threats & Mitigations v1.1
§Memory Poisoning Playbook — Step 1: Prevent Memory Poisoning (Proactive), items 6–7
"Segment memory access using session isolation, ensuring that AI does not carry over unintended knowledge across different user sessions. Restrict AI memory access based on context-aware policies. Enforce that AI agents can only retrieve memory relevant to their current operational task, reducing risk of unauthorized knowledge extraction."
Supports: Upstream prescription for memory segmentation and context-aware retrieval policies that mirror the namespace-scoped retrieval filter this control requires. Frames "unauthorized knowledge extraction" as the retrieval-side threat.
Does not prove: Frames isolation in terms of sessions and tasks, not per-agent namespace identities. Does not specify that namespace tags must be set by the write gateway rather than the caller.
OWASP MAESTRO Multi-Agentic Threat Modeling Guide v1.0
§RPA Expense Reimbursement Agent — Layer 2: Data Operations, T18
"T18 - RAG Input Manipulation Leading to Policy Bypass: An attacker crafts an expense claim description that, while not directly violating any policy rules, is semantically similar to examples of approved claims in the vector database that should have been rejected. This exploits the RAG system's similarity search to bypass policy checks."
Supports: Verbatim threat definition for T18 RAG Input Manipulation. Establishes that write-access to the corpus is the enabling condition: an attacker must be able to insert or influence corpus content before the similarity search can be exploited.
Does not prove: Scenario is scoped to an RPA expense-claim agent, not a general multi-agent architecture. Per-namespace write ACL is not named as a mitigation in this scenario; the T18 mitigation section names input validation rather than namespace isolation.
OWASP MAESTRO Multi-Agentic Threat Modeling Guide v1.0
§ElizaOS Blockchain Agent — Layer 2: Data Operations, T27
"T27 - Vector Database Poisoning with Malicious Smart Contract Data: An attacker injects manipulated data about malicious smart contracts into the vector database used by ElizaOS agents. This causes agents to interact with those contracts, potentially leading to financial losses or other security breaches."
Supports: Verbatim threat definition for T27. Confirms that unrestricted write access to a shared vector DB is the attack surface: namespace-scoped write ACL removes the injection capability named in the threat.
Does not prove: Scenario is specific to ElizaOS and Solana smart contracts. The listed mitigation for T27 in MAESTRO is monitoring and anomaly detection, not namespace ACL. Namespace isolation is the Helmwart-recommended structural control; MAESTRO does not prescribe it here.
Weaviate Multi-Tenancy Documentation
Weaviate docs › Manage data › Multi-tenancy — opening definition
"Multi-tenancy provides data isolation. Each tenant is stored on a separate shard. Data stored in one tenant is not visible to another tenant."
Supports: Verbatim vendor statement confirming that Weaviate's tenant primitive provides structural data isolation: data in one tenant is not visible to another. This is the Weaviate instantiation of the namespace-isolation pattern.
Does not prove: Does not address write-path ACL enforcement or the mapping of agent identity (SPIFFE/workload ID) to tenant. The isolation is a storage-level property; the authentication binding is a separate application concern.
Qdrant Multitenancy Documentation
Qdrant docs › Guides › Multitenancy — opening rationale
"When an instance is shared between multiple users, you may need to partition vectors by user. This is done so that each user can only access their own vectors and can't see the vectors of other users."
Supports: Verbatim vendor statement of the multi-tenancy rationale: partition vectors by user so each user can only access their own. Confirms the payload-based group_id partitioning pattern is purpose-built for access control on shared instances.
Does not prove: Qdrant's partition_key approach uses payload filters enforced at query time, not a separate namespace with storage isolation. Correct enforcement depends on the application layer always supplying the group_id filter; it is not automatically enforced if the filter is omitted.
MITRE ATLAS AML.M0019 — Control Access to AI Models and Data in Production
No verbatim excerpt pulled yet — open the original to verify the cited section.
Supports: Names "control access to AI models and data in production" as the mitigation category. Scoping write access to agent-owned namespaces and enforcing retrieval filters on principal identity are direct instantiations of least-privilege access to production AI data.
Does not prove: ATLAS catalogue page returned 404 during cross-check (May 2026). Description is from the Helmwart-maintained ATLAS mitigations catalogue (atlas-mitigations.ts). No verbatim excerpt from the upstream source could be verified at this time.
MITRE ATLAS AML.M0031 — Memory Hardening
No verbatim excerpt pulled yet — open the original to verify the cited section.
Supports: Names "trust boundaries and secure write paths around agent memory" as the mitigation primitive. The write-gateway pattern — enforcing namespace assignment at ingestion, not caller-supplied — is the implementation of a secure write path.
Does not prove: ATLAS catalogue page returned 404 during cross-check (May 2026). Description is from the Helmwart-maintained ATLAS mitigations catalogue (atlas-mitigations.ts). No verbatim excerpt from the upstream source could be verified at this time.