🤖 AI

Securing the Agent: Vendor-Neutral, Multitenant Enterprise Retrieval and Tool Use

Ce document comble la lacune critique en matière de sécurité des systèmes d'IA d'entreprise multilocataires, où la pertinence de la récupération prime sur l'autorisation, en proposant et en validant une architecture d'isolation en couches côté serveur au sein du framework open-source OGX, qui impose une ingestion et un filtrage de récupération conformes aux politiques pour prévenir les fuites de données entre locataires avec une surcharge de performance négligeable.

Auteurs originaux : Francisco Javier Arceo, Varsha Prasad Narsing

Publié 2026-05-08

📖 5 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Francisco Javier Arceo, Varsha Prasad Narsing

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez une immense bibliothèque high-tech où des milliers d'entreprises différentes (locataires) ont loué des étagères pour stocker leurs documents secrets. Dans cette bibliothèque, il y a aussi des robots puissants (agents IA) embauchés pour trouver des informations spécifiques et exécuter des tâches selon ce que les entreprises demandent.

Le document d'Arceo et Narsing identifie un défaut dangereux dans le fonctionnement actuel de ces bibliothèques et propose un nouveau système de sécurité pour le corriger.

Le Problème : Le Piège de la « Pertinence »

Dans une bibliothèque normale, si vous demandez des « recettes », le bibliothécaire vous remet les livres les plus pertinents pour ce mot. Il ne se soucie pas de qui possède les livres ; il se contente de prendre les meilleurs correspondants.

Les auteurs soulignent que, dans le monde de l'IA, c'est un désastre pour la sécurité.

Le Scénario : L'entreprise A demande au robot : « Comment réparer notre serveur ? »
L'Erreur : Le robot parcourt toute la bibliothèque. Il trouve un document de l'entreprise B qui est très similaire à la question (peut-être qu'il traite aussi de la réparation d'un serveur).
La Fuite : Parce que le document est une « correspondance parfaite » pour la question, le robot le remet. L'entreprise A vient de lire le manuel serveur secret de l'entreprise B.

Le document appelle cela le « Fossé Pertinence-Autorisation ». Le système est excellent pour trouver ce qui est pertinent, mais terrible pour vérifier qui a le droit de le voir.

La Solution : Le Bâtiment à « Isolation en Couches »

Pour corriger cela, les auteurs proposent une nouvelle conception de bâtiment avec trois couches de sécurité spécifiques et une règle stricte concernant qui détient les clés.

1. Les Trois Couches de Sécurité

Imaginez le parcours des données comme un colis traversant une installation sécurisée :

Couche 1 : Le Poste d'Étiquetage (Ingestion Consciente des Politiques)
Lorsqu'une entreprise dépose une boîte de documents, le système tamponne immédiatement chaque page avec une étiquette « Entreprise A » ou « Entreprise B ». Vous ne pouvez pas oublier de les étiqueter plus tard ; cela se produit dès leur arrivée. Cela garantit que chaque morceau de papier sait à qui il appartient.
Couche 2 : Le Portail de Sécurité (Filtrage de la Récupération)
Avant même que le robot ne soit autorisé à chercher des livres, il doit passer par un portail de sécurité. Le portail vérifie la badge d'identité de l'utilisateur.
- Si l'utilisateur vient de l'entreprise A, le portail bloque physiquement l'allée contenant les livres de l'entreprise B.
- Le robot ne voit jamais les livres interdits, donc il ne peut pas accidentellement les remettre. Cela s'appelle le filtrage ABAC (Contrôle d'Accès Basé sur les Attributs).
Couche 3 : Le Cerveau Partagé (Inférence Partagée)
La partie réelle de « réflexion » du robot (le modèle d'IA) est partagée par tous pour économiser de l'argent. Habituellement, vous pourriez penser qu'il faut un robot séparé pour chaque entreprise pour garder les secrets en sécurité. Mais parce que les couches 1 et 2 garantissent que seuls les documents corrects et étiquetés sont jamais alimentés au robot, le robot peut être partagé en toute sécurité. C'est comme un chef cuisinant pour tout le monde, mais les ingrédients sont prétriés de sorte que le chef n'utilise jamais accidentellement la recette secrète d'un client dans le plat d'un autre client.

2. La Règle « Côté Serveur »

Le document soutient que les vérifications de sécurité doivent se produire à l'intérieur du bâtiment (le serveur), et non à l'extérieur dans le bureau du client (le client).

L'Ancienne Façon (Côté Client) : L'ordinateur du client effectue la recherche et la vérification. Un client malveillant pourrait simplement désactiver son logiciel de sécurité, ignorer les règles et demander au robot de regarder tout.
La Nouvelle Façon (Côté Serveur) : Le client envoie une demande, mais l'équipe de sécurité interne du bâtiment effectue toute la recherche, l'utilisation d'outils et la vérification. Le client peut demander une « voiture rouge », mais il ne peut pas dire à l'équipe de sécurité d'ignorer les règles et de lui montrer une « voiture bleue » qui appartient à quelqu'un d'autre. Le bâtiment contrôle comment la recherche se déroule, garantissant que les règles ne sont jamais enfreintes.

Les Résultats : Ce Qu'ils Ont Testé

Les auteurs ont construit un système prototype appelé OGX (Open GenAI Stack) pour tester cette idée. Ils ont mené des expériences avec de fausses entreprises et des questions pièges pour voir ce qui se passait.

Sécurité : Sans le nouveau portail de sécurité, 98 à 100 % du temps, le robot a divulgué des documents secrets d'autres entreprises. Avec le nouveau portail, 0 % des secrets ont été divulgués. Le portail de sécurité a complètement arrêté les fuites.
Vitesse : L'ajout du portail de sécurité a ralenti les choses d'une infime quantité (environ 19 millisecondes). C'est comme ajouter une pause d'une fraction de seconde à une conversation — imperceptible pour les humains mais cruciale pour la sécurité.
Qualité : Parce que le robot n'était pas confus par des documents non pertinents d'autres entreprises, il a en fait trouvé les bonnes réponses plus rapidement et plus précisément.

La Conclusion

Le document conclut que vous pouvez avoir un système d'IA partagé et rentable pour de nombreuses entreprises différentes sans qu'elles ne volent les secrets les unes des autres. Il suffit de cesser de faire confiance à la « pertinence » d'un résultat de recherche et de commencer à appliquer des vérifications strictes de « permission » à la porte, le tout géré par une équipe de sécurité centrale à l'intérieur du serveur.

Ils soulignent qu'il s'agit d'une solution fournisseur-neutre, ce qui signifie qu'elle ne vous verrouille pas dans une entreprise d'IA spécifique (comme OpenAI ou Google) ; elle fonctionne avec n'importe quels outils d'IA open-source ou commerciaux que vous choisissez.

Résumé technique : Sécurisation de l'agent dans les environnements d'entreprise multitenants

1. Énoncé du problème

Le document traite d'une lacune fondamentale en matière de sécurité dans le déploiement des systèmes de génération augmentée par récupération (RAG) et des agents d'intelligence artificielle au sein des environnements d'entreprise. Alors que les traitements académiques et les API destinées aux consommateurs supposent souvent un accès aux données en mode mono-tenant et homogène, les déploiements d'entreprise réels impliquent plusieurs locataires partageant une infrastructure avec des données hétérogènes, une conformité réglementaire stricte et des exigences de contrôle d'accès granulaire.

Le problème central identifié est le fossé pertinence-autorisation. Les systèmes de récupération existants (vectoriels, par mots-clés ou hybrides) sont optimisés pour la pertinence sémantique ou la correspondance de mots-clés, mais manquent de mécanismes natifs pour faire respecter les politiques d'autorisation. Par conséquent, une requête émanant d'un locataire peut récupérer et exposer des données confidentielles appartenant à un autre locataire si ces données obtiennent les scores les plus élevés selon les métriques de pertinence. Ce fossé est exacerbé dans les systèmes d'agents où :

La divulgation médiée par les outils se produit lorsque les agents invoquent des outils avec des identifiants larges plutôt qu'une autorisation de l'utilisateur final.
L'accumulation de contexte permet aux conversations multi-tours de fuir des données inter-locataires sans réévaluation de la politique à chaque tour.
L'orchestration côté client distribue la logique critique pour la sécurité à des clients potentiellement non fiables, permettant de contourner les vérifications d'autorisation.

Les approches standard d'isolation, telles que la réplication de toute la pile d'agents (stores vectoriels, points de terminaison d'inférence) par locataire, sont jugées prohibitives en termes de coûts et fragmentées opérationnellement.

2. Méthodologie et architecture

Les auteurs proposent une architecture d'isolation en couches imposée par une orchestration côté serveur pour sécuriser les chemins de données et de contrôle des agents d'IA. Cette approche est mise en œuvre dans OGX (Open GenAI Stack), un framework open-source neutre vis-à-vis des fournisseurs, offrant des API compatibles OpenAI.

2.1 Isolation en couches (Chemin des données)

L'architecture sécurise le flux de données à travers trois couches distinctes au sein de la limite de confiance du serveur :

Ingestion consciente des politiques : Les métadonnées du locataire (propriété, attributs) sont attachées aux documents au moment de l'ingestion. Cela garantit que chaque fragment de document hérite d'attributs de locataire cohérents, empêchant un couplage accidentel inter-locataire.
Gestion de la récupération : Un mécanisme d'application à deux niveaux est appliqué :
- Pré-recherche : L'autorisation basée sur les attributs (ABAC) est évaluée avant le début de la recherche.
- Post-récupération : Un filtrage au niveau des fragments est appliqué après la récupération.
- Le système prend en charge la propagation des prédicats (où le backend vectoriel applique nativement les filtres lors de la recherche) pour maintenir un rappel parfait à grande échelle. Si la propagation n'est pas disponible, le filtrage post-récupération assure la sécurité (zéro fuite) mais peut dégrader le rappel sur de grands corpus.
Inférence partagée : La couche d'inférence du modèle de langage (LLM) est partagée entre les locataires. Puisque les couches 1 et 2 garantissent que seuls les documents autorisés entrent dans le contexte de l'invite, le modèle lui-même ne nécessite pas d'isolation par locataire, réduisant les coûts d'infrastructure de $O(N \cdot M)$ à $O(M)$ .

2.2 Orchestration côté serveur (Chemin de contrôle)

Pour répondre aux risques de contournement côté client, les auteurs préconisent une orchestration côté serveur de la boucle inférence $\to$ outil $\to$ inférence.

Limite de confiance : Toutes les opérations critiques pour la sécurité (autorisation d'exécution des outils, isolation de l'état, application des politiques) sont centralisées au sein du processus serveur.
Compromis : Bien que cela introduise une latence pour les appels d'outils par rapport à une exécution locale, cela empêche les clients compromis de sauter les filtres ou de manipuler les invocations d'outils.
Approche hybride : L'architecture permet aux frameworks côté client de conserver le contrôle sur la composition des agents et les opérations sensibles à la latence, tandis que le serveur fait respecter les invariants de sécurité.

3. Contributions clés

Le document apporte quatre contributions principales :

Formalisation du fossé pertinence-autorisation : Les auteurs définissent mathématiquement pourquoi le classement par pertinence seul est insuffisant pour l'isolation et fournissent des preuves empiriques montrant que la récupération non filtrée fuite des données inter-locataires dans 98 à 100 % des sondages.
Architecture d'isolation en couches : Une conception proposée combinant l'ingestion consciente des politiques, la gestion de la récupération au moment de la recherche et l'inférence partagée, avec l'orchestration côté serveur comme couche d'application.
Validation empirique : Une évaluation en six expériences mesurant la sécurité (fuites, résistance à l'injection d'invite), les performances des systèmes (latence, débit) et la qualité de la récupération à travers une matrice $2 \times 2$ des modes d'orchestration (client vs serveur) et de la gestion de la récupération (non filtrée vs filtrée par ABAC).
Implémentation open-source : L'architecture est implémentée dans OGX, un framework neutre vis-à-vis des fournisseurs offrant des API compatibles OpenAI (y compris une API de réponses pour l'orchestration multi-tours) et un Opérateur Kubernetes pour le déploiement.

4. Résultats expérimentaux

L'évaluation a utilisé un banc d'essai synthétique avec trois locataires (finance, ingénierie, juridique) et 300 documents.

Sécurité (Fuite inter-locataire) :
- Configurations non filtrées : Indépendamment du mode d'orchestration, la récupération non filtrée a entraîné une fuite de 98 à 100 % des données inter-locataires.
- Configurations filtrées : Le filtrage ABAC a éliminé toute fuite inter-locataire (0 % de fuite), atteignant l'objectif de sécurité (G1).
- Injection d'invite : Dans les configurations filtrées, tous les 90 sondages d'injection d'invite ont été bloqués (0 % de fuite). Dans les configurations non filtrées, 62 à 80 % des sondages ont réussi à récupérer des données non autorisées.
- Application : L'étude souligne que si le filtrage côté client (Configuration B) peut atteindre 0 % de fuite, il repose sur l'intégrité du client. L'orchestration côté serveur (Configuration D) fournit la garantie d'application nécessaire (G2) en déplaçant la logique à l'intérieur de la limite de confiance.
Performances :
- Latence : La gestion de la récupération a ajouté environ 19 ms au chemin de recherche (aller-retour d'authentification + évaluation de la politique + recherche), ce qui est négligeable par rapport aux temps d'inférence (secondes). L'orchestration côté serveur a ajouté une latence totale d'environ 3 secondes due aux aller-retours, mais prend en charge le streaming pour réduire le temps jusqu'au premier jeton.
- Débit : Le filtrage n'a pas dégradé le débit. Le débit a augmenté linéairement avec la concurrence. L'orchestration côté client a atteint environ 2 fois le QPS de l'orchestration côté serveur à haute concurrence en raison de chemins de requête plus courts.
Qualité de la récupération :
- Le filtrage au niveau des fragments a amélioré la Précision@5 de 2,2 fois (de 0,200 à 0,433) en filtrant le bruit inter-locataire.
- Propagation des prédicats : Les backends prenant en charge la propagation des prédicats ont maintenu un Rappel@5 = 1,0 pour toutes les tailles de corpus. Les backends sans propagation (utilisant un filtrage post-récupération) ont vu leur rappel se dégrader considérablement (de 1,0 à 0,002) alors que la taille du corpus augmentait jusqu'à 50 000 fragments, bien que les garanties de sécurité restent intactes.

5. Importance et portée

Le document affirme que ce travail est le premier à traiter l'intersection de la conception d'API d'agents standardisée, de l'orchestration côté serveur et de l'isolation multitenante sur une infrastructure partagée.

Importance : L'architecture démontre qu'une multitenance sécurisée, des API compatibles OpenAI neutres vis-à-vis des fournisseurs et des capacités d'agents autonomes peuvent être réalisées simultanément sans duplication d'infrastructure par locataire. Elle déplace le paradigme de sécurité de la récupération « basée sur la pertinence » vers la récupération « basée sur les politiques ».
Portée et limites :
- La solution est conçue pour les environnements d'entreprise multitenants ; elle est inutile pour les déploiements mono-locataire ou les données publiques.
- L'architecture sécurise la construction du contexte mais pas la mémoire paramétrique ; les modèles peuvent toujours générer des informations absorbées lors du pré-entraînement.
- La limite de confiance est le processus serveur ; l'architecture ne protège pas contre les processus serveur compromis, les opérateurs internes ou les attaques par canal auxiliaire.
- Les outils de fonction côté client restent en dehors de la limite de confiance du serveur, bien qu'OGX atténue cela via une classification explicite des outils.

Les auteurs concluent que si l'orchestration côté client offre une latence plus faible pour les environnements de confiance, l'orchestration côté serveur avec filtrage ABAC est essentielle pour les scénarios d'entreprise nécessitant une isolation stricte et une conformité.