Les agents IA doivent hériter des autorisations utilisateur, sans disposer de leurs propres identifiants

Chaque nouvelle intégration soulève la même question de sécurité : à quoi peut-elle accéder qu’un humain ne pourrait pas ? Pour les agents IA, tout dépend d’un choix de conception. Soit l’agent dispose de ses propres identifiants, soit il agit avec les autorisations de la personne qui en fait la demande.

Ce choix détermine l’étendue de la surface d’accès. Un compte de service partagé avec un large périmètre crée une identité privilégiée qui n’est jamais revue comme celle d’un utilisateur, et il peut accéder à des données qu’aucun utilisateur n’était censé voir. L’héritage des autorisations élimine ce problème à la racine.

Cet article explique pourquoi les identifiants permanents des agents sont risqués, comment fonctionne l’héritage des autorisations en pratique, et quelles questions poser à toute plateforme d’agents lors d’une revue de sécurité.

Résumé Exécutif

Les agents IA doivent agir au nom de l’utilisateur demandeur. Lorsqu’un agent hérite des rôles et autorisations d’une personne, il ne peut rien voir ni faire de plus que cette personne ; la plateforme évalue la politique à chaque requête, et la traçabilité attribue chaque action à un individu identifié. Les agents dotés de leurs propres identifiants étendus font l’inverse : ils élargissent la surface d’accès et rompent le lien entre une action et un utilisateur responsable. Pour les RSSI et les architectes sécurité, l’héritage transforme la revue des agents en une analyse du modèle d’accès de la plateforme, plutôt qu’en une vérification du code de chaque agent.

Résumé des Points Clés

1. Des identifiants permanents d’agent créent une nouvelle identité privilégiée. Un compte de service à large périmètre peut accéder à des données qu’aucun utilisateur n’était censé atteindre.
2. L’héritage maintient la surface d’accès inchangée. Un agent qui agit avec les rôles et autorisations de l’utilisateur ne peut pas accéder à des ressources hors de ce périmètre.
3. La politique doit être évaluée à chaque requête. Des décisions basées sur les attributs, qui prennent en compte la classification, les attributs utilisateur et le contexte, laissent le contrôle à la plateforme et non à l’agent.
4. La déclaration du périmètre des outils transforme la revue de sécurité en revue documentaire. Lorsqu’un agent précise ce qu’il peut faire avant l’installation, les examinateurs évaluent une spécification plutôt que d’auditer du code.
5. Les administrateurs ont besoin d’un contrôle centralisé. Les outils destructeurs restent inactifs tant qu’ils ne sont pas explicitement activés, et la liste des outils exposés peut être restreinte, ce qui limite le comportement des agents à ce que l’organisation a validé.

Pourquoi les Identifiants Permanents d’Agent Sont Risqués

Les raccourcis d’intégration suivent souvent le même schéma. Quelqu’un crée un compte de service, lui accorde un périmètre suffisant pour le projet, puis passe à autre chose. Ce compte subsiste alors pendant des années, accumulant des accès jamais revus par rapport au rôle d’un utilisateur.

Une Identité Privilégiée Jamais Revue

Les utilisateurs changent de rôle, partent et perdent leurs accès. Un compte de service, lui, ne fait rien de tout cela. Si un agent en détient un, son périmètre d’accès reflète le jour de sa création, pas les besoins actuels de la personne qui l’utilise.

Des Actions Sans Utilisateur Responsable

Quand l’agent agit en son nom propre, le journal affiche l’agent. Il n’indique pas quelle personne a déclenché l’action ni si cette personne avait le droit d’accéder aux données. Pour un enquêteur ou un auditeur, cela crée une faille dans la chaîne de responsabilité.

Comment Fonctionne l’Héritage des Autorisations pour les Agents IA

Avec l’héritage, une opération IA reprend les rôles et autorisations de l’utilisateur authentifié. La plateforme évalue en temps réel la politique basée sur les attributs pour chaque requête, en tenant compte de la classification des fichiers, des labels de sensibilité, des attributs utilisateur et du contexte. Si l’utilisateur ne pouvait pas ouvrir le fichier directement, l’agent ne le pourra pas non plus.

Déclaration du Périmètre des Outils

Chaque agent déclare à l’avance les outils qu’il utilise. Les examinateurs comparent alors cette déclaration à leurs exigences avant l’installation. Les appels d’outils sont également vérifiés par rapport aux périmètres accordés au client, de sorte qu’un agent ne peut utiliser que les outils pour lesquels il a été validé.

Contrôle Centralisé pour les Administrateurs

Les outils destructeurs comme déplacer ou supprimer sont désactivés par défaut et doivent être explicitement activés. Les administrateurs peuvent aussi restreindre la liste des outils autorisés pour les agents, et des étapes de confirmation précèdent les actions d’écriture. Ces contrôles permettent à l’équipe sécurité de décider à l’avance ce que les agents pourront faire avant toute installation.

Questions à Poser à Toute Plateforme d’Agents

Demandez avec quelles autorisations un agent fonctionne et s’il possède ses propres identifiants. Demandez où la politique est évaluée, et si des jetons de sécurité ou des données de fichiers entrent dans le contexte du modèle sans action utilisateur. Demandez comment chaque appel apparaît dans le journal d’audit et s’il remonte dans votre SIEM. Une plateforme qui répond précisément à ces questions facilite la revue. Celle qui se contente de décrire le bon comportement de l’assistant n’a rien répondu.

Pourquoi le Point d’Application des Contrôles Est Essentiel

Un assistant peut être manipulé par un document ou une invite malveillante. Les contrôles qui reposent sur le bon comportement de l’assistant échouent alors. Les contrôles appliqués au niveau du connecteur, comme l’exclusion des jetons du contexte ou des données de fichiers sauf si l’utilisateur lit volontairement un fichier, restent efficaces.

Faire Respecter l’Héritage sur le Data Control Plane de Kiteworks

Les outils de posture décrivent où résident les données sensibles et l’IAM définit qui peut se connecter. Aucun ne contrôle ce que fait un agent une fois qu’il agit pour un utilisateur. Le Data Control Plane de Kiteworks applique l’identité, les autorisations et la politique sensible aux données à ce moment précis, et son journal d’audit est inviolable et peut alimenter vos outils SIEM. Le Kiteworks Agent Marketplace illustre ce modèle, avec des agents qui s’exécutent en tant qu’utilisateur demandeur dans Kiteworks.

Il fonctionne en complément de votre IAM, DSPM et DLP, qui conservent leurs rôles. Si vous souhaitez examiner le modèle d’accès avec vos architectes sécurité, réservez une démo personnalisée et nous passerons en revue les contrôles étape par étape.