Le problème dont presque personne ne parle avec les agents IA d’entreprise
Votre CFO demande à un agent IA : « Combien avons-nous dépensé en salaires au dernier trimestre ? »
L’agent appelle votre API paie. L’API renvoie salaire, bonus et numéro personnel pour chaque employé. L’agent résume en un total clair.
Jusque-là, tout va bien — le CFO a le droit de voir ces données.
Maintenant un stagiaire pose la même question au même agent. L’agent appelle la même API. L’API renvoie la même charge utile. L’agent répond.
C’est le mode de défaillance silencieux de presque tout déploiement d’« agent IA d’entreprise » en production aujourd’hui.
Pourquoi le RBAC au niveau des endpoints ne suffit pas
La plupart des plateformes d’intégration — y compris la nôtre, jusqu’à récemment — sécurisent l’accès API au niveau de l’endpoint. Soit vous pouvez appeler GET /payroll/employees, soit non. Ce modèle fonctionnait quand les humains construisaient des interfaces qui filtraient côté client et que les seuls appelants étaient des services backend de confiance.
Les agents cassent ce modèle de deux façons :
- Les agents sont des appelants génériques. Ils ne savent pas quels champs masquer. Ils résument tout ce qu’ils reçoivent.
- Les agents agissent pour de nombreux utilisateurs. Un même profil d’agent peut servir le PDG et l’opérateur d’entrepôt. Le RBAC par endpoint ne les distingue pas une fois la requête autorisée.
Résultat : les agents deviennent un problème de « confused deputy » à l’échelle industrielle. Un utilisateur sans accès direct à la base peut extraire toutes les données que l’agent peut atteindre — avec la bonne question.
Où le RBAC du système source montre ses limites
La réponse standard est « laissez le système source gérer ça ». Transmettre l’identité utilisateur au système de paie. Laisser filtrer.
Cela fonctionne — quand le système source le supporte. En pratique :
- Les systèmes legacy ont souvent un seul compte de service avec accès complet. Pas de délégation par utilisateur.
- Les API SaaS tierces manquent souvent de permissions au niveau des lignes. Soit portée admin, soit rien.
- Les API internes maison ont été conçues avant les agents IA. Personne n’a ajouté
filter_by_user. - Les agrégations fuient. Même avec filtrage de lignes, sommes et moyennes sont souvent calculées sur l’ensemble complet.
Pour un RSSI, la surface d’exposition des données est désormais définie par le connecteur le plus faible dans la boîte à outils de l’agent.
Défense en profondeur : filtrage des réponses piloté par politique
Nous avons ajouté une nouvelle couche à l’Integration Platform de Copyl : DataAccessPolicy. Elle se situe entre la réponse du système source et l’agent, et applique des règles déclaratives à ce qui est renvoyé.
Le modèle repose sur trois idées :
1. Les politiques sont attachées aux actions d’intégration, pas aux agents.
Un endpoint paie a une politique. Chaque agent — chaque utilisateur — qui le touche passe par le même évaluateur. Un agent mal configuré ne peut pas contourner la règle.
2. Les règles correspondent au contexte du sujet, pas à l’endpoint.
L’évaluateur voit le sujet complet : identité, rôles, claims, profil d’agent, entreprise. Une règle peut dire « si le rôle contient CEO, autoriser toutes les lignes » ou « si l’utilisateur est Employee, ne renvoyer que les lignes où employeeId correspond à son ID. »
3. Push-down quand c’est possible, post-filtre en secours.
Si l’API source supporte le filtrage, la politique réécrit la requête — ?employeeId=42 — pour que les données sensibles ne quittent pas le système source. Sans push-down, filtrage côté serveur avant que l’agent ne voie.
Ce dernier point compte pour la conformité. Filtrer au moment de la requête est réellement plus sûr qu’après coup. Le post-filtre est une défense en profondeur, pas un substitut aux contrôles à la source.
Ce que cela donne pour Sec/Compliance
Trois propriétés le rendent gouvernable :
Auditable. Chaque évaluation écrit une trace : quelle politique, quelle règle, lignes entrées/sorties, champs masqués. Vous pouvez répondre à « qui a vu les données paie mardi et qu’a-t-on filtré ? » en SQL.
Versionné. Brouillon → publié → archivé. Chaque changement est une nouvelle version. Diff, restauration, preuve de ce qui était actif à une date.
Testable avant publication. Dry-run — le filtre est évalué et journalisé, la réponse n’est pas modifiée. Valider sur le trafic réel pendant des semaines. La publication exige un test réussi ou une dérogation explicite.
Pour les secteurs réglementés (finance, santé, secteur public sous NIS2/DORA en Europe), « faire confiance à l’agent » devient « prouver l’agent ».
Ce que cela ne résout pas
Des limites assumées :
- La délégation dans le système source reste préférable quand elle existe. Utilisez-la d’abord. Le filtrage par politique est pour le reste.
- Les agrégations sont délicates. Un filtre de lignes avec le salaire d’une personne et un champ
total: 4 200 000calculé sur tous les employés fuit. Notre modèle détecte les champs agrégés et échoue, les retire ou exige un opt-in explicite — réflexion endpoint par endpoint nécessaire. - Le masquage de champs n’est pas du chiffrement. Les numéros personnels hachés restent des PII. Le masquage réduit l’impact ; il ne supprime pas l’obligation.
- Les politiques ne valent que leurs règles. Un mauvais matching du sujet sur- ou sous-autorise. D’où les campagnes de test et la visibilité d’audit.
Ce que cela signifie en pratique
Si vous faites tourner des agents IA contre des systèmes sans RBAC au niveau des lignes — la plupart des ERP legacy, des paies, des API maison avant 2024 — vous avez une exposition que le contrôle au niveau des endpoints ne ferme pas.
La correction est structurelle, pas un tour de prompting. Dire dans le system prompt « montre seulement les données de l’utilisateur » tient jusqu’au prochain jailbreak. L’imposer dans la couche d’intégration avec une politique versionnée et auditable est quelque chose qu’un RSSI peut valider.
Nous déployons DataAccessPolicy sur les agents marketplace de Copyl, en commençant par paie, RH et finance. Si vous opérez dans un environnement réglementé et souhaitez analyser où se situe l’exposition dans votre stack, contactez-nous.
Copyl est une plateforme pour construire, déployer et gouverner des agents IA d’entreprise. Notre Integration Platform (CIP) connecte les agents aux systèmes métiers avec application des politiques de bout en bout, journalisation d’audit et contrôle de version.