Permission-aware RAG: πώς ο AI agent βρίσκει μόνο έγγραφα που επιτρέπεται να δει ο χρήστης
Ένα εταιρικό AI chatbot μπορεί να αναζητά συμβάσεις, HR policies, οικονομικά αρχεία και τεχνική γνώση. Αν το retrieval layer επιστρέψει έγγραφο που ο χρήστης δεν δικαιούται να δει, το μοντέλο μπορεί να αποκαλύψει το περιεχόμενό του στην απάντηση ή ακόμη και να επιβεβαιώσει ότι υπάρχει. Το prompt «μη δείχνεις εμπιστευτικά δεδομένα» δεν αποτελεί authorization.
Το permission-aware RAG εφαρμόζει τα δικαιώματα πριν τα passages φτάσουν στο model. Η αναζήτηση περιορίζεται με βάση την επαληθευμένη ταυτότητα, τα groups, τους ρόλους και τα ACL του κάθε document.
Authorization πριν από relevance
Μια vector search κατατάσσει κείμενα με βάση τη σημασιολογική ομοιότητα. Δεν γνωρίζει από μόνη της ποιος επιτρέπεται να δει τι. Η ασφαλής λογική είναι authorization filter και μετά relevance ranking πάνω στο επιτρεπόμενο σύνολο, ή ενιαία query-time enforcement μέσα στη search engine.
Δεν είναι ασφαλές να ανακτηθούν τα top 50 αποτελέσματα και μετά η εφαρμογή να αφαιρέσει τα μη επιτρεπόμενα, ειδικά αν intermediate logs, rerankers ή model-based filters έχουν ήδη δει το περιεχόμενο. Το trimming πρέπει να γίνεται όσο πιο κοντά γίνεται στην ίδια την αναζήτηση.
Η Microsoft τεκμηριώνει document-level access control στο Azure AI Search για RAG και agentic systems, με permission metadata στο index και enforcement κατά το query. Η αρχή ισχύει ανεξάρτητα από συγκεκριμένο vendor.
Ποια metadata χρειάζεται το index
Κάθε document ή chunk πρέπει να διατηρεί reference στο source document και permission metadata. Αν τα δικαιώματα είναι σε επίπεδο αρχείου, όλα τα chunks κληρονομούν το ίδιο ACL. Αν υπάρχουν sections με διαφορετική πρόσβαση, χρειάζεται λεπτομερέστερο security boundary και όχι μόνο κοινό parent ID.
Συνήθη metadata είναι tenant ID, allowed user IDs, group IDs, role ή department, classification label και source version. Τα πεδία που χρησιμοποιούνται για filters πρέπει να είναι filterable και να μην βασίζονται σε free text που μπορεί να αλλοιωθεί.
Το content ingestion δεν πρέπει να αντιγράφει μόνο κείμενο. Πρέπει να μεταφέρει και την τρέχουσα πολιτική πρόσβασης από το source system. Χωρίς ACL synchronization, το search index γίνεται δεύτερο, ανεξέλεγκτο repository.
Ταυτότητα χρήστη στο query
Η εφαρμογή αντλεί user και group identity από verified session ή access token. Δεν παίρνει tenant ή role από prompt argument. Στη συνέχεια δημιουργεί permission filter ή περνά token σε search service που υποστηρίζει native enforcement.
Η τεκμηρίωση Azure περιγράφει security filters με user/group strings και native token-based patterns όπου οι claims συγκρίνονται με permission metadata. Σε custom υλοποίηση, το backend κατασκευάζει το filter και δεν επιτρέπει στο model να το αφαιρέσει ή να το τροποποιήσει.
Η πρόσβαση στο ίδιο το search index είναι επίσης περιορισμένη. Ένα γενικό API key μέσα στον browser θα επέτρεπε παράκαμψη της εφαρμογής. Τα queries περνούν από trusted backend ή managed identity με το ελάχιστο απαιτούμενο scope.
Groups, inheritance και ACL explosion
Οι εταιρικές άδειες συχνά προκύπτουν από nested groups, folders και inherited permissions. Η εισαγωγή πρέπει να αποφασίσει αν αποθηκεύει expanded user IDs ή group IDs. Το expansion όλων των χρηστών σε κάθε document αυξάνει το index και δυσκολεύει τις αλλαγές. Τα group IDs είναι πιο συμπαγή, αλλά το query layer πρέπει να γνωρίζει αξιόπιστα τα memberships.
Χρειάζονται όρια και monitoring για documents με υπερβολικά ACL entries. Τα features κάθε provider έχουν συγκεκριμένους περιορισμούς, ιδιαίτερα σε preview λειτουργίες. Το design δεν πρέπει να βασίζεται σε μη υποστηριζόμενο αριθμό principals.
Η inheritance πρέπει να έχει ξεκάθαρη source-of-truth σημασία. Αν ένα child document αφαιρέσει inherited access, η διαδικασία sync πρέπει να το αποτυπώσει και όχι να κρατήσει stale parent permission.
Permission synchronization και παράθυρο έκθεσης
Όταν ένας χρήστης αφαιρεθεί από group ή ένα έγγραφο γίνει confidential, ο index πρέπει να ενημερωθεί. Μέχρι τότε μπορεί να υπάρχει stale permission window. Η Microsoft επισημαίνει ότι αλλαγές δικαιωμάτων γίνονται ορατές αφού συγχρονιστούν τα metadata με τον index.
Για κρίσιμα δεδομένα χρειάζονται event-driven updates ή μικρό sync interval. Μπορεί επίσης να γίνεται δεύτερος real-time authorization check στο source πριν προβληθεί ολόκληρο document ή εκτελεστεί action.
Κάθε indexed item κρατά permission version και last-synced timestamp. Αν το ACL είναι παλιό πέρα από policy threshold, το σύστημα μπορεί να αρνηθεί retrieval αντί να ρισκάρει πρόσβαση.
Tenant isolation πρώτα
Σε multi-tenant εφαρμογή, το tenant filter είναι υποχρεωτικό σε κάθε query και προκύπτει από verified identity. Δεν πρέπει ένα document άλλου tenant να μπαίνει καν στο candidate set, ακόμη κι αν κατά λάθος μοιράζεται group name.
Μπορούν να χρησιμοποιηθούν ξεχωριστά indexes ανά tenant για ισχυρότερη απομόνωση ή κοινός index με αδιάσπαστο tenant filter. Η επιλογή εξαρτάται από κλίμακα και threat model. Σε κοινό index, απαιτούνται tests που αποδεικνύουν ότι κάθε code path εφαρμόζει το filter.
Τα admin και support εργαλεία χρειάζονται επίσης scope. Ένα elevated diagnostic query πρέπει να είναι ρητό, audited και περιορισμένο, όχι κρυφό bypass στο κανονικό endpoint.
Caching χωρίς διαρροή
Το cache key πρέπει να περιλαμβάνει permission context ή να αποθηκεύει μόνο public/common αποτελέσματα. Αν μια απάντηση που δημιουργήθηκε για manager επιστραφεί από cache σε απλό χρήστη, η ασφάλεια έχει παρακαμφθεί μετά το retrieval.
Για retrieval cache, το key περιλαμβάνει tenant, normalized query, ACL/group fingerprint, index version και permission version. Αλλαγές membership ή document ACL πρέπει να ακυρώνουν σχετικές entries ή να έχουν πολύ μικρό TTL.
Τα citations και snippets σε conversation history παραμένουν δεδομένα με permissions. Αν ο χρήστης χάσει πρόσβαση, μια νέα συνεδρία δεν πρέπει να επαναφέρει cached confidential context. Για συνεχιζόμενη conversation, η πολιτική πρέπει να ορίζει revalidation.
Prompt injection από εξουσιοδοτημένα έγγραφα
Το γεγονός ότι ο χρήστης δικαιούται ένα document δεν σημαίνει ότι το περιεχόμενο είναι ασφαλής instruction. Ένα έγγραφο μπορεί να περιέχει κακόβουλο κείμενο που προσπαθεί να αλλάξει τη συμπεριφορά του agent.
Το retrieved content αντιμετωπίζεται ως untrusted data, διαχωρίζεται από system instructions και περνά από hygiene controls. Η Microsoft συστήνει permission-aware indexes, access control, relevance controls και citations, μαζί με αντιμετώπιση prompt injection από documents.
Authorization και prompt-injection defense είναι δύο διαφορετικά layers. Χρειαζόμαστε και τα δύο.
Απαντήσεις, citations και no-result συμπεριφορά
Το model λαμβάνει μόνο εξουσιοδοτημένα chunks και οι citations δείχνουν σε URLs που επίσης εφαρμόζουν authorization. Δεν πρέπει ένα citation link να εκθέτει public blob URL επειδή το retrieval ήταν προστατευμένο.
Αν δεν υπάρχουν επιτρεπόμενα αποτελέσματα, η απάντηση λέει ότι δεν βρέθηκε διαθέσιμη πληροφορία. Δεν αποκαλύπτει ότι υπάρχουν τρία confidential documents που ο χρήστης δεν μπορεί να δει.
Οι source titles μπορεί επίσης να είναι ευαίσθητοι. Το logging και το tracing πρέπει να redacts content και document names ανάλογα με τον ρόλο του operator.
Tests που πρέπει να υπάρχουν
Χρειάζονται negative authorization tests: χρήστης Α δεν ανακτά document Β, ούτε μέσω semantic query, exact title, typo, filters, pagination ή cached response. Δοκιμάζονται αλλαγές group membership, revoked access, deleted document και cross-tenant IDs.
Τα evals ελέγχουν όχι μόνο answer quality αλλά retrieval authorization rate. Ένα single unauthorized chunk είναι σοβαρό failure ακόμη κι αν η τελική απάντηση δεν το παράθεσε.
Red-team prompts επιχειρούν να ζητήσουν filenames, summaries ή επιβεβαίωση ύπαρξης. Τα results και traces εξετάζονται χωρίς να αντιγράφουν ευαίσθητα documents σε λιγότερο προστατευμένο σύστημα.
Πώς το υλοποιεί η Ai Foundry
Στην Ai Foundry σχεδιάζουμε το RAG πάνω στο υπάρχον identity και authorization model της επιχείρησης. Κατά το ingestion μεταφέρουμε tenant, groups, ACL και permission versions μαζί με τα chunks. Στο query, το backend δημιουργεί υποχρεωτικά filters από verified identity πριν οποιοδήποτε content φτάσει σε reranker ή model.
Υλοποιούμε permission synchronization, freshness monitoring και ασφαλή cache keys που περιλαμβάνουν το authorization context. Τα citations οδηγούν σε προστατευμένα resources, ενώ negative tests καλύπτουν cross-tenant, revoked-access και stale-cache σενάρια. Παράλληλα αντιμετωπίζουμε το retrieved content ως untrusted για προστασία από prompt injection. Έτσι ο agent απαντά από τη γνώση της εταιρείας χωρίς να γίνεται παράκαμψη των δικαιωμάτων της.
Checklist ασφαλούς RAG
- Μεταφέρονται ACL και tenant metadata κατά το ingestion;
- Εφαρμόζεται authorization πριν από reranking και model context;
- Προκύπτουν identity και groups από verified session/token;
- Συγχρονίζονται γρήγορα revoked permissions;
- Υπάρχει permission version και freshness policy;
- Περιλαμβάνει το cache key το authorization context;
- Προστατεύονται και τα citation URLs;
- Δεν αποκαλύπτει το no-result response ύπαρξη ιδιωτικών εγγράφων;
- Υπάρχουν negative και cross-tenant tests;
Το ασφαλές RAG δεν ρωτά το model αν επιτρέπεται να απαντήσει. Φροντίζει να μη δει ποτέ το περιεχόμενο που δεν επιτρέπεται να χρησιμοποιήσει.