{"id":174,"date":"2026-09-19T08:00:21","date_gmt":"2026-09-19T08:00:21","guid":{"rendered":"https:\/\/www.dobryakov.net\/blog\/174\/"},"modified":"2026-09-19T08:00:21","modified_gmt":"2026-09-19T08:00:21","slug":"ai-governance-access-control","status":"publish","type":"post","link":"https:\/\/www.dobryakov.net\/blog\/174\/","title":{"rendered":"Enterprise Access Control: Securing RAG with RBAC and ABAC"},"content":{"rendered":"
\n# Enterprise Access Control: Securing RAG with RBAC and ABAC\n\nAn operations clerk asks the assistant: "What were the terms on the last deal with this customer?" The assistant searches the RAG index, finds a document from the legal department, and hands it over. The clerk has no access to that document in SharePoint. They didn't hack anything; they just asked the bot, and the bot isn't a rights subject. The retriever found the most relevant hit, the model summarized it. This is how AI produces **privileged leakage**: data the person has no access to at the source flows out through the assistant anyway.\n\n<!--more-->\n\nThis is a fundamental defect of naive RAG. Indexing collapses data at different access levels into a single vector index, and semantic search doesn't know about permissions. The fix is an **identity plane**: RAG must return answers strictly within the rights the user actually has in the source systems \u2014 Confluence, Jira, SharePoint, PostgreSQL \u2014 and that must be provable.\n\n## The business goal\n\nA user gets from RAG exactly what they're allowed to see in the source systems \u2014 no more. Three promises anchor the work:\n\n1. No answer contains data the asker lacks access to at the source.\n2. Access revocation at the source propagates into RAG within minutes, not days.\n3. When a regulator or auditor asks "why did this employee see this," the answer lies in the permissions, not in the retriever's luck.\n\n## What drives the work: threat and regulator\n\n- **Confused deputy**: the AI acts under its own identity with the full permissions of the index, rather than on behalf of the user. A classic internal-leak vector.\n- **OWASP LLM**: LLM02 (Sensitive Info Disclosure), LLM06 (Excessive Agency \u2014 when RAG tools reach into systems).\n- **GDPR \/ banking secrecy**: access to PII without a legal basis is a violation even inside the company.\n- **AI Act audit**: access to high-risk data must be logged and justified.\n\n## The architectural pattern: Identity-Aware Hybrid Filtering\n\nThe 2026 enterprise-architecture consensus: don't choose between fast pre-filtering and precise authz \u2014 combine both.\n<\/code><\/pre>\n
JWT(user: groups, roles, tenant_id) \u2502 \u25bc [1] Pre-filter in the vector DB by ACL metadata (recall, cheap) \u2502  candidate chunks \u25bc [2] FGA post-check: CheckBulkPermissions against each chunk's source document \u2502  permitted chunks          (precision, ReBAC\/ABAC) \u25bc [3] LLM  \u2192  [4] OPA post-filter on the answer (field masking, forbidden combinations)<\/p>\n
<\/p>\n
\nThe pre-filter cheaply cuts out the bulk. The FGA service gives a precise check where the payload filter isn't enough \u2014 complex relationships, ABAC context. The user's rights penetrate **the retrieval itself**, rather than being layered onto the output after the fact.\n\n## Engineering stack\n\n- **Vector DB with payload filters**: Qdrant, Pinecone, PostgreSQL (pgvector).\n- **Identity**: OpenID Connect (OIDC), Keycloak; JWT with `groups`, `roles`, `tenant_id`.\n- **Fine-Grained Authorization (ReBAC\/ABAC)**: OpenFGA, SpiceDB, Cerbos, Auth0 FGA \u2014 `CheckBulkPermissions` in the retrieval path.\n- **Output-side policy**: OPA (Rego).\n- **Orchestration**: LlamaIndex \/ LangChain.\n\n## Implementation\n\n### Step 1. ACL as chunk metadata + version\n\nAt indexing time, each chunk's payload gets a normalized ACL array and an `acl_version`. The version is the key to instant invalidation.\n<\/code><\/pre>\n
payload = { "tenant_id": doc.tenant_id, "allowed_groups": doc.acl_groups,     # from the source system "source_doc_id": doc.id,              # for FGA post-check "acl_version": doc.acl_version, }<\/p>\n
\n### Step 2. Pre-filter from the JWT security context\n<\/code><\/pre>\n
flt = {"must": [ {"key": "tenant_id",     "match": {"value": user.tenant_id}}, {"key": "allowed_groups","match": {"any": user.groups}}, ]} candidates = qdrant.search(query_vec, query_filter=flt, limit=50)<\/p>\n
\n### Step 3. FGA post-check against the source\n<\/code><\/pre>\n
allowed = fga.batch_check( user=f"user:{user.id}", relation="viewer", objects=[f"doc:{c.payload['source_doc_id']}" for c in candidates], ) chunks = [c for c in candidates if allowed[c.payload["source_doc_id"]]]<\/p>\n
\n### Step 4. ACL sync \u2014 event-driven, not batch\n\nSubscribe to permission-change webhooks from the source systems; permission changes reconcile within minutes. Bump the `acl_version` \u2192 stale chunks are invalidated. A nightly batch sync is unacceptable here: a day with a revoked access still valid is a day of leakage.\n\n### Step 5. OPA at the output\n\nThe final answer and its citations pass through policy: masking of individual fields, banning dangerous combinations, redacting reference-link metadata.\n\n## Where it breaks\n\n- **ACL drift is the main risk.** Permissions change at the source, the index lags \u2192 you hand over what's already forbidden. The only fix is event-driven sync plus real-time FGA checking. Pre-filtering against the index always lags by the sync delay.\n- **Leakage through aggregation.** Chunks permitted individually reveal something forbidden in aggregate. Neither pre-filter nor FGA sees this \u2014 it needs OPA\/business-rule logic on top.\n- **Citation metadata.** Content is filtered, but the source's title or link in the answer reveals the mere existence of the document. Clean up citations too.\n- **FGA latency.** `CheckBulkPermissions` across dozens of chunks adds delay; balance pre-filter depth against post-check volume.\n- **ABAC context.** "Access only during business hours \/ only for your own region \/ only with a business justification" doesn't fit cleanly into a payload \u2014 it moves into FGA\/OPA, adding complexity.\n\n## Standards and mapping\n\n- **ISO\/IEC 42001**: access controls for AI system data and systems.\n- **EU AI Act**: Art. 10 (data governance), access logging for high-risk.\n- **OWASP LLM**: LLM02, LLM06.\n- **NIST AI RMF**: Govern\/Map \u2014 data and access control.\n\n## Lab and artifact\n\nSet up Qdrant with payload ACLs and `acl_version`, OIDC via Keycloak, pre-filter by `tenant_id`+`groups`, an OpenFGA relationship model + `batch_check` in the retrieval path, webhook-based access-revocation sync, OPA at the output. Test: two users with different permissions ask the same question from the introduction \u2014 compare the results; revoke access and measure reconciliation time. **Artifact**: FGA model + rego policies + a "role \u00d7 document \u2192 access" test matrix + a sync-lag metric.\n\n## Maturity checklist\n\n- **L1**: a single index filtered by `tenant_id`.\n- **L2**: pre-filter by groups from the JWT + FGA post-check against the source, OPA at the output.\n- **L3**: event-driven ACL sync (minutes), protection against aggregation and citation leaks, ABAC context, an audit trail for every access.\n\n## Sources\n\n- [Document-Level RBAC for RAG (2026 guide, Truto)](https:\/\/truto.one\/blog\/how-to-maintain-document-level-rbac-in-enterprise-rag-pipelines\/)\n- [Fine-Grained Authorization for RAG with OpenFGA (Auth0)](https:\/\/auth0.com\/ai\/docs\/intro\/authorization-for-rag)\n- [The Right Approach to Authorization in RAG (Oso)](https:\/\/www.osohq.com\/post\/right-approach-to-authorization-in-rag)\n- [RAG with Access Control (Pinecone)](https:\/\/www.pinecone.io\/learn\/rag-access-control\/)\n\n---\n\nIf your RAG assistant returns an answer the asker could not have seen in the source system, you have built a privilege-escalation tool with a chat interface.\n<\/code><\/pre>\n","protected":false},"excerpt":{"rendered":"
Naive RAG collapses data at different access levels into one index. Here is how to build identity-aware filtering so an employee sees through the assistant exactly what they can access in the source systems.<\/p>\n","protected":false},"author":0,"featured_media":173,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[147,155],"tags":[158,156,160,159,46,157],"class_list":["post-174","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ai-governance","category-rag-security","tag-abac","tag-access-control","tag-enterprise-architecture","tag-openfga","tag-rag","tag-rbac"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t