Data, RAG, and Memory Security

8.1 Data Classification and Access Control

Define and enforce a simple classification scheme:

• Public - No restrictions on access or processing.
• Internal - Available to authenticated users within the organization.
• Confidential - Restricted to specific roles, departments, or teams.
• Regulated - Subject to GDPR, HIPAA, PCI, or local data-protection laws.

For each classification level, define: who can access it (roles, departments, tenants), where it may be processed (on-prem or specific regions), and how long it may be retained.

Implementation

• Record-level and document-level filters - Always attach tenant and user context to queries. Enforce filters server-side. Never trust the client or the model to self-filter.
• Avoid cross-tenant RAG indices when possible. If you must share an index across tenants, enforce tenant filters in the query and re-check results in code before returning them.

8.2 RAG Integrity and Indirect Prompt Injection (XPIA) Defenses

RAG content is a persistent indirect prompt injection vector. When agents retrieve and process documents, those documents can contain malicious instructions that hijack agent behavior. Hardening both ingestion and retrieval is critical.

Ingestion Controls

• Restrict who can edit high-impact corpora (e.g., configuration docs, policy documents).
• Require approvals for content that is heavily used by agents and for regulated or sensitive documents.
• Log and review changes to key sources.
• Optionally: hash and sign critical documents, verify signatures at retrieval time, and maintain versions with rollback capability.

Retrieval Controls

• Apply row-level and document-level access controls. Only retrieve documents the current user is allowed to see.
• Limit the number of retrieved documents and the maximum size per document.
• Tag documents with: tenant, classification, origin, last editor, and last review date.

In Prompt Construction

• Explicitly separate untrusted RAG snippets from system instructions.
• Label retrieved content as untrusted context, and instruct the model not to follow instructions found within it.

8.3 Memory Tiers and Poisoning Defenses

Not all agent memory is the same. Define clear tiers with different security treatments:

1. Session Memory - Lives for a single conversation or short task. Cleared after completion or a short timeout.
2. Short-Term Memory - Spans multiple sessions (hours to days) for continuity. Auto-expiring and limited in size.
3. Long-Term Memory / Knowledge - RAG collections, user profiles, configuration. Curated, versioned, and usually human-reviewed.

Promotion Rules

• Only promote data to long-term memory if the source is trusted or the data passes validation workflows (consistency checks, approvals).
• For high-impact information like policy or configuration changes, require manual review before promotion.

Poisoning Detection

• Monitor agent behavior over time. Sudden shifts in tone, recommendations, or policy interpretations may indicate knowledge base poisoning.
• Keep snapshots of important memory sets so you can diff changes and roll back when needed.

8.4 PII, Secrets, and Retention

PII and secrets must not be casually fed into third-party models or stored in long-term memory without controls.

PII and Secrets Detection

• Use detectors to find PII, PHI, financial data, and secrets in prompts, logs, and RAG ingestion streams.
• Redact or tokenize as required by policy.

Data Minimization for Models

• For third-party LLMs: avoid sending raw identifiers (names, IDs). Use pseudonyms or tokens where possible.
• Turn off training and retention features, or use dedicated non-training endpoints.

Retention and Deletion

• Set different retention periods per data type and classification.
• Support deletion and erasure requests (e.g., GDPR/CCPA) by deleting or anonymizing chat logs, embeddings, and related artifacts.
• Ensure logs maintain their security value while minimizing personal data.

8.5 Database Mediation

Agents should not have raw SQL access. Full stop.

Introduce a database mediation layer that:

• Exposes safe, domain-specific operations as tools - get_sales_summary, find_customer_by_name - instead of generic query access.
• Uses parameterized queries only. No string concatenation. No dynamic SQL built from model output.
• Enforces limits on rows returned, query complexity, and request frequency and volume.

For analytical agents that need broader data access, consider pre-aggregated data marts or database views rather than direct access to transactional tables. Give the agent the answers, not the keys to the warehouse.