La différence entre les filtres et les murs
Vous construisez un agent IA ayant accès à vos données. Vous avez deux choix pour la sécurité. Vous pouvez filtrer les données, ou vous pouvez les cloisonner.
Le filtrage signifie que votre requête ne renvoie que certaines lignes. Le cloisonnement signifie que l'agent ne peut absolument pas accéder aux lignes cachées.
Cela semble identique jusqu'à ce que quelque chose casse.
J'ai récemment construit un système pour transformer 1,2 million de mots en une base de connaissances. J'ai utilisé Supabase pour gérer les données. Je voulais que mes agents IA ne voient que le contenu public.
J'ai utilisé une vue Postgres standard pour filtrer les données :
CREATE VIEW public_seeds AS
SELECT * FROM moments
WHERE visibility = 'public'
AND is_canonical = true;
Cela semble correct. Mais cela présente une faille massive. Par défaut, une vue Postgres s'exécute avec les privilèges du propriétaire, et non de la personne qui l'appelle. Le propriétaire de la vue a souvent un accès complet. Cela signifie que vos politiques de Row Level Security (RLS) ne s'appliquent pas à la vue.
Vous n'avez pas construit un mur. Vous avez construit un filtre.
Si un filtre échoue, un agent IA ne s'en apercevra pas. Un humain verra une erreur ou des données erronées. Un agent se contente de traiter ce qu'il reçoit. Si votre filtre échoue, votre agent commencera à utiliser des données privées sans avertissement.
Postgres 15 a résolu ce problème avec l'option security_invoker.
Lorsque vous réglez security_invoker sur true, la vue s'exécute avec le rôle appelant. Cela force la vue à respecter vos politiques RLS. La vue devient une barrière structurelle.
La méthode correcte :
CREATE VIEW public_seeds
WITH (security_invoker = true)
AS
SELECT * FROM moments
WHERE visibility = 'public'
AND is_canonical = true;
Désormais, le mur est structurel. Même si un développeur écrit une mauvaise requête ou une jointure, la politique RLS protège la table.
« Cela ne devrait pas arriver » repose sur le fait que tout fonctionne parfaitement. « Cela ne peut pas arriver » repose sur votre architecture.
Lorsque vous construisez pour l'IA, vous devez concevoir pour ce qui ne peut pas arriver.
Trois choses à vérifier dans votre configuration :
- Assurez-vous de ne pas utiliser le service role pour les agents. Le service role contourne entièrement le RLS.
- Vérifiez votre version de Postgres. Vous avez besoin de la version 15 ou supérieure pour security_invoker.
- Auditez vos vues existantes. Les anciennes vues ne suivent pas automatiquement les nouvelles politiques RLS.
Communauté d'apprentissage optionnelle : https://t.me/GyaanSetuAi