Retrieval-augmented generation can make enterprise AI useful because it connects models to current internal knowledge. It can also become a data-leakage path if retrieval ignores the permissions that exist in source systems. The core principle is simple: the model should never receive a document the user was not allowed to retrieve in the first place.

Enforce permissions before generation

Do not rely on the language model to decide whether information is sensitive. Access control belongs in the retrieval layer, before passages enter the prompt. Map identity consistently. The RAG service needs a reliable mapping between the user, groups, roles and source-system identities. If permissions are copied into a separate index, changes must propagate quickly enough to avoid stale access.

Store access metadata with chunks. When documents are split into chunks, authorization metadata must travel with them. A chunk without ACL context can be retrieved independently of the original file.

Filter during vector search. Permission filtering should be part of the search query rather than a cleanup step after top results are returned. Post-filtering can reduce retrieval quality and may expose metadata in intermediate systems.

Watch caches carefully

Response and retrieval caches can cross user boundaries. Cache keys should include authorization context so one user’s result cannot be reused for another without access. Audit the retrieval path. Log who asked, which documents were considered, which were retrieved and what policy allowed access. These logs support incident review and permission debugging.

Least privilege applies to agents too. If an AI agent retrieves data and then acts, tool permissions should also be scoped. This extends least-privilege AI agent design.

Separate highly sensitive indexes. Some datasets deserve architectural separation rather than only metadata filters. Isolation reduces blast radius and can simplify auditing.

Test adversarial permission cases

Include overlapping roles, recently revoked access, inherited permissions and renamed groups. Security bugs often appear at permission edges. Permission-aware RAG is a systems problem. Secure retrieval depends on identity, indexing, authorization, caching and observability working together. Treating it as prompt engineering creates a false sense of safety.

Make capability boundaries machine-enforceable. Natural-language tool descriptions help the model choose actions, but security requires deterministic enforcement. Define allowed operations, resource scope, argument constraints and required approval in a policy layer that executes before the tool call.

This separation prevents a persuasive model output from expanding its own authority. The application can reject an unsafe action even when the model is highly confident.

Prefer short-lived access over standing secrets

Agents often need access for only a small part of a workflow. Issuing scoped credentials that expire automatically reduces the impact of leaks and simplifies offboarding after the task completes. Credential lifetime should match workflow lifetime, and refresh should require the same policy checks as the original grant.

Track security-relevant events explicitly. Logs should capture permission denials, privilege changes, approval grants, credential issuance and external side effects. These events are more useful for investigation than storing every token of ordinary model reasoning.

Alerts can focus on unusual patterns such as repeated denied actions, cross-resource attempts or operations occurring after expected workflow completion.

Exercise revocation as part of normal testing

Teams should verify that disabling a user, tool or credential prevents queued and retried work from succeeding later. Revocation propagation is a distributed-systems problem and needs the same end-to-end testing as successful access. Separate identity, policy and credential.

A robust security model answers three different questions: who is acting, what that identity is allowed to do and which credential proves the permission to the downstream service. Combining these layers into one long-lived token makes auditing and revocation unnecessarily difficult. Keeping them separate allows the application to change policy without reissuing every identity and to issue narrow credentials only when an allowed action is ready to execute.

Constrain the arguments, not just the tool name

Permission to use a tool should not imply permission to use every possible argument. Validate destination, amount, path, environment and other high-impact fields before execution. For sensitive operations, compare the final arguments with the user-approved intent so a later model turn cannot silently widen the action after approval.

Separate identity, policy and credential

A robust system answers three questions independently: who is acting, what that identity is allowed to do and which credential proves the permission downstream. Combining all three in one broad long-lived token makes auditing and revocation difficult.

Separation lets policy change without reissuing every identity and enables narrow credentials only when an approved action is ready to execute.

Validate sensitive arguments

Permission to call a tool should not imply permission for every destination, path or amount. High-impact arguments should be checked against current policy and the user-approved intent before execution.

This protects the action boundary even if the model later changes its plan.