Obsidian Security lance un moteur de décision des politiques à l’exécution pour contrôler les actions des agents IA

Obsidian Security a lancé un moteur de décision des politiques à l’exécution conçu pour permettre aux entreprises de contrôler ce que font les agents IA dans les applications professionnelles avant l’exécution d’une action. Cette annonce enrichit la plateforme de sécurité des agents de l’entreprise avec un proxy de sécurité MCP, une API de décision des politiques et une prise en charge étendue des outils de programmation et des agents intégrés à des logiciels tiers.

Ce lancement répond à un problème que les contrôles d’accès classiques ne résolvent pas entièrement : un agent peut disposer d’identifiants valides et utiliser une application approuvée tout en tentant une action inappropriée. L’autorisation de consulter des dossiers clients ne signifie pas nécessairement que l’agent est autorisé à les exporter vers une destination externe.

L’approche d’Obsidian consiste à évaluer l’action proposée au regard de politiques gérées de manière centralisée, en tenant compte de la personne à l’origine de l’agent, de son emploi et de ses autorisations, de l’application concernée et des classifications de données fournies par le client. Les points de contrôle intégrés permettent ensuite d’autoriser ou de bloquer l’action, ou d’exiger une approbation lorsque cette fonctionnalité est prise en charge.

De la découverte des agents au contrôle de leurs actions

La découverte des agents permet de savoir quels outils sont présents et à quelles ressources ils peuvent accéder. La gouvernance peut réduire les autorisations superflues ou repérer les configurations à risque. Les politiques à l’exécution répondent à la question qui reste : que doit-on permettre à un agent par ailleurs autorisé de faire à cet instant ?

L’annonce d’Obsidian concerne à la fois les agents utilisés par les employés et ceux intégrés aux logiciels déjà employés par l’entreprise. Ses capacités étendues de découverte et de gouvernance couvrent notamment Salesforce Agentforce, Databricks, GitHub, Microsoft 365, Snowflake, ServiceNow et Workday.

Il s’agit de points de contrôle différents. Repérer un agent dans une application SaaS ne signifie pas, à lui seul, que toutes les actions effectuées dans cette application sont interceptées. Le contrôle à l’exécution dépend de l’intégration prise en charge et du point de passage de l’action.

L’entreprise a également ajouté la prise en charge des politiques à l’exécution pour OpenAI Codex, en complément de ses contrôles existants sur les agents de programmation. Son annonce met en évidence des risques tels que les commandes destructrices, l’exposition d’identifiants et les lectures dépassant le périmètre prévu d’un projet — des actions susceptibles de survenir au cours d’une session de développement par ailleurs légitime.

Le Knowledge Graph fournit le contexte manquant

Une passerelle peut examiner une requête, mais celle-ci ne suffit pas toujours à expliquer les pouvoirs dont dispose son auteur. Pour prendre une décision de sécurité pertinente, il peut être nécessaire de savoir si le compte à l’origine de la requête appartient à un employé ou à un prestataire, si la relation de travail a pris fin et quelles autorisations le compte détient réellement dans l’application de destination.

L’architecture Knowledge Graph d’Obsidian relie les personnes, les comptes, les applications, les jetons, les droits d’accès et les relations entre ces éléments. L’entreprise explique qu’elle normalise les informations provenant des API d’administration, des flux d’activité et des intégrations dans un modèle commun, avec des entités et des relations versionnées pour suivre leur évolution au fil du temps.

Cette structure permet de retracer les accès dans plusieurs systèmes, plutôt que d’examiner chaque compte isolément. Le rôle apparent d’un agent peut être limité, alors qu’un jeton ou un droit hérité lui donne une portée plus large ailleurs. La mise en relation de ces éléments donne au moteur de décision des politiques une base plus solide pour déterminer si une action donnée est conforme aux règles de l’organisation.

Les clients peuvent ajouter leur propre contexte, notamment des étiquettes de classification. Une politique peut ainsi distinguer un fichier ordinaire d’un fichier que l’entreprise considère comme hautement sensible, au lieu de s’appuyer uniquement sur la définition générique des données confidentielles établie par un fournisseur de solutions de sécurité.

Du processus de décision au contrôle effectif

L’architecture sépare la prise de décision de l’exécution de l’action. Dans son explication du moteur à l’exécution, Obsidian indique qu’un point de contrôle met en pause une opération proposée, en soumet les détails à évaluation, puis applique la décision et le motif retournés.

La nouvelle API de décision des politiques étend ce modèle aux passerelles exploitées par les clients, aux environnements d’exécution des agents et aux flux de travail. Une entreprise peut conserver son infrastructure existante tout en demandant à Obsidian une décision tenant compte du contexte. Le composant de contrôle du client doit ensuite appliquer cette décision avant que l’opération ne se poursuive.

Obsidian décrit également un mode de signalement permettant de tester les correspondances avec les politiques sur du trafic réel avant de bloquer des opérations. Les enregistrements de décision consignent l’agent, la personne à l’origine de la requête, l’outil, les arguments, le résultat et la politique correspondante, afin que les équipes de sécurité puissent déterminer pourquoi une action a été autorisée ou bloquée.

La prise en charge des approbations est plus limitée que l’architecture générale d’autorisation ou de blocage : selon la documentation actuelle de l’entreprise, l’approbation obligatoire est disponible pour les politiques Claude Code exécutées avant une opération. Il est donc important de tenir compte des fonctionnalités propres à chaque intégration lors de la conception des contrôles pour un parc d’agents hétérogène.

Le proxy MCP empêche les clients IA d’accéder aux jetons des applications

Le proxy de sécurité MCP régit les connexions entre les clients d’IA et les applications métier prises en charge. Le Model Context Protocol, ou MCP, fournit aux agents une méthode standard pour appeler les outils exposés par des serveurs externes. Obsidian place un contrôle de stratégie entre le client et le serveur MCP de l’application.

La documentation de son produit indique qu’il faut remplacer l’URL MCP directe du fournisseur par un point de terminaison régi par Obsidian. Les utilisateurs autorisent l’accès au moyen du processus de consentement du fournisseur de l’application ; le client d’IA reçoit un jeton émis par le proxy au lieu de stocker lui-même le jeton d’accès à l’application.

Le proxy associe une session à l’utilisateur, à son compte dans l’application et au locataire concerné, par exemple une organisation ou un espace de travail Salesforce donné. Il vérifie les appels d’outils avant de les transmettre et consigne s’ils ont été autorisés ou bloqués. Selon Obsidian, le dispositif respecte les autorisations dont l’utilisateur dispose déjà dans l’application, sans lui accorder de privilèges supplémentaires par l’intermédiaire d’un compte de service partagé.

L’annonce fait également état d’une collaboration avec Cloudflare et son MCP Server Portal. L’objectif est de combiner la position d’une passerelle sur le chemin du trafic avec les informations d’Obsidian sur l’identité, les applications et les données.

Pourquoi les contrôles au niveau des actions sont importants

Pour les entreprises qui déploient des agents, le défi pratique consiste à leur permettre d’effectuer des tâches utiles tout en limitant les erreurs lourdes de conséquences. Une interdiction générale peut bloquer entièrement un processus ; une décision ciblée peut autoriser les consultations courantes tout en empêchant une exportation non autorisée ou en exigeant une vérification avant une modification destructive.

Obsidian intègre ces décisions à une couche de stratégie commune couvrant les outils et les points de contrôle pris en charge. La valeur de cette approche dépendra de la qualité des informations d’accès sous-jacentes et de l’exhaustivité des chemins soumis au contrôle. À mesure que les agents assument davantage de responsabilités opérationnelles, la capacité à expliquer et à faire appliquer une décision avant son exécution devient un élément de plus en plus important de la sécurité des entreprises.