Controlul accesului în RAG: cine ce are voie să vadă

Un sistem RAG care răspunde corect nu e același lucru cu un sistem RAG care răspunde corect fiecărui utilizator. Prima proprietate ține de retrieval. A doua ține de autorizare — și se rupe complet altfel.

Controlul accesului în RAG e a doua proprietate, iar diferența apare în momentul în care al doilea om pune aceeași întrebare. Dacă răspunsul e identic indiferent cine întreabă, sistemul are exact o audiență: toată lumea. Într-un intranet care conține contracte, evaluări de performanță, grile salariale și dosare de client, asta nu mai e o scăpare de configurare. E o breșă cu nume și dată. Cazul în care se vede cel mai repede e helpdesk-ul intern de IT și HR, unde cel care întreabă e un angajat, nu un client.

Decizia arhitecturală — unde stă granița de autorizare — e luată deja în arhitectura unui sistem RAG. De acolo pornește textul de față, spre implementare: cum arată filtrul concret în fiecare motor, ce faci cu ACL-uri care nu încap într-un câmp de metadate, ce se întâmplă când cineva pierde un drept după ce documentul a fost deja indexat și pe unde scapă informația chiar și atunci când retrieval-ul a filtrat corect.

Modelul de amenințare: cine vede ce nu ar trebui și pe ce cale

Înainte de orice filtru, ai nevoie de lista căilor pe care informația poate ieși. Fără ea ajungi să aperi o singură ușă și să lași trei deschise.

Cele patru căi

Retrieval necontrolat. Interogarea vectorială rulează fără nicio noțiune de identitate. Similaritatea semantică nu știe ce e un ACL — găsește documentul cel mai apropiat de întrebare, indiferent cui îi aparține. Asta e cazul de bază și cel mai ușor de reprodus.

ACL învechit. Filtrul există, dar valoarea după care filtrează a fost copiată din sistemul-sursă acum două săptămâni. Între timp omul a schimbat echipa. Filtrul funcționează perfect — pe o realitate care nu mai există.

Izolare ratată între tenanți. Doi clienți în același index, separați printr-un câmp de metadate pe care o interogare îl uită. Nu e nevoie de atac: e suficient un cod care construiește filtrul în trei locuri și îl uită într-unul.

Scurgere prin răspuns. Retrieval-ul a filtrat impecabil, dar modelul citează un titlu de fișier revelator, sau sintetizează din trei fragmente permise o concluzie pe care omul nu avea dreptul să o afle. Ultima cale e și cea mai greu de testat.

Deputatul confuz

Cercetătorii de la Spark Research Lab (University of Texas at Austin) au descris atacul ConfusedPilot pe sisteme RAG comerciale exact în acești termeni: sistemul devine un confused deputy — un intermediar care acționează cu propriile privilegii, nu cu ale celui care întreabă. Documentele retrase sunt tratate ca instrucțiuni, iar rezultatul e că sistemul poate ajunge să prezinte conținut pe care utilizatorul nu ar fi trebuit să îl vadă, ori conținut vechi despre care crede că a fost șters.

Consecința practică: nu poți trata pipeline-ul de retrieval ca pe un serviciu de încredere care rulează „în numele aplicației”. Rulează în numele unui om anume, iar identitatea aceea trebuie să ajungă până la interogare, nu să se oprească la login.

Ce nu intră aici

Conformitatea — temei legal, date cu caracter personal, transferuri — e un subiect separat și e tratată în RAG și GDPR. Textul de față se ocupă strict de autorizarea tehnică: mecanismul care decide, la fiecare interogare, ce fragmente au voie să intre în context. Poți fi perfect conform și complet vulnerabil la scurgeri interne. Sunt două probleme diferite, cu două soluții diferite.

Pre-filter și post-filter: aceeași decizie, implementări diferite

Alegerea principială e făcută: filtrezi înainte de căutarea vectorială, nu după. OWASP formulează motivul într-un mod util — filtrarea de dinainte de retrieval e mai sigură pentru că nu lasă scorurile de similaritate ale documentelor restricționate să fie observate deloc.

Rămâne partea grea: ce înseamnă „înainte” în motorul pe care îl folosești.

De ce post-filter strică recall-ul

Post-filter înseamnă: caută top-k, apoi aruncă ce nu e permis. Problema nu e de securitate, e de utilitate — și e cuantificabilă.

Documentația pgvector dă exemplul canonic: cu un index HNSW și hnsw.ef_search la valoarea implicită de 40, dacă o condiție de filtrare se potrivește pe 10% din rânduri, în medie doar 4 rânduri trec filtrul. Ceri 10 fragmente, primești 4. Modelul primește un context sărac și răspunde prost — nu pentru că retrieval-ul e slab, ci pentru că filtrul de securitate a mâncat rezultatele după ce indexul deja decisese.

Cu cât permisiunile sunt mai restrictive, cu atât e mai rău. Un utilizator care are acces la 2% din corpus obține, cu post-filter pur, aproape nimic.

Ce înseamnă „pre-filter” în fiecare motor

Aici e capcana: termenul e același, mecanica nu. Un motor care „suportă pre-filtering” poate face oricare dintre:

• Filtrare la nivel de partiție — interogarea nu atinge deloc datele altui tenant, pentru că merge într-un namespace sau o colecție separată. Cea mai puternică garanție.
• Filtrare integrată în graf — indexul ANN e construit cu muchii suplimentare care țin cont de câmpul de filtrare, deci traversarea rămâne eficientă chiar și pe filtre selective.
• Filtrare iterativă — indexul e scanat repetat, în loturi, până când destule rânduri trec condiția. E, tehnic, tot post-filtrare, doar cu buclă de recuperare.

Prima variantă e o graniță. Celelalte două sunt optimizări de recall care se aplică după ce indexul a văzut deja datele. Diferența contează când auditorul întreabă ce garantează sistemul, nu ce optimizează.

Când post-filter rămâne necesar

Nu îl elimini de tot. Îl păstrezi ca a doua plasă, în trei situații:

1. ACL-ul nu încape în filtru — regula reală e prea complexă pentru limbajul de filtrare al motorului (vezi secțiunea următoare).
2. Permisiunile se schimbă mai des decât reindexezi — o verificare finală pe sursa de adevăr prinde revocările proaspete.
3. Vrei defense in depth — filtrul pre-retrieval e o linie de cod care poate fi uitată la un refactor; verificarea de la ieșire e independentă de ea.

Combinația funcționează: pre-filter pentru garanție și recall, post-filter pentru prospețime și redundanță.

Controlul accesului per motor: cum arată filtrul concret

Alegerea bazei vectoriale schimbă mecanica autorizării mai mult decât schimbă performanța. Comparația generală de capabilități e în pgvector vs Pinecone vs Qdrant vs Weaviate; aici contează exclusiv unghiul de acces.

pgvector: autorizarea și retrieval-ul în același plan de execuție

Avantajul e structural. Vectorii stau în aceeași bază cu restul datelor, deci politica de acces poate fi exprimată în Postgres — row-level security, view-uri, join pe tabela de permisiuni — și devine parte din planul de execuție. Baza nu returnează rânduri neautorizate, punct.

Prețul e recall-ul. pgvector parcurge graful HNSW și abia apoi aplică filtrul; dacă tenant_id se potrivește pe o fracțiune mică din rânduri, candidații returnați pot cădea toți la filtrare. Versiunea 0.8 a introdus scanarea iterativă (hnsw.iterative_scan, ivfflat.iterative_scan), care continuă să scaneze indexul până când trec destule rânduri sau se atinge o limită. Nu e activă implicit — o setezi pe sesiune sau tranzacție — și costă CPU și latență de coadă.

Qdrant: filtrul intră în structura indexului

Qdrant tratează multi-tenancy ca pe un caz de partiționare logică într-o singură colecție, cu un index de payload marcat is_tenant=true. Combinația recomandată în documentație — payload_m diferit de zero (de exemplu 16) și m=0 — dezactivează graful HNSW global și construiește sub-grafuri per tenant, astfel încât traversarea nu mai vizitează noduri ale altor tenanți doar ca să le arunce ulterior.

Două detalii care produc incidente:

• Indexul de payload trebuie creat înainte de ingestia datelor. Creat după, indexul HNSW trebuie reconstruit ca să beneficieze de muchiile filtrabile.
• Documentația descurajează explicit o colecție per tenant. În Qdrant Cloud numărul de colecții per cluster e plafonat la 1000, iar un cluster cu mii de colecții devine instabil înainte de a atinge plafonul.

Pentru filtre cu selectivitate slabă pe mai multe câmpuri, versiunea 1.16 a adăugat algoritmul ACORN, activabil per interogare — util, dar cu overhead, deci nu ceva ce pornești global.

Pinecone: namespace-ul ca graniță

Modelul recomandat pentru multi-tenancy e un namespace per tenant, iar orice operație de date țintește un singur namespace. Asta face granița mai greu de ratat din cod: nu există interogare care să atingă accidental doi tenanți.

Există și o consecință de cost pe care merită să o știi înainte de a alege filtrul pe metadate: documentația Pinecone arată că interogarea unui namespace de 1 GB dintr-un set de 100 de tenanți costă 1 RU, în timp ce filtrarea după metadate într-un singur namespace de 100 GB costă 100 RU pentru aceeași interogare — pentru că scanarea acoperă toate datele, indiferent de filtru. Offboarding-ul e la fel de tranșant: ștergi namespace-ul.

Limita e simetrică: dacă ai nevoie de căutare transversală (un administrator care caută peste toți tenanții), namespace-urile nu îți dau asta și ajungi să compui rezultate din mai multe interogări.

Azure AI Search: două modele, una simulată

Documentația Microsoft e neobișnuit de directă: security trimming e o simulare de autorizare la nivel de document. Un câmp filtrabil de tip colecție de string-uri conține identitățile permise, iar interogarea aplică un filtru OData. Nu există autentificare pe principal — e comparație de string-uri.

Modelul mai nou, permission filters, transmite un token de utilizator sau grup într-un header dedicat, iar serviciul construiește automat filtrele de securitate din permisiunile respective, adăugându-le peste orice alt filtru al interogării.

Detaliul care merită pus într-un runbook: dacă un element depășește limitele de intrări ACL, permisiunile de peste limită pot să nu fie aplicate la interogare. E exact tipul de eșec silențios care nu apare în teste — până când apare într-un audit.

ACL-uri care nu încap într-un câmp de metadate

Modelul simplu — o listă de identificatori de grup pe fiecare chunk — funcționează până la un punct. Punctul e mai apropiat decât pare.

Unde se rupe lista de principali

Microsoft descrie limita fără menajamente: o filtrare construită ca disjuncție de egalități e predispusă la erori, greu de întreținut, iar când lista conține sute sau mii de valori încetinește răspunsul cu multe secunde. Iar peste limitele de intrări ACL, aplicarea devine parțială.

În practică ajungi acolo repede. Un document dintr-un ERP poate fi vizibil pentru: proprietar, echipa lui, managerul echipei, doi auditori externi, un grup de conformitate și oricine are rolul „citire contracte” în regiunea respectivă. Denormalizat, asta înseamnă sute de identificatori pe un singur chunk, recalculați la fiecare schimbare de organigramă.

Mai rău: regulile reale nu sunt liste, sunt relații. „Managerul autorului poate citi” nu e o valoare, e o traversare de graf.

Motor de autorizare extern

Când regula nu încape în filtru, o scoți din index și o pui într-un serviciu dedicat de autorizare fine-grained — SpiceDB, OpenFGA, Cerbos și alte implementări de ReBAC/ABAC. Modelul de integrare are exact două forme, care corespund celor două strategii de mai sus:

• Pre-filter: întrebi motorul de autorizare ce resurse poate vedea utilizatorul (lookupResources în terminologia SpiceDB), apoi trimiți lista ca filtru către baza vectorială.
• Post-filter: rulezi căutarea, apoi verifici fiecare identificator returnat (checkPermission, ideal în variantă bulk, ca să nu faci N apeluri).

Compromisul e documentat de furnizori: interogarea care enumeră resursele e mai costisitoare decât o verificare punctuală, deci pre-filter e mai eficient când rata de potrivire e mică (corpus mare, utilizator cu acces îngust), iar post-filter e mai eficient când utilizatorul are acces la aproape tot.

Pragul real depinde de datele tale. Măsoară-l, nu-l presupune.

Ce denormalizezi și ce evaluezi la interogare

Regula practică: denormalizează ce se schimbă rar, evaluează la interogare ce se schimbă des.

Clasificarea documentului („confidențial”, „intern”, „public”) și apartenența lui la o unitate organizațională se schimbă rar — merg în metadate, alături de access_scope din schema minimă descrisă în pregătirea documentelor pentru RAG. Apartenența omului la grupuri se schimbă des — se rezolvă la interogare, din tokenul de sesiune sau din furnizorul de identitate.

Inversarea acestei reguli e sursa cea mai frecventă de ACL-uri învechite: cineva materializează lista de utilizatori pe fiecare chunk „ca să fie rapid” și își cumpără o problemă de sincronizare pe viață.

Revocarea: evenimentul fără mecanism

Aici e golul pe care majoritatea arhitecturilor nu îl acoperă, pentru că nu seamănă cu nimic din ce au deja.

De ce prospețimea nu prinde revocarea

Când un document e șters sau modificat, semnalul vine din conținut și există mecanisme care îl propagă — le tratează prospețimea, ștergerile și reindexarea. Când o permisiune e revocată, documentul rămâne valid. Textul e neschimbat, hash-ul e identic, data ultimei modificări nu se mișcă. Se restrânge doar audiența lui.

Niciun mecanism de prospețime nu prinde asta, pentru că semnalul nu e în sistemul de conținut, ci în cel de identitate. Un crawler care detectează modificări de documente va trece pe lângă revocare de fiecare dată.

Fereastra de expunere

Între momentul revocării în sistemul-sursă și momentul în care indexul reflectă schimbarea există o fereastră. Mărimea ei e o proprietate a sistemului tău, nu un detaliu.

Merită spus limpede că nici furnizorii mari nu o comunică ca angajament: Microsoft nu publică un SLA de reindexare după schimbarea permisiunilor, iar cifrele care circulă în materialele de consultanță pe tema Copilot și SharePoint variază între surse — motiv suficient să nu construiești pe ele. Ce poți face e să măsori fereastra la tine: revoci un drept într-un mediu de test și cronometrezi până când interogarea nu mai returnează documentul.

Trei tipare care închid fereastra

Verificare la interogare pe apartenență. Filtrezi pe grupuri, nu pe utilizatori, iar apartenența la grup se citește la fiecare interogare din furnizorul de identitate. Revocarea în IdP devine efectivă imediat, fără să atingi indexul.

TTL pe ACL-ul denormalizat. Dacă totuși materializezi permisiuni în metadate, pui un timestamp și refuzi să servești fragmente cu ACL mai vechi decât pragul acceptat. Degradezi disponibilitatea în loc să degradezi securitatea.

Invalidare push din sistemul de identitate. Un webhook la schimbarea unui grup declanșează invalidarea țintită a chunk-urilor afectate. Cel mai rapid și cel mai fragil — un webhook pierdut trece neobservat, deci are nevoie de reconciliere periodică oricum.

Alegerea nu e liberă: dacă modelul tău de amenințare include un angajat plecat în aceeași zi, verificarea la interogare e singura care ține.

Izolarea multi-tenant: storage, namespace sau filtru

Tenant nu înseamnă neapărat client. Într-un sistem intern, „tenantul” poate fi departamentul, nivelul de clasificare sau regiunea juridică. Mecanica e aceeași; miza diferă.

Trei niveluri, trei garanții

OWASP recomandă explicit namespace-uri, colecții sau indexuri separate per tenant sau nivel de clasificare, tocmai pentru că filtrul partajat mută garanția în codul aplicației. Iar LLM08:2025 din Top 10-ul pentru aplicații LLM listează lipsa izolării între tenanți ca risc de sine stătător.

Costul izolării dure

Izolarea prin indexuri dedicate nu e gratuită și nu scalează liniar. Un raport tehnic pe tema controlului de acces bazat pe roluri în baze vectoriale (HONEYBEE, arXiv 2025) măsoară costul: partiționarea pe roluri — nu chiar pe utilizatori individuali — a produs în experimentele autorilor un overhead de stocare de circa 27× față de un index unificat, pentru că vectorii accesibili mai multor roluri se duplică în fiecare partiție.

Concluzia practică nu e „nu izola”, ci: alege granularitatea izolării dure la nivelul la care ai chiar granițe de încredere — client, jurisdicție, nivel de clasificare — și rezolvă restul cu filtre în interiorul partiției.

Când modelul nu se mapează curat

Documentele partajate între tenanți (politici comune, documentație de produs) sparg schema „un vector, un tenant”. Două soluții uzuale: duplici documentul comun în fiecare partiție (simplu, scump la actualizare) sau ții o partiție „comună” pe care fiecare interogare o atinge suplimentar și îi combini rezultatele. A doua e mai curată, dar înseamnă două căutări și o reunificare a scorurilor — cu efectele pe care le are orice fuziune de liste de rezultate.

Scurgerea prin răspuns, chiar când retrieval-ul a filtrat corect

Ultima cale e cea care trece de toate testele automate, pentru că nu implică niciun fragment neautorizat.

Citarea care trădează

Un răspuns cu citări bine făcute — practica descrisă în reducerea halucinațiilor prin grounding și citare — expune metadate: titluri de fișiere, căi, nume de proiecte, denumiri de clienți. Plan_restructurare_Q4_Divizia_Nord.docx spune destul chiar dacă nimeni nu îl deschide.

Regula: metadatele afișate în citare trec prin același filtru ca și conținutul. Dacă nu ai voie să vezi documentul, nu ai voie să vezi nici că există.

Sinteza peste fragmente permise

Trei fapte permise separat pot compune un fapt nepermis. Grila salarială pe roluri, organigrama și bugetul unei echipe sunt, fiecare, informații pe care mulți angajați au dreptul să le vadă. Împreună, dau salariul unei persoane.

E o problemă veche de agregare, dar RAG o accelerează: modelul face compunerea automat, competent, într-un răspuns care sună legitim. Nu există filtru de retrieval care să o prindă, pentru că fiecare fragment în parte e autorizat. Controlul trebuie să existe la nivel de politică — ce combinații de surse nu au voie să apară în același context — sau la ieșire.

Canale laterale

Trei detalii mici care spun mai mult decât par:

• Scorurile de similaritate. Motivul pentru care OWASP preferă filtrarea de dinainte de retrieval: cu post-filtrare, scorurile documentelor restricționate au fost deja calculate și pot deveni observabile.
• Diferența dintre „nu există” și „nu ai voie”. Dacă răspunsul e formulat diferit în cele două cazuri, ai construit un oracol de existență. Un mesaj identic pentru ambele situații e alegerea corectă.
• Embedding-urile în sine. OWASP notează în LLM08:2025 că embedding-urile nu sunt nici anonimizate, nici ireversibile: atacurile de inversiune pot recupera porțiuni semnificative din textul original. Un index vectorial e un depozit de date sensibile, nu un artefact derivat inofensiv.

Ce loghezi ca să poți face audit

Un control de acces pe care nu îl poți demonstra ulterior nu îți folosește la nimic în ziua în care cineva întreabă ce a văzut un anumit utilizator.

Evenimentul minim

Pentru fiecare interogare, înregistrează: identitatea apelantului, momentul, textul întrebării (sau un hash, dacă întrebările în sine sunt sensibile), filtrul de securitate efectiv aplicat, identificatorii fragmentelor candidate, identificatorii fragmentelor care au trecut filtrul și cele care au ajuns efectiv în context.

Câmpul care lipsește aproape întotdeauna e al treilea. Fără filtrul aplicat nu poți reconstitui de ce un fragment a trecut, doar că a trecut — și tocmai reconstituirea e obiectul auditului. Când urma asta devine ea însăși dovadă într-un dosar, cerințele se schimbă încă o dată — vezi RAG pentru conformitate și audit intern.

Ce nu loghezi

Nu conținutul fragmentelor în clar. Un log de retrieval care stochează textul devine o a doua copie a bazei de cunoștințe, de obicei cu permisiuni mai laxe decât indexul și cu retenție mai lungă. Identificatori și hash-uri, da; text, nu.

La fel, atenție la telemetria trimisă către servicii externe de observabilitate: prompturile complete conțin fragmentele retrase, deci pleacă din perimetru împreună cu ele.

Testul care prinde regresiile

Suita minimă e o matrice de perechi utilizator × document, cu rezultatul așteptat pentru fiecare: vizibil sau nu. O rulezi la fiecare schimbare de schemă, de motor sau de logică de filtrare. Adaugă în ea, obligatoriu, cazurile care au produs deja incidente.

Fără testul ăsta, o schimbare de câmp de payload sau o rescriere de interogare poate deschide accesul fără să spargă niciun test funcțional — sistemul continuă să răspundă corect, doar că unui public mai larg. Modelul de evaluare e complementar celui de calitate a retrieval-ului, nu un înlocuitor.

Întrebări frecvente

Pot să nu indexez deloc documentele sensibile?

Da, și e cea mai sigură opțiune când segmentul sensibil e mic și rar cerut. Un index separat, cu acces restrâns, evită complet problema filtrării. Prețul e că sistemul nu va putea răspunde la întrebări legitime din acea zonă, iar utilizatorii autorizați vor căuta manual — ceea ce, în funcție de caz, poate fi exact compromisul corect.

Filtrarea după permisiuni încetinește retrieval-ul?

Depinde de unde se aplică. Filtrarea la nivel de partiție (namespace, colecție) e de obicei mai rapidă decât căutarea în indexul complet, pentru că spațiul căutat e mai mic. Filtrarea pe metadate într-un index comun poate încetini semnificativ când filtrul e selectiv, iar recuperarea recall-ului (scanare iterativă, grafuri filtrabile) costă CPU și latență de coadă. Măsoară pe datele tale.

Cum tratez utilizatorii anonimi sau publicul extern?

Ca pe un tenant cu drepturi minime, nu ca pe o excepție. Dai identității anonime un access_scope explicit — de exemplu public — și aplici exact același mecanism de filtrare. Excepțiile în cod sunt locul unde apar breșele; un rol cu drepturi zero e mai sigur decât o ramură if care sare peste filtru.

Ce fac dacă baza vectorială nu suportă filtrare pre-retrieval?

Ai trei ieșiri: partiționezi datele fizic (colecții sau indexuri separate pe granițele de încredere), muți filtrarea într-un motor care o suportă, sau accepți post-filtrarea și compensezi recall-ul cerând un k mult mai mare. A treia variantă rămâne acceptabilă doar dacă filtrul nu e foarte selectiv — și înseamnă că scorurile documentelor interzise sunt oricum calculate.

Cine deține politica de acces: aplicația sau baza de cunoștințe?

Sursa de adevăr rămâne sistemul care a generat documentul — ERP, DMS, drive, ticketing. Indexul păstrează o proiecție a acelei politici, nu o versiune proprie. În momentul în care cineva editează permisiuni direct în index, ai două surse de adevăr care vor diverge, iar divergența nu se anunță.

Controlul accesului nu e o funcție pe care o adaugi peste un sistem RAG care funcționează. E o proprietate a buclei întregi: identitatea trebuie să ajungă până la interogare, filtrul trebuie să fie o graniță și nu o convenție, iar revocarea are nevoie de un mecanism propriu, pentru că nu seamănă cu nicio ștergere.

Dacă pornești acum un asemenea sistem, cel mai bun moment pentru a decide unde stă granița e înainte de prima ingestie — schema de metadate e greu de schimbat retroactiv. Restul clusterului acoperă contextul: ce este RAG pentru fundamente, arhitectura RAG pentru deciziile de structură, iar Fundamentele RAG și soluțiile AI și RAG pentru harta completă a subiectului.