Les agents IA ont besoin de plus que des permissions

Un agent peut réussir tous les contrôles d’accès et quand même faire la mauvaise chose

Un agent d’entreprise peut être correctement authentifié, correctement autorisé et tout de même publier les dossiers de rémunération de l’entreprise. Heather Ceylan, directrice de la sécurité des systèmes d’information chez Box, donne l’exemple d’une entité disposant d’un accès légitime aux données de paie et à un dossier partagé public. Box fournit des contrôles de plateforme pour les contenus d’entreprise ; l’entreprise a donc un intérêt commercial à ce que ses clients considèrent ces contrôles comme essentiels à la sécurité des agents. « Un employé ayant accès à des données de paie qu’il n’était jamais censé conserver pourrait recevoir l’instruction d’extraire les dossiers de paie et de les écrire dans un dossier partagé public, publiant ainsi en une seule opération l’ensemble des rémunérations de l’entreprise », explique-t-elle. « Tous les contrôles d’accès ont été validés, mais le comportement a tout de même des conséquences catastrophiques. »

Cette défaillance distingue l’autorisation d’accéder à une ressource de l’autorisation d’exécuter une action particulière. L’identité et les permissions déterminent quelles ressources un agent peut atteindre ; un accès strictement limité reste donc la première couche de défense. Mais dès qu’un agent autonome commence à agir, le système de sécurité doit aussi décider si une opération précise impliquant une ressource accessible est acceptable à cet instant. Ceylan décrit la transition potentielle entre un accès légitime aux données d’entreprise et une action non intentionnelle comme pouvant se produire « en quelques secondes », ce qui reflète la vitesse d’exécution des agents.

Cette distinction modifie la question de sécurité pour les agents IA d’entreprise. Une identité valide et une permission légitime établissent les circonstances dans lesquelles un agent peut interagir avec une ressource. Une décision d’exécution distincte établit quelles actions techniquement possibles sont appropriées dans ces circonstances. Sécuriser l’exécution des agents exige donc des limites successives autour de l’identité et de l’accès, des actions individuelles, du contenu et du comportement en production.

Le moindre privilège doit se resserrer, du workflow jusqu’à l’étape individuelle

La première limite commence par une hygiène d’accès classique, car les agents héritent de toutes les permissions qu’une organisation leur accorde. « Les contrôles d’accès et les permissions sont la base, mais le problème est qu’ils ont été conçus pour des humains », explique Ceylan. Une personne qui conserve l’autorisation d’accéder à un dossier vieux de dix ans a peut-être oublié son existence et ne l’ouvrira peut-être plus jamais. Un agent peut examiner de façon systématique ce que ses permissions attribuées rendent disponible ; un accès obsolète peut donc devenir pertinent pendant l’exécution beaucoup plus vite et à bien plus grande échelle.

Parce que les agents peuvent exploiter systématiquement leurs droits, leurs permissions doivent être plus finement délimitées que les droits permanents généralement accordés à une identité humaine. « Les permissions restent la base, mais il faut aussi réfléchir à la manière dont les permissions des agents sont délimitées », explique Ceylan. Assainir les identités et l’accès aux ressources reste utile, notamment parce qu’une activité systématique des agents peut révéler des erreurs de configuration oubliées. L’exigence supplémentaire consiste à faire en sorte que le privilège suive le travail effectué à un moment précis.

Ce moment compte dans une tâche large qui exige légitimement qu’un agent appelle cinquante outils, réalise vingt actions différentes et lise ou écrive dans des dossiers de plusieurs départements. Donner à l’agent toutes les permissions requises pour l’ensemble de la tâche signifie qu’une erreur à une étape peut mobiliser des privilèges nécessaires seulement bien plus tard. Le workflow complet peut nécessiter un vaste ensemble d’autorisations, alors qu’une opération individuelle n’en requiert qu’un très petit nombre. L’architecture de sécurité doit donc représenter les permissions requises par chaque étape.

« Il faut des permissions qui changent en fonction de ce qu’on a demandé à l’agent de faire, au moment où il doit effectuer cette action », explique Ceylan. Ces permissions évolutives rendent le moindre privilège temporel autant que spécifique à la ressource : l’autorité s’étend pour une étape autorisée puis se rétracte lorsque cette étape n’en a plus besoin. L’identité reste importante, tandis que l’autorité effectivement utilisable suit l’action en cours tout au long du workflow.

L’ampleur de ce changement peut être considérable, même dans le cadre d’une tâche légitime. « S’il exécute une étape et n’a besoin que de deux outils, il ne devrait être limité qu’à ces deux-là. Quand vous restreignez les permissions à la tâche immédiate de l’agent, le nombre de façons dont une étape donnée peut mal tourner diminue d’autant », explique Ceylan. Dans le workflow hypothétique à cinquante outils, une étape à deux outils reçoit une autorité sur deux outils au lieu d’hériter de tout ce qu’une opération ultérieure pourrait exiger.

Cette délimitation au niveau de l’étape met ensuite en évidence la limite des permissions sur les ressources elles-mêmes. Un agent peut légitimement lire et écrire dans un dossier financier, mais ce droit n’établit pas qu’il soit approprié de déplacer quatre mille fichiers ailleurs. À ce stade, la décision de sécurité porte sur l’action, son ampleur et sa destination. Le moindre privilège temporel réduit le rayon d’impact disponible, tandis que la gouvernance de l’exécution décide si la capacité autorisée restante doit être utilisée.

Les contrôles d’exécution doivent résister à ce qui arrive au prompt

Une fois les permissions limitées à une étape, la limite suivante consiste à déterminer si cette étape doit s’exécuter dans les conditions actuelles. Les instructions d’un agent IA peuvent changer, des instructions injectées peuvent entrer dans son contexte, et les fichiers rencontrés pendant le travail peuvent orienter le comportement ultérieur. Malgré tous ces changements, un contrôle de permission peut rester exact, car l’agent peut toujours accéder à une ressource que son identité est autorisée à atteindre. La gouvernance de l’exécution doit donc évaluer l’opération elle-même.

Ce besoin conduit Ceylan à plaider pour des restrictions durables autour des appels d’outils et du contenu affecté par ces appels. Le système peut établir à l’avance quelles opérations un agent est autorisé à exécuter, puis préserver ces limites même si son prompt a été manipulé. Les instructions du prompt continuent de diriger le travail de l’agent, mais la limite de sécurité a besoin d’un point d’application qui reste stable à mesure que ces instructions changent.

Une application stable vaut aussi pour le confinement. Ceylan évoque des incidents « au cours des derniers mois » impliquant des modèles s’échappant des sandbox prévues, atteignant des systèmes hors de leur périmètre ou lisant des contenus non autorisés. Ces incidents rendent le problème architectural concret, car les agents IA d’entreprise peuvent découvrir et exploiter les chemins disponibles dans leur environnement d’exploitation. Les contrôles d’exécution doivent donc continuer à faire respecter les limites là où les outils et les données sont réellement utilisés.

Ces contrôles créent une question d’autorisation distincte pour chaque opération ayant des conséquences. L’accès à la ressource répond à la question de savoir si l’agent peut atteindre un dossier financier ; l’autorisation d’exécution peut décider s’il peut copier un ensemble particulier de fichiers vers une destination particulière pendant la tâche en cours. Sans cette seconde décision, une identité valide et un accès valide à la ressource peuvent exposer implicitement toutes les opérations que ces droits rendent techniquement possibles.

Le risque, la réversibilité et l’observabilité déterminent quand les humains doivent rester dans la boucle

Une fois les opérations individuelles gouvernées, les équipes peuvent décider lesquelles nécessitent une implication humaine directe. Ceylan indique qu’il y a deux ans, on s’attendait à ce que la sécurité des agents exige toujours des humains dans la boucle, mais l’exploitation des agents a changé cette hypothèse chez Box. Box répartit désormais les actions en trois niveaux opérationnels, l’autonomie étant déterminée par les conséquences et la contrôlabilité de l’action. Comme Box fournit les contrôles utilisés pour mettre en œuvre ce modèle opérationnel, l’entreprise en tire un bénéfice commercial lorsque les clients adoptent cette approche.

Le niveau autonome repose sur plusieurs contrôles fonctionnant ensemble. Le caractère borné limite ce qu’une action peut affecter, la journalisation rend l’opération visible, et des entrées fiables réduisent la probabilité qu’un contenu hostile oriente l’exécution. La réversibilité modifie la décision opérationnelle, car une erreur qui peut être annulée de manière fiable n’a pas les mêmes conséquences qu’une erreur dont les effets sont permanents. Le coût d’une erreur doit aussi rester acceptable pour l’équipe qui exploite l’agent.

Ces contrôles peuvent soutenir la supervision à mesure que les preuves opérationnelles s’accumulent. Une fois qu’une équipe a suffisamment confiance dans un agent, les alertes peuvent identifier une défaillance tandis que le rollback offre un moyen de l’annuler. L’implication humaine passe alors de l’approbation préalable de chaque opération à la supervision d’un système dont les erreurs peuvent être détectées et inversées. Cette organisation dépend du fait que l’action reste adaptée à une intervention après le début de son exécution.

Le niveau de risque le plus élevé modifie la décision, car le rollback ne peut pas rendre chaque action sûre. Si un agent propose de supprimer un grand nombre de fichiers ou d’effacer le dossier principal d’une structure, Box considère ce type d’opération irréversible comme nécessitant l’intervention d’une personne. Un point de contrôle humain a le plus de valeur lorsque les conséquences le justifient et que l’automatisation ne peut pas fournir de voie de récupération fiable.

Ces conséquences varient selon la charge de travail ; les limites entre niveaux sont donc contextuelles. Ceylan explique que les équipes doivent calibrer les niveaux en fonction de leur propre tolérance au risque, car le coût acceptable, le périmètre et la réversibilité d’une erreur dépendent de la charge de travail. Les équipes classent donc une action précise selon ses entrées, ses limites, sa supervision, sa capacité de récupération et ses conséquences lorsqu’elles décident du degré d’autonomie à lui accorder.

Cette classification peut commencer avant l’action finale, car Box place des contrôles dans sa plateforme. Les protections de la plateforme incluent la classification des données, l’étiquetage et l’expiration, ce qui permet à la politique de contraindre les conditions dans lesquelles un agent opère. « La bonne configuration doit être appliquée dès le départ, au lieu de bloquer une action à la fin », explique Ceylan. La gouvernance peut donc façonner les conditions d’exécution avant qu’une opération à fortes conséquences ne soit tentée.

Les principes de travail plus larges de Box prolongent le même modèle au moyen d’identités et d’actions strictement limitées, d’attentes explicites en matière de rollback, de trois niveaux d’approbation, ainsi que de tests et d’itérations rapides. Ce sont les principes opérationnels de Box, et Box a un intérêt commercial dans leur application via la plateforme. Dans ce modèle, la réversibilité et l’observabilité peuvent soutenir l’autonomie pour un travail borné, tandis que des conséquences irréversibles déclenchent une revue directe.

La couche de contenu fait partie de la limite de sécurité de l’agent

Ces décisions d’exécution dépendent des systèmes qui détiennent les informations utilisées par un agent. « Chaque action d’un agent se résout finalement en contenu », explique Ceylan. Pour qu’une couche d’application puisse déterminer si une action est appropriée, l’environnement de contenu doit fournir des métadonnées, une classification, une propriété et des informations contextuelles que la politique peut évaluer. Il doit aussi fournir des journaux suffisamment détaillés pour établir ce à quoi l’agent a effectivement accédé et ce qu’il a fait.

Cette dépendance crée une limite difficile pour les anciennes infrastructures d’entreprise. Les contenus d’entreprise tels que les contrats, les politiques et les dossiers clients peuvent être répartis entre des lecteurs réseau, des plateformes vieillissantes d’enterprise content management (ECM) et des outils SaaS conçus autour du classement humain et des permissions de dossiers. Certains de ces référentiels portent des permissions non auditées depuis des années tout en manquant des métadonnées et de la classification nécessaires à une application plus riche, ou de journaux suffisamment détaillés pour montrer ce qu’un agent a lu. Leurs propriétés de gouvernance existantes deviennent donc une partie de l’environnement de sécurité de l’agent.

Un connecteur IA hérite de ces propriétés lorsqu’il relie un agent à un référentiel legacy. L’agent reçoit un accès via les contrôles et les informations que ce référentiel fournit déjà, y compris des permissions obsolètes au niveau des dossiers et une faible visibilité lorsque ces conditions existent. Il peut ensuite exercer ces permissions héritées à la vitesse de la machine. Les organisations dont les systèmes de contenu ne disposent pas des métadonnées, du contexte de propriété, de la classification et de la journalisation requis se heurtent donc à une limite structurelle quant au degré de mise en œuvre d’une politique d’exécution sensible aux étapes.

Ceylan formule cette dépendance en termes explicites : « Si la couche de contenu ne peut pas vous dire ce qu’elle contient, à qui cela appartient et ce qui ne doit jamais en sortir, il n’y a rien sous vos contrôles. » Une politique d’appel d’outils peut limiter une opération, mais une application sensible au contenu exige que le référentiel sous-jacent fournisse suffisamment d’informations pour évaluer le contenu concerné. La gouvernance s’étend donc à l’architecture de contenu et relie le runtime de l’agent aux systèmes qui détiennent les informations de l’entreprise.

Ce lien est également étroitement aligné sur l’activité de Box, puisque Box fournit les capacités de plateforme de contenu que décrit Ceylan. Pour les architectes sécurité, la tâche pratique consiste à examiner les référentiels eux-mêmes : si le contenu peut être classifié, si la propriété peut être établie, si les restrictions peuvent être appliquées et si les lectures peuvent être observées avec un niveau de détail suffisant. La visibilité comportementale doit en fin de compte exister là où le contenu existe, car c’est là qu’un appel d’outil autorisé de l’agent devient une opération concrète sur les données d’entreprise.

La confiance envers un agent doit être observée dans le temps, y compris entre agents

Une fois que ces opérations concrètes entrent en production, la décision de sécurité ne consiste plus seulement à contrôler une action, mais aussi à comprendre comment l’agent se comporte dans le temps. Ceylan soutient que la confiance doit se construire en observant comment un agent s’exécute, collabore et utilise les résultats générés par d’autres agents. Une décision d’accès peut être prise à un instant donné, tandis que la confiance dans le comportement dépend de preuves accumulées pendant l’exploitation. La journalisation fournit l’historique nécessaire pour construire cette confiance.

Cette dépendance à l’historique crée un problème immédiat pour les systèmes expérimentaux. Beaucoup d’agents commencent comme des tests, et leurs actions peuvent ne jamais atteindre l’infrastructure de journalisation d’une organisation. Sans ces enregistrements, les équipes perdent l’historique comportemental nécessaire pour déterminer si le fonctionnement reste dans les limites attendues. La couche de supervision doit donc couvrir l’expérimentation suffisamment tôt pour fournir des preuves utiles aux décisions de confiance ultérieures.

Une fois que la journalisation couvre ces systèmes, l’analytique comportementale doit reposer sur des attentes adaptées aux agents. Les outils d’analyse du comportement des utilisateurs et des entités établissent généralement des références autour de l’activité humaine, alors qu’un comportement suspect d’agent peut avoir une forme et un rythme différents. La supervision des agents a donc besoin de références dérivées du fonctionnement des agents. Ces références donnent aux équipes un point de comparaison pour identifier des changements significatifs dans le comportement automatisé.

Le comportement mesuré peut aussi s’étendre à plusieurs agents et systèmes. Un agent peut produire un résultat qui devient l’entrée d’un autre agent, créant une chaîne dont les étapes individuelles peuvent sembler ordinaires lorsqu’elles sont considérées séparément. Ceylan indique que les détections pour ces schémas sont encore en cours de conception, ce qui fait des chaînes d’activité intersystèmes un problème de supervision important. Les contrôles d’accès restent nécessaires à chaque limite, tandis que la visibilité comportementale révèle ce que ces entités autorisées séparément font réellement ensemble au fil du temps.

Les contrôles de sécurité ne fonctionnent que si le parcours gouverné reste utilisable

La visibilité intersystèmes devient plus difficile lorsque l’expérimentation se déroule en dehors de l’environnement gouverné. Les équipes doivent toujours tester et itérer, et Ceylan explique qu’un environnement approuvé doit permettre ce travail au rythme exigé par les développeurs. « Le parcours approuvé doit être le parcours le plus rapide, car lorsque les équipes ne disposent pas d’un moyen sûr d’expérimenter, elles ont tendance à contourner complètement les contrôles », explique-t-elle. Les agents développés en dehors de ce parcours peuvent aussi rester en dehors de la journalisation nécessaire pour établir leur future référence comportementale.

Ce lien fait de la vitesse de déploiement une composante de l’architecture de sécurité, car les contrôles ne peuvent gouverner que l’activité que les équipes font effectivement passer par l’environnement contrôlé. Des permissions strictes au niveau de l’étape, une politique d’exécution, une application sur le contenu, le rollback et la supervision dépendent tous du fait que les équipes maintiennent les expérimentations et les agents de production sur ce parcours. « Le rôle d’un responsable sécurité est d’offrir un moyen d’avancer vite sans sortir des garde-fous », explique Ceylan. Le parcours gouverné doit donc permettre des tests et des itérations rapides afin que ces contrôles restent attachés à l’agent, de l’expérimentation jusqu’à l’exploitation.

Réflexions finales

Pour les dirigeants, l’implication centrale est que la gouvernance des agents IA ne peut pas s’arrêter à la gestion des identités et des accès. Un agent peut avoir la bonne identité, les bonnes permissions et une tâche métier légitime tout en exécutant une action que l’organisation n’a jamais eu l’intention d’autoriser. À mesure que les agents accèdent à davantage d’outils et de données d’entreprise, cette distinction devient plus lourde de conséquences.

Le modèle opérationnel doit donc gouverner l’autorité au niveau où le travail s’effectue. Les permissions doivent se resserrer sur l’étape en cours, les actions les plus risquées doivent faire l’objet de contrôles d’exécution plus stricts, et l’approbation humaine doit être réservée aux conséquences qui ne peuvent pas être limitées, observées ou inversées de manière fiable. La classification du contenu et la journalisation deviennent également des infrastructures de base, car les politiques ne peuvent pas prendre de décisions sensibles au contexte sans savoir quelles données un agent manipule.

Pour les dirigeants d’entreprise, cela fait de l’autonomie des agents une décision de gestion du risque plutôt qu’un choix binaire entre automatisation et supervision humaine. Les organisations peuvent accorder davantage d’autonomie lorsque les actions sont limitées, observables et réversibles, tout en maintenant des contrôles plus stricts autour des travaux irréversibles ou à fortes conséquences. Cette approche peut préserver la rapidité promise par les agents sans considérer un accès valide comme la preuve que chaque action autorisée est sûre.