EVIDENCE TRAIL
Permission-aware vector retrieval — ACLs at the retrieval boundary
Verbatim excerpts from the upstream sources cited on the mitigation page, with what each source does and does not prove. The title is Helmwart's normalised label — the closest upstream wording is in OWASP LLM08:2025, which names "permission-aware vector and embedding stores" verbatim as the required control. Two misattributions in the MDX are flagged under "Does not prove" for the relevant entries.
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 LLM Applications v2025 — LLM08:2025 Vector and Embedding Weaknesses
§Prevention and Mitigation Strategies — Item 1 "Permission and access control"
"Implement fine-grained access controls and permission-aware vector and embedding stores. Ensure strict logical and access partitioning of datasets in the vector database to prevent unauthorized access between different classes of users or different groups."
Supports: Verbatim upstream source for the control's core requirement: permission-aware vector stores with strict logical partitioning per principal class. This is the closest upstream statement of the control as titled.
Does not prove: Does not specify which vendor primitives (namespaces, partition keys, RLS) satisfy the requirement, or give implementation guidance. Helmwart adds that layer.
OWASP Agentic AI — Threats & Mitigations v1.1
§RAG-related security — 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 within the agentic context (the document's scope). Reinforces LLM08:2025's permission-aware language in the agentic AI threat taxonomy.
Does not prove: Delegates the full RAG control definition to LLM08:2025; the agentic threats document does not independently define the control. T18, T27, T28, T49 — which the MDX cites — are not in this document; they come from the OWASP MAS Guide v1.0.
OWASP Agentic AI — Threats & Mitigations v1.1 (Playbook 2: Memory Poisoning)
§Playbook 2: Securing AI Memory & Preventing Poisoning — Step 1 (Proactive) bullet "Restrict AI memory access based on context-aware policies"
"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: Establishes that agentic memory access must be policy-governed and scoped to the current task and principal — the access-control-at-retrieval pattern this control implements.
Does not prove: Framed as memory policy rather than as a vector-store namespace primitive. Does not name specific vendor mechanisms or SQL-level controls.
OWASP Multi-Agentic System Threat Modeling Guide v1.0
No verbatim excerpt pulled yet — open the original to verify the cited section.
Supports: Upstream source for T18 (RAG Input Manipulation Leading to Policy Bypass), T27 (Vector Database Poisoning with Malicious Smart Contract Data), T28 (RAG Data Exfiltration), and T49 (Semantic Drift in Expense Policy Embeddings) — all four threats that the MDX maps to this mitigation. Per-namespace ACL at the retrieval boundary directly closes the cross-tenant retrieval path each scenario depends on.
Does not prove: The guide describes the threat scenarios; it does not prescribe per-namespace ACL as the specific mitigation. The MDX's mapping of these threats to this control is Helmwart analysis, not a direct claim in the guide. The live page did not render the detailed threat text for direct excerpt verification.
Weaviate Multi-Tenancy Documentation
Weaviate docs — Multi-tenancy overview
"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 of the isolation guarantee: separate shard per tenant, cross-tenant data not visible. Confirms the architectural primitive the MDX names as a production reference implementation.
Does not prove: Describes architectural isolation (separate shards), not a runtime ACL policy engine. Does not address how the application layer enforces that the requesting principal maps to the correct tenant.
Qdrant — Multitenancy / Multiple Partitions Documentation
Qdrant docs — Multitenancy — Partition-based access control overview
"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 per-user partitioning goal ("each user can only access their own vectors and can't see the vectors of other users") and the implementation pattern (payload filter on tenant identifier at query time).
Does not prove: The isolation is enforced by application-level filter injection, not by the database refusing unfiltered queries. If the application omits the filter, Qdrant returns all vectors. The control requires the application to enforce the filter consistently on every query path.
Pinecone — Namespaces (Glossary / Get Started)
Pinecone docs — Glossary — Namespace entry
"A namespace is a partition within an index. It divides records into separate groups so that each query scans only one namespace (faster lookups) and each customer's data can be isolated from another customer's (multitenant isolation)."
Supports: Verbatim vendor statement of the multitenant isolation guarantee for Pinecone namespaces. Confirms the production primitive the MDX names for the Pinecone implementation path.
Does not prove: Pinecone namespace routing is caller-supplied; the SDK does not enforce that the caller supplies the correct namespace. The MDX's Pinecone code snippet correctly adds a metadata ACL filter inside the namespace — that second layer is not described here.
MITRE ATLAS AML.M0019 — Control Access to AI Models and Data in Production
AML.M0019 description field — ATLAS YAML (mitre-atlas/atlas-data)
"Require users to verify their identities before accessing a production model. Require authentication for API endpoints and monitor production model queries to ensure compliance with usage policies and to prevent model misuse."
Supports: Establishes the production-environment access-control requirement (identity verification, API authentication) that per-namespace ACL implements for vector stores serving production agents.
Does not prove: Describes authentication and API-level access control generically; does not mention vector databases, namespaces, or retrieval-boundary partitioning specifically.
MITRE ATLAS AML.M0031 — Memory Hardening
AML.M0031 description field — ATLAS YAML (mitre-atlas/atlas-data)
"Memory Hardening involves developing trust boundaries and secure processes for how an AI agent stores and accesses memory and context. This may be implemented using a combination of strategies including restricting an agent's ability to store memories by requiring external authentication and validation for memory updates, performing semantic integrity checks on retrieved memories before agents execute actions, and implementing controls for monitoring of memory and remediation processes for poisoned memory."
Supports: Defines "trust boundaries" for agent memory access and explicitly names "restricting an agent's ability to store memories" and "semantic integrity checks on retrieved memories" — the per-namespace ACL is the structural mechanism that enforces these trust boundaries at the retrieval boundary.
Does not prove: Does not specifically name per-principal namespace partitioning or retrieval-side filtering as the implementation mechanism. MDX claim that AML.M0031 "names per-principal retrieval boundaries" is a reasonable but loose interpretation; the ATLAS text names trust boundaries and semantic integrity checks, not namespace-level ACL.
NIST AI 600-1 — Generative AI Risk Profile
No verbatim excerpt pulled yet — open the original to verify the cited section.
Supports: Section 2.9 Information Security names data poisoning and prompt injection as the two primary GAI information security risks, directly motivating retrieval-boundary controls. MS-2.7 (AI system security and resilience — MEASURE 2.7) names "unauthorized access attempts" and "access controls" among the metrics to measure security effectiveness.
Does not prove: MDX claims NIST AI 600-1 "names retrieval-time access control under MS-2.6." This is a misattribution. MS-2.6 evaluates safety risks and fail-safety; MS-2.7 covers security and resilience. Neither measure specifically names vector database access control or retrieval-time namespace filtering. NIST does not name the control by name anywhere in the document.