The RAG Authorization Gap: What Your Security Team Needs to Know Before AI Goes to Production

When engineering teams deploy RAG, they think about retrieval quality and latency. Security teams think about access controls and audit trails. The two perspectives rarely intersect early enough — and that gap is where AI-related security incidents happen.

Why application-layer controls do not cover retrieval

Your organization has invested in SSO, IAM, ACLs, and RBAC for every application in your stack. Those controls work at the API layer: they govern which users can call which endpoints, which resources they can modify, which records they can read. When a user opens a Jira ticket, the access control fires. When a user opens a pull request, it fires again. These controls are enforced at well-defined checkpoints in your application architecture.

A RAG pipeline does not have those checkpoints by default. When your AI assistant is asked a question, it queries a vector database and retrieves the most semantically similar chunks — regardless of who asked. The vector database performs a nearest-neighbor search. It does not know the user's department, their clearance level, or whether they are supposed to see a particular document. The application layer's access controls stopped at the API boundary. The vector database sees a query, not a principal.

The five questions your auditor will ask

A SOC 2 or EU AI Act audit of any AI system will surface these questions. First: who can your AI access? This requires principal-level enforcement — not just "employees can access the knowledge base" but "this specific user has access to these specific resources under these conditions." Second: can you prove what was retrieved? This requires retrieval-level audit logging, not application-level HTTP logs. Third: can you revoke access without a redeploy? Schema migrations and service restarts are not acceptable incident response timelines. Fourth: can you classify and gate sensitive content? "Confidential" labels in a spreadsheet that are not enforced at query time do not satisfy this requirement. Fifth: will the system fail safely? On policy evaluation error, the system must deny, not allow.

The compliance crosswalk

SOC 2 CC6.1 (logical access controls) requires that access to information assets is restricted to authorized users. For a RAG system, this means principal-level enforcement at retrieval time, not document-level enforcement at ingestion time. ISO 27001 A.8.3 (information access restriction) requires that access to information and application system functions is restricted in accordance with the access control policy — the policy must be enforced at the retrieval layer, not just stated in documentation. NIST AI RMF GOVERN-1.1 requires that AI risk management policies establish accountability — policy-as-code with version history, approval workflows, and Access Simulator dry-runs cover this requirement. EU AI Act Article 12 requires automatic logging for post-hoc traceability — you need retrieval-level logs, not application-level request logs.

What a security review should include

When reviewing a RAG deployment for security gaps, check four things. First: is there a deny-by-default enforcement layer? Any retrieval that does not have an explicit allow policy should be denied. Second: is principal identity resolved before retrieval? The query should carry a principal ID that is resolved to attributes from your IDP before any policy is evaluated. Third: is every retrieval decision logged with the policy reason? The audit log should show principal, resource, policy, decision, and timestamp — not just "query executed." Fourth: can you demonstrate instant revocation? If a principal leaves the organization, you should be able to revoke their access immediately without touching your application code.

The [security page](/security) documents Gateco's full posture, including the latency SLO (<25ms p95 policy overhead), the failure model (fail-closed by default), and the audit trail spec. The [for-security-teams page](/for-security-teams) maps to specific SOC 2, ISO 27001, NIST AI RMF, and EU AI Act controls.