Enterprise RAG security starts with retrieval permissions

An employee asks a harmless question. The assistant retrieves a confidential acquisition memo because its wording resembles the query. A final-answer filter removes the company name, but the model has already processed the document, the trace may contain it and a follow-up could reveal the substance.

The security boundary failed before generation.

For enterprise RAG, the core rule is simple: a user must not retrieve evidence they could not access in the source system. Enforce that rule before content enters the model context.

Retrieval is an authorisation decision

Search relevance asks, “Which passages match?” Secure retrieval asks two questions in order:

1. Which passages is this identity allowed to access now?
2. Of those passages, which are relevant?

Post-generation redaction is not a substitute. Neither is asking the model to ignore sensitive text. Authorisation must be deterministic and outside the model.

The application needs a trusted user identity, current group or role information, document-level policy and a retrieval mechanism capable of enforcing it. If the source uses item-level permissions, flattening content into an index without that policy loses the boundary.

Choose an isolation model deliberately

Common patterns include:

• separate indexes or collections per tenant or high-sensitivity domain;
• security-filtered retrieval using access-control metadata;
• a broker that queries source systems under the user's identity; and
• hybrid designs, with hard physical separation for the highest-risk data and filters elsewhere.

Physical separation is easier to reason about but can increase cost and operational overhead. Metadata filtering is flexible but depends on flawless propagation, query enforcement and testing. Live source queries preserve current permissions but may add latency and connector dependency.

The right design follows the threat model, not fashion.

Permission metadata has a lifecycle

Capturing an access-control list during the first index is not enough. People join, leave and change roles. Groups nest. Files move. Links become restricted. Legal holds and investigations alter access.

Define:

• how identities map between application and source;
• whether access is user-, group-, role- or attribute-based;
• how nested and external groups are resolved;
• permission-update and revocation latency;
• behaviour when the identity or policy service is unavailable;
• reindexing and tombstone semantics; and
• audit evidence for the policy applied to each retrieval.

Fail closed when authorisation cannot be established. A more helpful answer is not worth an unauthorised disclosure.

Tenant isolation is more than a metadata field

Multi-tenant systems must defend against missing filters, malformed queries, cache collisions and operational mistakes. Bind tenant context server-side from authenticated identity; never trust a tenant identifier supplied only by the prompt or browser.

Include isolation in every layer:

• connector credentials and ingestion jobs;
• storage namespaces and encryption keys where appropriate;
• retrieval filters and indexes;
• caches, traces and evaluation datasets;
• tool calls and generated links; and
• support and administrative access.

Test that removing a filter cannot happen through an alternate code path.

Retrieved content is untrusted input

OWASP's RAG security guidance highlights that external documents can contain instructions designed to manipulate the model. A poisoned page might tell the assistant to ignore policy, reveal other context or call a tool.

Treat retrieved text as data, not authority. Separate system instructions from content, constrain tools with least privilege, validate tool arguments and restrict egress. Sanitize unsupported active content, monitor source provenance and create tests for indirect prompt injection.

Access permission does not imply instructional trust. An authorised user can still upload a malicious document.

Citations, logs and caches can leak too

A secure answer can still expose a confidential title in a citation. A trace can store the complete prompt and retrieved passages. Shared semantic caches can return an answer generated under another user's permissions.

Apply the same data classification to:

• prompts and conversation history;
• retrieved chunks;
• generated answers and citations;
• embeddings and index metadata;
• application, model and tool traces;
• feedback and evaluation datasets; and
• cache entries.

Minimise capture, encrypt appropriately, restrict operators, define retention and make deletion achievable. Observability is necessary, but unlimited logging is not governance.

Test denial, not only success

Most RAG evaluations ask whether the correct document was found. Security evaluation must ask whether prohibited content stayed unreachable.

Build adversarial cases covering:

• a user without access asking an exact question from a restricted file;
• two tenants with nearly identical documents;
• revoked access before and after index refresh;
• confidential titles or snippets in citations;
• direct and indirect prompt injection;
• encoded or obfuscated requests;
• alternate search, export and conversation-history paths;
• cache reuse across roles; and
• administrator and support workflows.

Red-team high-impact use cases before launch and after changes to connectors, identity, retrieval or tools.

Operating ownership

Security cannot own the system alone. Source owners define access intent. Identity teams provide reliable principals and groups. Data and AI engineers propagate and enforce policy. Product owners define acceptable use. Privacy and legal govern purpose, retention and regulated data. Operations detect and respond.

Create one accountable service owner and explicit veto points for security and data risk. Maintain an inventory of sources, models, tools and destinations. Give users a way to report unsafe retrieval and revoke compromised collections quickly.

What to measure

• unauthorised retrieval rate in negative tests—target zero;
• permission-change and deletion propagation time;
• sources indexed without an accountable owner;
• retrievals lacking policy-decision evidence;
• cross-tenant cache or trace test failures;
• prompt-injection test pass rate;
• sensitive data retained beyond policy; and
• time to contain a retrieval-security incident.

The counterargument: strict controls will make search worse

They can increase complexity and reduce the amount of content available. That is the correct trade when the alternative is unauthorised disclosure.

Improve usefulness inside the permitted set: better metadata, source ownership, clearer denial messages and a request-access path. Do not silently broaden access to improve answer quality.

For low-risk public knowledge, a simpler design may be enough. Security should be proportional, but the classification must be explicit.

Adovo’s view

An enterprise assistant earns trust by knowing what it must not know for the person asking. The model is not the policy engine, and redaction is not authorisation.

Secure retrieval is not a feature added after a successful pilot. It is the architecture.

Primary documentation and further reading

• Azure AI Search document-level access control
• NIST AI Risk Management Framework