Politiques contextuelles dans Omnigent : utiliser l'état de session pour mieux gouverner les agents d'IA

Nous avons récemment lancé Omnigent, un méta-harnais open source pour les agents IA. Il vous permet de continuer à utiliser les harnais d'agents que vous appréciez déjà, notamment Claude Code, Codex et des agents personnalisés, tout en ajoutant une couche partagée pour la collaboration, la composition et les politiques.

Pour la sécurité et la gestion des coûts, Omnigent introduit un nouvel outil puissant : les politiques contextuelles. Les frameworks d'agents actuels ne disposent que de contrôles simples pour limiter ce qu'un agent peut faire, par exemple des règles pour autoriser, refuser ou demander l'avis de l'utilisateur pour différents appels d'outils. Mais cela rend difficile la création de politiques qui soient à la fois sécurisées et pratiques pour les utilisateurs. En revanche, les politiques contextuelles d'Omnigent peuvent mémoriser ce qui s'est passé dans une session jusqu'à présent (par exemple, ce que l'agent a lu ou le montant en dollars dépensé jusqu'ici) et utiliser cet état pour décider si l'action suivante doit se poursuivre. Cela permet de mettre en place un large éventail de politiques riches, à la fois plus sûres et plus pratiques pour les utilisateurs : du suivi dynamique du niveau de risque d'une session à la mise en œuvre de modèles de sécurité de moindre privilège, en passant par la possibilité pour les utilisateurs de définir des budgets pour des tâches individuelles afin de gérer les dépenses.

Pourquoi les contrôles d'agents sont plus efficaces avec du contexte

Les agents IA introduisent de nouveaux types de risques pour les entreprises. Par exemple, comme les agents peuvent subir des injections de prompts par du contenu non fiable et être invités à effectuer des actions malveillantes, il est souhaitable d'empêcher le même agent de lire du contenu non fiable, d'accéder à des données sensibles et de communiquer avec le monde extérieur (concept popularisé sous le nom de « Lethal Trifecta » de Simon Willison et de « Agents Rule of Two » de Meta). Le fait qu'une action soit « sûre » dépend, en partie, de ce qui s'est passé auparavant : un agent de codage qui effectue un push vers GitHub ne pose généralement pas de problème si l'agent vient de travailler sur une fonctionnalité pour un développeur, mais ce même push GitHub est risqué si l'agent a préalablement téléchargé une page web non fiable susceptible de contenir une attaque par injection.

Malheureusement, la plupart des logiciels d'agents actuels ne proposent que des contrôles simples basés sur des listes d'autorisation ou des garde-fous sur des actions individuelles, par exemple pour autoriser ou non les pushs Git ou les recherches sur le web. Pour empêcher les attaques par injection, il faudrait bloquer complètement au moins l'une de ces actions, ce qui serait restrictif pour de nombreux cas d'usage inoffensifs. Demander l'approbation de l'utilisateur pour chaque action ne fonctionne pas non plus de manière optimale, car les utilisateurs finissent par se lasser des demandes d'approbation.

Il en va de même dans d'autres situations. Par exemple, qu'un agent d'un commercial envoie un e-mail à un client est tout à fait acceptable, mais qu'il en envoie des milliers peut indiquer une compromission ou un bug. Qu'un agent modifie un document qu'il a créé est correct, mais que ce même agent modifie des milliers de documents internes peut nécessiter un examen attentif. En effet, de nombreux outils de sécurité destinés aux utilisateurs humains prennent également en compte leur historique et pas seulement l'action en cours (c'est ce qu'on appelle la sécurité contextuelle).

Présentation des politiques contextuelles

Dans Omnigent, une politique peut écouter les événements qu'un agent exécute (par exemple, les appels d'outils et les réponses, ainsi que les entrées et sorties du LLM) et décider d'autoriser, de refuser, de transformer les messages ou de demander l'autorisation de l'utilisateur, à l'instar des garde-fous traditionnels des agents. Cependant, la politique peut également mettre à jour l'état de la session : des variables arbitraires visibles uniquement par cette politique. Cela peut inclure le suivi du nombre de fois qu'un agent a utilisé un outil spécifique, les documents qu'il a lus, etc. Le serveur Omnigent mémorise l'état de chaque politique et session et le transmet au gestionnaire de politique lors de son prochain appel. Pour écrire une politique contextuelle, il vous suffit d'écrire une fonction qui prend l'ancien état et le nouvel événement que l'agent tente d'exécuter, et renvoie les mises à jour de l'état ainsi qu'une décision. Omnigent est également fourni avec plusieurs politiques utiles déjà incluses.

De plus, comme Omnigent est un méta-harnais, il peut appliquer vos politiques contextuelles de la même manière aux agents utilisant n'importe quel harnais. Omnigent prend en charge des agents de codage largement utilisés tels que Claude Code, Codex, Antigravity, Pi, OpenCode et Hermes, ainsi que des agents personnalisés dans des frameworks tels que OpenAI Agents SDK et Claude Agents SDK. Lancez simplement les agents via Omnigent, et le serveur Omnigent interceptera leurs appels d'outils pour appliquer les politiques.

Exemples de cas d'usage

Voici les trois exemples de politiques intégrées fournies aujourd'hui avec Omnigent. Chacune repose sur un type d'état de session différent : le contenu que l'agent a lu jusqu'à présent, un score de risque cumulé de la session ou le coût total de la session en cours.

1. Politique Google Drive : limiter l'accès de l'agent aux documents appropriés

La politique Google Drive régit ce que l'agent peut lire et modifier dans Docs, Sheets et Slides. Par défaut, les écritures sont limitées aux documents que l'agent a créés au cours de cette session. Ainsi, un agent peut créer un nouveau document et le modifier librement, mais ne peut pas modifier discrètement un fichier préexistant auquel il n'était pas censé toucher. Ce comportement ne pourrait pas être mis en œuvre avec de simples listes d'autorisation : nous ne voulons pas autoriser ou refuser catégoriquement l'outil « écrire un document », nous voulons uniquement l'autoriser sur les documents que l'agent a créés au cours de la même session.

Comme second exemple de comportement contextuel dans cette politique, vous pouvez marquer un ensemble de documents comme confidentiels : dès que l'agent en ouvre un, la politique se durcit de sorte que les écritures soient limitées à cet ensemble. Même un document que l'agent a créé il y a une minute devient inaccessible, car y ajouter des éléments confidentiels divulguerait ce contenu dans un fichier moins protégé. En sécurité classique, cela met en œuvre le modèle de Bell-LaPadula avec sa règle de « non-écriture vers le bas » (no write-down).

2. Politique de score de risque : redoubler de prudence à mesure que l'agent manipule des éléments sensibles

L'évaluation des risques est couramment utilisée par les équipes de sécurité pour gérer les accès des humains. Dans Omnigent, la politique d'évaluation des risques conserve un score évolutif pour la session en cours, un nombre unique qui suit le niveau de risque accumulé au fur et à mesure que l'agent travaille. Les utilisateurs peuvent configurer quelles actions augmenteront le score et de combien : un appel d'outil de routine peut ajouter un point ou deux, tandis que la lecture d'un document que vous avez marqué comme hautement confidentiel ajoute beaucoup plus de points. Tant que le score reste bas, l'agent travaille sans interruption. Dès qu'il franchit un seuil, des actions comme l'envoi d'un e-mail ou le partage d'un fichier renverront ASK au lieu de ALLOW et inviteront l'utilisateur à valider. Ainsi, le même e-mail qui serait parti au début d'une session peut nécessiter une approbation humaine plus tard, une fois que l'agent a manipulé suffisamment d'éléments sensibles, ce qui fait grimper le score.

3. Politique de coûts : garder les dépenses sous contrôle

Une politique budgétaire suit le montant dépensé par la session pour les appels de modèles jusqu'à présent. Après avoir franchi un premier seuil d'alerte, elle se met en pause pour demander s'il faut continuer. Lorsque les dépenses atteignent la limite stricte, la politique bloque les appels suivants vers le modèle coûteux jusqu'à ce que l'agent passe à un modèle plus économique, ce qui permet à la session de se poursuivre plutôt que de s'arrêter. Cette même idée s'étend au-delà d'une seule session. Une équipe de plateforme peut cumuler un plafond quotidien par utilisateur avec celui par session, afin que personne ne puisse accumuler des coûts sur plusieurs conversations distinctes. Dans les deux cas, le contexte est la dépense cumulative : la politique ne juge pas un appel de modèle individuel ; elle surveille le total cumulé et intervient lorsque la session ou l'utilisateur a trop dépensé.

4. Autorisation basée sur l'intention : limiter les privilèges en fonction de l'objectif

L'autorisation basée sur l'intention définit les autorisations des agents en fonction de la consigne initiale de l'utilisateur, de sorte que même un agent victime d'une injection de prompt ne puisse pas utiliser la plupart de ses outils pour causer des dommages. Par exemple, si vous commencez une session en demandant à un agent de mettre à jour une présentation Google Slides, la politique permet à cet agent de lire et d'écrire sur cette présentation, mais bloque l'accès si l'agent tente soudainement d'utiliser GitHub. La politique mémorise simplement ce que l'utilisateur a réellement demandé au début d'une session sous forme d'état, puis compare chaque appel d'outil à cet objectif initial, en appliquant le principe du moindre privilège. Il s'agit d'une politique très simple mais puissante, rendue possible par l'état contextuel : vous pouvez configurer des agents avec de nombreux outils par défaut, et ils seront automatiquement restreints à chaque session. Le même appel d'outil qui convient dans une session peut nécessiter votre approbation dans une autre, selon ce que vous avez demandé à l'agent de faire.

Ce qu'il faut retenir

À mesure que les agents effectuent des tâches de plus en plus concrètes, la difficulté réside désormais dans la manière de les contrôler. Les agents peuvent commencer à causer des dommages en raison d'entrées malveillantes ou de simples bugs, et les politiques de liste d'autorisation simples qui inspectent les actions individuelles ne sont pas assez flexibles pour rendre les agents à la fois exploitables et sûrs. Les politiques contextuelles permettent d'obtenir des agents à la fois plus exploitables et plus sûrs en suivant de manière dynamique l'état au sein d'une session et en bloquant les actions uniquement lorsque l'agent a accumulé un niveau de risque suffisant. Elles fournissent également un outil simple et puissant pour gérer les budgets au niveau de chaque session, plutôt que de se limiter à un budget quotidien par utilisateur. Omnigent est open source et s'intègre aux agents de codage et aux frameworks d'agents les plus populaires, de sorte que vous pouvez commencer à appliquer ces règles à vos agents existants.

Essayez-le

Omnigent est actuellement disponible en open source en version alpha.

• Démarrez avec notre guide de démarrage rapide : https://omnigent.ai/quickstart/install
• Ajoutez une étoile et clonez le dépôt : https://github.com/omnigent-ai/omnigent
• Suivez le tutoriel sur les politiques : https://omnigent.ai/quickstart/policies
• Consultez la documentation sur les politiques : https://omnigent.ai/docs/policies/overview
• Rejoignez-nous sur Discord : https://discord.gg/omnigent

(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original