Comment contrôler les agents IA au moment où ils agissent

Les agents d’IA peuvent désormais planifier, décider et agir sur plusieurs systèmes sans attendre qu’une personne approuve chaque étape. La question d’architecture devient donc concrète : lorsqu’un agent tente une action en dehors de son autorité, quel système peut réellement l’arrêter ? EDB propose de placer l’autorité finale dans des contrôles au niveau de la couche de données opérationnelles, où l’accès peut être évalué et refusé au moment où l’action se produit. EDB a un intérêt commercial à ce que les entreprises adoptent l’approche par couche de données qu’elle propose ; ses affirmations sur les bénéfices de cette architecture doivent donc être lues dans ce contexte.

L’autonomie des agents change le point où la gouvernance doit s’appliquer

Des agents plus autonomes modifient le moment où la gouvernance doit intervenir, car les organisations restent responsables des agents exécutés sur leurs modèles, leur infrastructure et leurs données. Une règle documentée pour un examen ultérieur ne peut pas empêcher une action déjà effectuée, tandis qu’exiger une décision humaine avant chaque action supprime une grande partie de l’autonomie que le système a été conçu pour offrir. La gouvernance doit donc fonctionner dans le contexte immédiat d’une requête et avoir autorité sur le fait qu’elle se poursuive ou non.

Cette exigence de temporalité transforme des idées générales sur le comportement responsable des agents en limites système précises. Une organisation doit décider jusqu’où un agent peut aller, à quelles données il peut accéder, ce qu’il peut modifier, quelles opérations exigent une escalade et comment un incident pourra ensuite être reconstitué. À mesure que les systèmes agentiques gagnent en capacités et en autonomie, ces décisions prennent davantage d’importance, car une part croissante de l’exécution se déroule sans approbation humaine individuelle.

Ces limites n’ont d’importance que si un système peut les faire respecter. Des instructions peuvent indiquer à un agent ce qu’il doit faire, et la supervision peut révéler son comportement, mais un contrôle de production doit pouvoir arrêter une opération non autorisée au moment où l’agent la tente. EDB soutient que cette décision finale doit intervenir au niveau de la couche de données, à l’aide de contrôles qui évaluent l’identité et le contexte associés à l’action.

Des agents probabilistes ne peuvent pas constituer le point final d’application des règles

Placer l’application des règles au niveau de la couche de données répond à une propriété fondamentale des agents autonomes : leur comportement est probabiliste. Les instructions, les politiques et la supervision peuvent influencer et observer ce comportement, mais le contrôle final dépendrait alors du fait que l’agent se comporte de manière suffisamment prévisible pour faire respecter ses propres limites. L’autonomie rend cette dépendance plus difficile à accepter, car un agent autonome est autorisé à sélectionner des actions au lieu de suivre une séquence entièrement prédéterminée.

La vitesse d’exécution rend le problème plus difficile. EDB affirme que les agents peuvent agir « en millisecondes » et opérer simultanément sur de nombreux systèmes ; une gouvernance fondée sur une revue humaine avant l’action ne peut donc pas suivre ce modèle d’exécution. Un agent peut interroger des données, les récupérer, les transformer et, de plus en plus, agir sur cette base avant qu’une personne puisse examiner chaque décision intermédiaire.

Une interdiction d’accès montre ce qu’exige une application finale des règles. Dire qu’un agent ne doit jamais accéder à une catégorie particulière de données a une portée pratique lorsque le système qui reçoit la requête peut la rejeter. Si la base de données applique la politique d’accès, l’autorisation devient une propriété du système qui détient les données. Lorsque la conformité dépend uniquement du fait que l’agent obéisse à une instruction, son comportement probabiliste reste une partie de la frontière de sécurité.

Séparer ces responsabilités permet au raisonnement probabiliste et à l’application déterministe des règles de coexister. Un agent peut raisonner de manière probabiliste sur l’opération qui lui permettra d’atteindre son objectif, tandis qu’un système sous-jacent prend une décision d’autorisation définitive sur l’opération demandée. La gouvernance peut alors contrôler l’action qui en résulte, même lorsque le raisonnement ayant produit la requête était difficile à prévoir.

Cette décision d’autorisation a néanmoins besoin de contexte, car les circonstances peuvent modifier l’action autorisée. La politique doit donc disposer de suffisamment d’informations sur le contexte d’une action pour déterminer si elle est autorisée à cet instant. Le défi architectural consiste à représenter ce contexte sous une forme qu’un système d’application des règles peut évaluer tant que l’opération peut encore être arrêtée.

Les nouvelles entrées sont l’identité de l’agent et l’objectif déclaré

Déplacer l’autorité dans la couche de données impose que la sécurité existante des bases de données prenne en compte les agents autonomes. La proposition d’EDB adapte des contrôles que de nombreuses entreprises exploitent déjà : le contrôle d’accès basé sur les rôles (RBAC), le contrôle d’accès basé sur les attributs (ABAC), la sécurité au niveau des lignes et des colonnes, la classification des données, le masquage, les politiques sous forme de code et des pistes d’audit complètes. Le changement est que ces mécanismes doivent comprendre l’agent participant à une requête.

Cette compréhension commence par la gestion des identités, qui traite l’agent comme un principal, une entité dotée de sa propre identité que les systèmes d’autorisation peuvent reconnaître. L’agent entre ainsi dans le même processus de politique applicable que les autres principaux et reste visible indépendamment de la connexion applicative qui transporte sa requête. Son autorisation peut alors être évaluée au moment de la requête par rapport aux contrôles qui protègent déjà les données sous-jacentes.

L’identité établit qui est l’agent, tandis que l’objectif déclaré ajoute pourquoi il accède aux données. EDB propose de déclarer cet objectif au début d’une session et de l’associer à l’identité de l’agent, faisant de l’objectif un autre attribut de politique aux côtés d’informations telles que le rôle et le département. Le contexte devient opérationnel parce que le moteur de politique reçoit une raison déclarée pour la session et peut l’utiliser pour décider si l’accès est autorisé.

L’objectif doit aussi rester relié à la personne à l’origine de la tâche. Un agent peut exécuter une requête de base de données sous sa propre identité machine tout en effectuant un travail pour une personne donnée, et la conservation des deux identités renforce le contexte d’autorisation et la responsabilité ultérieure. Un enregistrement peut conserver l’agent, l’humain ou l’autre utilisateur pour lequel il a agi, son objectif déclaré et l’opération sur les données qui a suivi.

Priyanka Jain, vice-présidente, gestion produit, gouvernance des données & de l’IA, EDB, décrit l’objectif comme l’ajout qui rend les mécanismes de politique existants conscients des agents : « L’objectif déclaré est ce qui fait la différence. Il devient un attribut que la couche d’accès comprend déjà, évalué dans le même chemin de politique que le rôle et la sécurité au niveau des lignes. Le mécanisme d’application des règles ne change pas. Ce qui change, c’est que l’objectif de l’agent fait partie de ce qu’il évalue, et de ce que l’enregistrement prouve ensuite. »

La description de Jain relie ces nouvelles entrées à des primitives d’application des règles familières. L’agent dispose d’une identité de premier ordre, l’objectif est déclaré à l’ouverture de la session, l’utilisateur agissant est conservé lors du transfert, et la politique évalue ces informations là où une opération peut encore être refusée. Cette combinaison constitue le mécanisme derrière l’affirmation d’EDB selon laquelle une plus grande autonomie des agents peut s’appuyer sur une stack de gouvernance existante adaptée au contexte des agents.

Neuf contrôles transforment le principe en système applicable et démontrable

EDB transforme cette architecture en neuf contrôles organisés autour de trois impératifs : appliquer la politique, produire des preuves de ce qui s’est passé et rendre les contrôles robustes et portables. Ces groupes fonctionnent comme une séquence, car empêcher une requête interdite traite l’action immédiate, tandis que la gouvernance de production doit aussi expliquer ensuite les actions de l’agent et préserver la politique à mesure que les workloads se déplacent entre environnements de déploiement.

Le premier impératif détermine ce qu’un agent peut réellement faire. Les contrôles d’accès basés sur les rôles et les attributs prennent des décisions d’autorisation lorsque des agents et des utilisateurs émettent des requêtes, tandis que le masquage dynamique des colonnes utilise le même chemin de politique pour déterminer quelles valeurs ils peuvent voir. La classification, l’identité et l’objectif peuvent ainsi produire différentes vues ou opérations autorisées via des contrôles appliqués par le système de données.

Au sein de ce groupe d’application, l’identité d’agent de premier ordre fournit le contexte spécifique à l’agent décrit plus haut. L’agent déclare son objectif à l’ouverture de la session, et le système conserve l’identité de l’utilisateur pour lequel il agit. Ces entrées permettent au chemin d’autorisation d’évaluer l’acteur machine et sa raison déclarée d’accès avant l’exécution de l’opération sous-jacente sur les données.

Une fois que l’application des règles peut identifier l’acteur et le contexte, la politique doit aussi comprendre les données concernées. Cette exigence conduit au deuxième impératif d’EDB : voir et prouver ce qui s’est passé. La classification et l’étiquetage identifient les données dans des termes qu’une politique peut évaluer, donnant à la politique des informations sur les données elles-mêmes. Ces classifications peuvent ensuite contribuer aux décisions d’accès et de masquage lorsqu’un agent demande des informations particulières.

Ce même contexte doit survivre à l’exécution, ce qui est le rôle de l’audit au niveau de la session. Pour l’activité des agents, le framework d’EDB enregistre quel agent a agi, pour quel utilisateur il a agi et sous quel objectif déclaré la session a fonctionné. L’enregistrement qui en résulte relie une opération de base de données aux identités et à l’intention associées à la session qui l’a produite.

La traçabilité prolonge cette preuve au-delà de l’opération individuelle et à travers les pipelines. Un résultat peut apparaître après que l’information a traversé plusieurs étapes de traitement ; reconstituer l’événement final exige donc un lien avec la requête d’origine. Le contrôle de traçabilité d’EDB vise à préserver ce lien, permettant à une organisation de retracer un résultat à travers le chemin de traitement qui l’a généré.

Ensemble, l’audit et la traçabilité définissent ce que signifie « auditable » pour un agent autonome dans le framework d’EDB. L’organisation a besoin d’une chaîne de preuve reliant l’identité de l’agent, l’utilisateur agissant, l’objectif déclaré, les données consultées, la traçabilité ultérieure et le résultat produit. Cette chaîne répond aux questions qu’une équipe sécurité ou risque posera après un incident : qu’a fait l’agent, à quoi a-t-il accédé, pour qui agissait-il et qu’est-ce qui en a résulté ?

Après l’application des règles et la preuve, le dernier impératif traite de la capacité des contrôles à résister aux contraintes réelles de déploiement. La gestion centralisée et portable des politiques fournit un moyen de gérer les règles entre environnements, tandis que le chiffrement protège les données à la fois au repos et lors de leur circulation entre systèmes. Une application cohérente étend ensuite la même exigence de gouvernance aux déploiements on-premises, cloud, souverains et isolés du réseau, rendant les contrôles applicables à différents modèles d’hébergement.

Ces neuf contrôles donnent une forme opérationnelle au modèle d’agent gouverné d’EDB. L’identité et le périmètre de l’agent alimentent l’autorisation et le masquage, son activité entre dans les enregistrements d’audit, et les logs ainsi que la traçabilité conservent les preuves pour une reconstitution ultérieure. Dans ce modèle, la gouvernance couvre à la fois la décision prise avant l’accès et l’enregistrement utilisé pour comprendre ce qui s’est passé ensuite.

Le contrôle au niveau de la couche de données compte surtout lorsque le contrôle de l’environnement compte

L’exigence de portabilité devient particulièrement déterminante pour les organisations qui ont besoin d’une autorité sur l’infrastructure elle-même. EDB fonde son approche sur Postgres open source et soutient que cette base permet aux entreprises de contrôler où résident les données, qui peut y accéder et quelle politique s’applique. Pour une organisation opérant on-premises, dans un environnement souverain ou dans un déploiement isolé du réseau, la gouvernance au niveau de la couche de données maintient ces décisions dans une infrastructure que l’organisation peut posséder et inspecter.

À partir de cet argument d’infrastructure, EDB formule une affirmation plus forte pour les secteurs réglementés : la souveraineté des données combinée à une application des règles au niveau du source est une condition préalable à la mise en production des agents. Selon EDB, l’application des règles doit accompagner l’architecture des données à travers les environnements on-prem, cloud, souverains et isolés du réseau. Les équipes sécurité, risque et direction peuvent alors évaluer le modèle opérationnel des agents tout en conservant la gouvernance sur une infrastructure sous leur contrôle.

Ce modèle opérationnel place un périmètre défini autour de l’action autonome. Les équipes définissent ce qu’un agent peut atteindre et modifier, quand une escalade est requise et quelles preuves seront disponibles après une défaillance. EDB soutient qu’un agent opérant à l’intérieur de ces limites peut recevoir une plus grande autonomie, car les systèmes sous-jacents restent capables de faire respecter les limites indépendamment de son comportement.

Ces limites définies soutiennent également l’affirmation plus large d’EDB sur l’adoption, dont l’entreprise peut tirer un bénéfice commercial. EDB présente l’application des règles au niveau de la couche de données comme un moyen pour les entreprises d’avancer plus vite avec l’IA, parce que les équipes sécurité, risque et direction peuvent faire confiance au modèle opérationnel sous-jacent à l’agent. Selon ce raisonnement, les organisations peuvent autoriser davantage d’autonomie tout en laissant au système de données sous-jacent la responsabilité de faire respecter les limites d’accès.

Ce que l’architecture établit

L’affirmation plus large d’EDB sur l’adoption découle d’un mécanisme technique plus précis. Les agents autonomes peuvent produire un comportement imprévisible et agir plus vite qu’une revue humaine, tandis que les systèmes de couche de données peuvent prendre des décisions d’autorisation lorsque ces actions atteignent des données protégées. Le framework à neuf contrôles précise ensuite comment l’identité, l’objectif, l’application des politiques, l’audit, la traçabilité, le chiffrement et la portabilité du déploiement s’articulent autour de ces décisions.

Le mécanisme explique aussi le rôle de l’évolution des circonstances. Un scénario de règle contextuelle utilisé pour montrer pourquoi les circonstances influencent une décision illustre la nécessité pour la politique de recevoir suffisamment de contexte pour évaluer une opération au moment de l’action. Dans la conception d’EDB, l’identité de l’agent et l’objectif déclaré fournissent une partie de ce contexte, tandis que les classifications et d’autres attributs de politique déterminent la manière dont le système de données répond.

Une plus grande autonomie rend donc plus nette une décision que les équipes d’ingénierie et de gouvernance doivent prendre : quel composant détient l’autorité finale lorsqu’un agent demande une opération ? La réponse d’EDB consiste à rendre cette autorité exécutable dans le système de données, avec l’identité de l’agent et l’objectif déclaré mis à la disposition de la politique au moment de l’action. Le caractère applicable de cette limite est une propriété architecturale que les équipes peuvent évaluer directement, tandis qu’une adoption plus rapide par les entreprises reste, selon EDB, la conséquence de cette conception.

Points clés

• Placer l’application des règles là où les actions se produisent : Les équipes sécurité et données peuvent gouverner les agents autonomes au niveau de la couche de données, où les politiques d’accès peuvent approuver ou refuser les opérations au moment de l’exécution. Cela préserve l’autonomie tout en maintenant des limites applicables autour des données protégées.
• Séparer le raisonnement de l’agent de l’autorisation : Le comportement probabiliste de l’IA fait de l’agent lui-même un point final d’application des règles peu fiable. Les équipes d’architecture peuvent placer une autorisation déterministe sous les agents afin que les opérations demandées restent soumises à une politique applicable.
• Donner aux agents une identité et un objectif : Les équipes identité peuvent traiter chaque agent comme un principal distinct et associer son objectif déclaré ainsi que l’utilisateur agissant à la session. Ces attributs donnent aux contrôles d’accès le contexte nécessaire à l’autorisation et à la responsabilité.
• Construire ensemble l’application des règles et la preuve : Les neuf contrôles d’EDB combinent contrôle d’accès, masquage, identité, classification, audit, traçabilité, politique portable, chiffrement et application cohérente. Les équipes sécurité peuvent utiliser ce modèle pour relier les décisions d’exécution aux preuves montrant qui a agi, pour qui, pourquoi et avec quel résultat.
• Préserver la gouvernance entre les environnements de déploiement : Les organisations opérant entre des environnements cloud, on-premises, souverains ou isolés du réseau ont besoin de politiques qui se déplacent de manière cohérente avec leur architecture de données. Les équipes infrastructure peuvent évaluer si les contrôles restent applicables à mesure que les workloads passent d’un environnement à l’autre.
• Définir qui détient l’autorité finale : Les équipes d’ingénierie et de gouvernance doivent identifier quel système peut réellement arrêter une opération non autorisée d’un agent. Le modèle d’EDB attribue cette autorité à la couche de données, en utilisant l’identité, l’objectif et le contexte de politique pour prendre la décision au moment où l’accès se produit.