AI memory attack

An attacker manipulates an AI application's retrieval workflow to access documents, embeddings, or knowledge that should be restricted by user, role, tenant, department, classification, or other authorization boundaries.

RAG Access Control Bypass occurs when a Retrieval-Augmented Generation system retrieves information that the requesting user is not authorized to access.

RAG applications frequently connect language models to enterprise knowledge sources such as SharePoint, Google Drive, Confluence, file repositories, databases, support systems, CRM platforms, and internal documentation.

The presence of authentication on the AI application does not guarantee that authorization is preserved during retrieval.

A user may be correctly authenticated while the retrieval service operates using a shared service account, overly privileged application identity, broad API token, or vector database containing documents from multiple authorization domains.

An attacker can then manipulate queries, semantic searches, metadata, filters, conversation context, or retrieval behavior to cause restricted information to enter the model’s context.

The model becomes the final disclosure mechanism:

Authorized User → AI Application → Overprivileged Retriever → Restricted Document → LLM Context → Unauthorized Response

The core security principle is simple:

Retrieval must never expand a user’s effective permissions.

An attacker begins with legitimate or compromised access to a RAG-enabled application.

Direct access to a sensitive source document may be denied by the underlying enterprise system.

The attacker instead asks the AI system questions designed to retrieve information semantically related to the protected material.

If authorization filtering is absent, incorrectly implemented, or applied only after retrieval, the vector search or knowledge-retrieval layer may return chunks from restricted documents.

Those chunks enter the model context.

The attacker may not receive the complete source document. However, repeated queries can potentially expose summaries, individual passages, names, financial information, credentials, internal procedures, source code, security findings, customer information, or other sensitive material.

This creates an important distinction:

The attacker bypasses access to the document by querying the knowledge represented by the document.

1. Application Access
The attacker gains legitimate or compromised access to a RAG-enabled AI application.

2. Protected Information Identification
The attacker identifies or suspects the existence of restricted information.

3. Semantic Query Manipulation
Queries are crafted to retrieve concepts associated with the protected content without necessarily requesting the original document directly.

4. Retrieval Execution
The RAG system searches its vector database, knowledge store, or connected repository.

5. Authorization Failure
Document-level, user-level, role-level, or tenant-level authorization is not correctly applied before retrieval.

6. Restricted Context Retrieval
Chunks originating from protected content are returned.

7. Model Context Injection
The retrieved information is inserted into the model’s context.

8. Information Disclosure
The model summarizes, quotes, transforms, reasons over, or otherwise reveals protected information.

9. Iterative Extraction
The attacker modifies subsequent queries to reconstruct additional portions of the restricted knowledge.

• Enterprise RAG applications
• AI knowledge assistants
• Vector databases
• Enterprise search platforms
• SharePoint-connected AI
• Google Workspace-connected AI
• Confluence integrations
• CRM-connected assistants
• Customer-support AI
• Internal documentation systems
• AI coding assistants
• Document intelligence platforms
• Multi-tenant AI applications
• Cloud storage integrations
• Database-connected LLM applications
• Agentic RAG systems

RAG is attractive to enterprises precisely because it allows AI systems to access internal knowledge.

That also means a RAG implementation can inadvertently create a new access path around existing enterprise security controls.

An organization may spend years carefully implementing permissions in SharePoint, cloud storage, databases, document-management systems, and SaaS applications.

If the AI retrieval layer indexes all of that information under a broadly privileged identity and fails to reproduce those permissions correctly, the AI interface can effectively flatten those security boundaries.

The result may expose:

• Intellectual property
• Customer information
• Legal documents
• HR information
• Financial records
• Executive communications
• Security findings
• Source code
• Credentials and secrets
• M&A information
• Regulated data

For enterprise AI testing, the central question is:

Does your AI system know more than the person asking it the question is authorized to know?

That should be a standard test in any serious RAG security assessment.

Authorized testing should verify that retrieval authorization is at least as restrictive as source-system authorization.

Testing should include:

• Cross-user document retrieval
• Cross-role retrieval
• Cross-department retrieval
• Cross-tenant retrieval
• Restricted-document semantic searches
• Queries using partial document information
• Queries based on employee names or project names
• Metadata-filter manipulation
• Direct vector-store queries where exposed
• Retrieval using alternate phrasing
• Multi-turn extraction attempts
• Summarization of inaccessible documents
• Questions designed to reconstruct document sections
• Retrieval through related-document relationships
• Authorization after role changes
• Retrieval after access revocation
• Cached restricted content
• Deleted-document persistence
• Embeddings generated before permissions changed
• Retrieval through an AI agent rather than the primary UI

A critical test is:

If User A cannot open Document X in the source system, can User A’s AI assistant answer questions using information from Document X?

If yes, the RAG implementation has created an authorization bypass.

Monitor for:

• Repeated semantic queries targeting restricted topics
• Retrieval of documents outside the user’s authorization scope
• Cross-tenant retrieval activity
• RAG results inconsistent with source-system permissions
• High-volume iterative questioning
• Users querying known restricted projects
• Retrieval-service identities accessing unusually broad datasets
• Restricted document IDs appearing in AI context logs
• Metadata-filter manipulation
• AI responses containing sensitive classifications
• Access to revoked or deleted documents
• Unusual vector database queries
• Retrieval without corresponding source-system authorization checks
• Users accessing information through AI that they have never accessed directly

RAG Access Control Bypass does not correspond to one single ATT&CK technique because the primary weakness exists in the application's retrieval and authorization architecture. Depending on the resulting access, relevant techniques can include: T1213 — Data from Information Repositories T1530 — Data from Cloud Storage T1555 — Credentials from Password Stores T1114 — Email Collection T1005 — Data from Local System T1078 — Valid Accounts The mapping should reflect the information source actually reached through the vulnerable RAG system.

OWASP Mapping Strongly related to: OWASP LLM02 — Sensitive Information Disclosure OWASP LLM08 — Vector and Embedding Weaknesses OWASP LLM01 — Prompt Injection, when injection is used to manipulate retrieval behavior Agentic implementations may introduce additional authorization and excessive-agency risks when an AI agent performs retrieval on the user's behalf.