Comment encadrer les actions des agents IA en entreprise

L’approbation de Claude crée une deuxième décision de sécurité

L’utilisation approuvée de Claude par un développeur peut donner à un agent IA l’autorisation de lire du code privé, d’accéder à des identifiants, de modifier des fichiers et d’exécuter des commandes. Ces autorisations créent une deuxième décision de sécurité : comment gouverner l’autorité déléguée de l’agent, y compris les ressources auxquelles il peut accéder et les actions qu’il peut effectuer. Un agent peut rester dans le cadre de ses autorisations tout en exposant des données ou en endommageant des systèmes ; l’approbation de l’application laisse donc sans réponse des questions importantes sur son comportement.

Palo Alto Networks relie cette question de sécurité à son partenariat avec Anthropic, à son utilisation interne de Claude et à l’approche de sécurité qu’il propose dans « Securing the AI Systems of Tomorrow ». L’entreprise commercialise les produits de sécurité qu’elle recommande et en tire un bénéfice commercial lorsque les entreprises adoptent ces contrôles. Elle affirme que 95 % des entreprises du Fortune 500 s’appuient sur elle pour protéger leurs activités, ce qui mesure son empreinte dans le monde de l’entreprise. Ses recommandations portent sur la manière dont les entreprises contrôlent les dépendances, les entrées et les actions des agents opérant au sein de leurs systèmes.

Les autorisations laissent ouvertes les décisions sur le comportement des agents

Le besoin de ces contrôles augmente à mesure que l’assistance IA devient exécution. Palo Alto Networks décrit des développeurs utilisant Claude pour comprendre des bases de code complexes, produire des logiciels et résoudre des problèmes plus rapidement, tandis que les travailleurs du savoir l’utilisent pour tirer des conclusions à partir d’informations. Lorsque des agents exécutent des séquences de tâches à travers des applications et des systèmes, leurs actions affectent les ressources de l’entreprise. Les équipes de sécurité doivent donc examiner ce qui se passe après que le modèle recommande une étape.

Claude Code montre comment ces actions peuvent exploiter un accès qu’un développeur a déjà accordé. Sur le terminal du développeur, ou machine locale, un agent peut inspecter des dépôts privés, récupérer des secrets et des identifiants, modifier des fichiers et exécuter des commandes. Il peut aussi atteindre des outils via le Model Context Protocol, ou MCP, qui relie les agents aux outils et aux données. Comme ces actions peuvent rester dans le cadre des autorisations existantes, des comportements nuisibles peuvent survenir sans contourner les contrôles d’accès.

Le risque dépend alors en partie de ce qui influence les choix de l’agent. Un développeur peut autoriser un travail sur un dépôt, mais l’agent peut rencontrer des instructions malveillantes dans les éléments qu’il lit et utiliser son accès légitime pour les exécuter. Le prompt injection est cette tentative de rediriger un agent au moyen d’une entrée malveillante. Pour un agent capable d’agir sur des ressources de l’entreprise, cette redirection peut modifier son usage des outils, ses modifications de fichiers ou son exécution de commandes.

Les compétences d’agent réutilisables, ensembles d’instructions et de ressources pour des tâches particulières, introduisent un risque connexe avant même le début d’une tâche. Les équipes adoptent ces compétences pour donner aux agents des façons de travailler répétables, mais une compétence compromise pourrait orienter des actions autorisées vers un résultat dangereux. Palo Alto Networks identifie le code malveillant et les portes dérobées, des moyens cachés d’obtenir un accès ou de modifier un comportement, dans les modèles ou les compétences d’agent comme des raisons de les inspecter avant déploiement. L’intégrité d’une dépendance influe donc sur la sûreté avec laquelle un agent utilise son autorité.

Même des composants dignes de confiance ont besoin de contrôles sur le traitement des données et l’accès. Un agent peut légitimement lire des informations sensibles tout en nécessitant malgré tout des restrictions sur les interactions qui peuvent les contenir. Des identifiants exposés créent une autre voie vers un dommage, tandis que des autorisations excessives augmentent les ressources qu’une action dangereuse peut atteindre. Les faiblesses de l’application IA ou de son workflow créent d’autres possibilités d’exploitation ; les équipes doivent donc examiner l’application, ses entrées, ses dépendances et son autorité.

Ces vérifications deviennent plus difficiles lorsque chaque développeur utilise une combinaison différente d’outils et de connexions. Palo Alto Networks étend son scénario développeur à « des milliers de développeurs, terminaux, compétences et intégrations », illustrant le nombre de combinaisons qu’une entreprise peut avoir à superviser. Un enregistrement central d’approbation pour Claude révèle peu de choses sur ces combinaisons, à moins que les équipes de sécurité puissent inspecter les endroits où le travail a lieu. La découverte doit donc atteindre les environnements dans lesquels les agents opèrent.

Ces environnements vont au-delà des outils de codage. Les employés peuvent travailler via Claude.ai et Claude Desktop, tandis que les équipes de développement peuvent créer des agents et des applications via l’API Claude, une interface de programmation d’application qui permet à des logiciels d’échanger des requêtes et des réponses avec Claude. Palo Alto Networks décrit également une dépendance croissante à l’égard des compétences réutilisables, des modèles open-source et des intégrations tierces. L’activité est donc répartie entre des dépôts, des terminaux, des applications et des systèmes connectés dont les dépendances peuvent évoluer indépendamment.

Une plus grande capacité des modèles modifie aussi le travail défensif réalisé dans ces environnements. Grâce au Project Glasswing d’Anthropic, Palo Alto Networks indique que ses équipes ont utilisé des modèles Claude de pointe, des modèles à la frontière des capacités actuelles, pour trouver des vulnérabilités logicielles que des modèles antérieurs n’avaient pas détectées. L’entreprise relie ce travail à une découverte plus précoce et à une réponse défensive plus rapide, et affirme que le délai entre la divulgation d’une vulnérabilité et son exploitation se réduit. Cette pression donne aux défenseurs une raison d’utiliser de manière proactive des modèles avancés.

Pourtant, l’usage défensif et la gouvernance des agents répondent à des questions distinctes. Project Glasswing concerne la détection des faiblesses logicielles ; le scénario Claude Code concerne le contrôle de ce qu’un agent peut faire avec un accès à l’entreprise. Le partenariat de Palo Alto Networks avec Anthropic combine cet usage défensif interne, un objectif commercial et une responsabilité de sécurité partagée. Son expérience en découverte de vulnérabilités aide à expliquer ce partenariat, tandis que les contrôles d’entreprise qu’il propose traitent les risques introduits par les agents déployés.

Trouver les agents et évaluer ce qui façonne leur comportement

Pour traiter ces risques, Palo Alto Networks organise sa proposition en quatre étapes : découvrir, évaluer, protéger et gouverner. L’entreprise applique cette séquence au codage assisté par IA, au travail de connaissance des employés et aux agents autonomes à travers le développement, le déploiement et l’exploitation. Elle affirme que l’objectif est de conserver la vitesse de développement que permet Claude tout en plaçant des contrôles là où les risques apparaissent. La découverte vient en premier, car une organisation doit savoir où un agent opère avant de pouvoir y appliquer une politique.

Trouver cette activité exige d’examiner l’intérieur des environnements développeur ainsi que les applications utilisées par les employés. Claude peut fonctionner dans des terminaux, des environnements de développement intégrés, les applications que les développeurs utilisent pour écrire et manipuler du code, des logiciels de bureau locaux, des connexions MCP et des API d’entreprise. Palo Alto Networks présente Cortex Agentic Endpoint Security comme un moyen d’identifier les agents de codage, les extensions et les serveurs MCP, qui fournissent des outils ou des données via MCP. L’entreprise affirme que cela aide à mettre au jour le shadow AI : l’usage de l’IA en dehors de la visibilité ou de la supervision organisationnelle établie.

L’usage orienté employés a besoin de visibilité à ses propres points d’accès. Palo Alto Networks propose Prisma Browser et Prisma SASE pour l’accès et la protection des données dans ces workflows. SASE, abréviation de secure access service edge, combine l’accès réseau et des fonctions de sécurité fournies via des services cloud. Ces contrôles complètent la découverte sur les terminaux en couvrant les environnements navigateur et réseau par lesquels les employés utilisent les services d’IA.

Une fois que les équipes localisent les agents et leurs connexions, elles peuvent évaluer les composants dont ces agents dépendent. L’approbation d’une application n’établit pas le comportement de chaque compétence réutilisable, modèle open-source ou intégration tierce qu’elle utilise. Palo Alto Networks indique que Prisma AIRS AI Supply Chain Security analyse les modèles et les compétences d’agent à la recherche de code malveillant, de portes dérobées et d’autres risques avant déploiement. Cela place un contrôle de sécurité avant qu’un composant puisse influencer une tâche opérationnelle.

L’inspection des composants laisse encore à examiner le comportement du workflow assemblé. Palo Alto Networks décrit l’AI Red Teaming comme des tests d’applications IA et de workflows d’agents pour détecter des faiblesses qu’un attaquant pourrait exploiter. Une analyse examine un modèle ou une compétence, tandis que les tests de workflow examinent la manière dont les parties connectées se comportent ensemble. Les deux soutiennent l’évaluation avant déploiement, car les interactions entre des composants examinés individuellement peuvent créer des risques supplémentaires.

Placer des contrôles avant le traitement par le modèle et pendant l’exécution

L’évaluation avant déploiement traite de ce qui entre dans le système, mais les requêtes en direct peuvent introduire de nouvelles instructions ou des données sensibles. Grâce aux hooks d’inférence natifs de Claude Enterprise, des points de connexion avant que le modèle ne traite une requête, Palo Alto Networks indique que Prisma AIRS inspecte les prompts couverts par ces contrôles. L’entreprise identifie comme préoccupations les informations sensibles quittant leur contexte autorisé et les entrées malveillantes atteignant le modèle. L’inspection à ce niveau permet à la politique de traiter une requête avant qu’elle n’influence la réponse du modèle.

Un prompt vérifié peut néanmoins conduire à plusieurs interactions ultérieures ; l’exécution a donc besoin de sa propre couverture. Pour Claude Code sur les terminaux des développeurs, Palo Alto Networks indique que Prisma AIRS s’intègre à Cortex Agentic Endpoint Security pour inspecter les prompts, les réponses, les appels d’outils MCP et les interactions réseau prises en charge. Les équipes qui évaluent cette couverture doivent la mettre en correspondance avec les interactions que leurs propres agents effectuent, y compris les interactions réseau prises en charge par l’intégration.

L’inspection devient application des règles lorsque la politique peut affecter le travail en cours sur la machine. Palo Alto Networks indique que la même intégration applique des politiques de sécurité des terminaux aux workflows d’agents. Une vérification de requête examine ce qu’il est demandé au modèle de traiter, tandis que les règles de terminal traitent l’activité là où les actions qui en résultent se produisent. Ces contrôles répondent à des décisions différentes, car une tâche autorisée peut produire plusieurs appels d’outils, modifications de fichiers et commandes.

Les applications personnalisées placent ces décisions à des points d’intégration différents. Pour les logiciels construits avec l’API Claude, Palo Alto Networks indique que Prisma AIRS fournit une protection pendant l’exécution via AI Gateway ou une intégration API directe. Les équipes qui construisent de tels services ont besoin de contrôles là où l’application envoie des requêtes et reçoit des réponses. La couverture sur le terminal d’un développeur ne s’étend pas automatiquement à chaque service que ce développeur construit.

Les points de connexion de l’application laissent une question distincte sur l’autorité de l’agent. Palo Alto Networks décrit Agent Identity Security comme fournissant des identités d’agent vérifiables et un accès juste-à-temps, à privilège minimal, aux ressources de l’entreprise. En pratique, un agent reçoit un accès lorsqu’il en a besoin, limité aux ressources et aux actions requises pour sa tâche. L’objectif est de réduire la dépendance à des identifiants permanents qui restent disponibles entre les tâches.

Un accès limité réduit le dommage potentiel, mais il ne peut pas déterminer si une instruction est sûre. Les contrôles d’identité établissent quel agent agit et quelle autorité il reçoit ; l’inspection du contenu examine les éléments dangereux ; les politiques d’exécution gouvernent l’activité dans l’environnement d’exploitation. Un agent aux autorisations restreintes peut toujours rencontrer des instructions malveillantes, et un prompt inspecté peut toujours conduire à une action ultérieure nécessitant une décision distincte. Coordonner ces contrôles permet à chacun de traiter la partie du workflow qu’il peut réellement gouverner.

Gouverner le trafic et la consommation partagés

Lorsque ces workflows traversent des services partagés, la gouvernance doit aussi déterminer quelles connexions sont autorisées et quel volume d’activité elles peuvent générer. Palo Alto Networks indique que Prisma AIRS AI Gateway centralise la politique pour le trafic des grands modèles de langage, ou LLM, ainsi que pour le trafic MCP et A2A. A2A signifie communication agent à agent, par laquelle des agents échangent des informations ou coordonnent leur travail. L’entreprise décrit des contrôles de routage, d’accès, de quotas et de limites de débit, donnant aux équipes des moyens de définir les destinations autorisées et les limites d’usage.

Ces limites nécessitent une observation continue, car les schémas d’usage peuvent changer après le déploiement. Palo Alto Networks décrit des analyses montrant où et comment l’IA est consommée ainsi que les coûts associés. Les équipes de sécurité et d’ingénierie peuvent utiliser cette vue pour examiner la consommation en parallèle des règles d’accès et de trafic. La visibilité sur les coûts devient alors une composante de l’exploitation des services d’IA partagés, liée aux politiques qui déterminent qui peut les utiliser et à quel volume.

Tester la coordination entre les systèmes de sécurité

L’application de ces politiques exige une coopération entre les systèmes qui protègent déjà les utilisateurs de l’entreprise. Un agent peut s’exécuter sur un terminal géré, se connecter à une application d’entreprise, utiliser une identité et échanger des données via des services réseau. Chaque domaine de sécurité voit une portion différente de la tâche. Les examiner séparément peut empêcher les équipes de reconstituer ce à quoi l’agent a accédé, ce qu’il a créé ou ce qu’il a fait.

Palo Alto Networks propose de relier la sécurité de l’IA à la protection réseau, à la protection du navigateur, aux contrôles d’identité et aux opérations de sécurité Cortex. Dans son approche, les contrôles du navigateur et du réseau traitent leurs interactions respectives, les contrôles d’identité limitent l’accès et les opérations de sécurité fournissent un lieu pour gérer l’activité à travers l’environnement. Ces systèmes servent déjà les personnes utilisant les mêmes ressources. Le travail supplémentaire consiste à relier leurs décisions et leurs observations au comportement des agents.

L’entreprise appelle cela la « platformization for the AI era », présentant son portefeuille comme le moyen de coordonner ce travail. Palo Alto Networks en bénéficie si les entreprises répondent à cette exigence par ses produits ; le principe opérationnel et la décision d’achat méritent donc une évaluation distincte. Les workflows intersystèmes exigent des contrôles coopératifs ; choisir une plateforme d’un fournisseur unique exige d’examiner comment cette coopération fonctionne dans l’environnement de l’entreprise. Un large portefeuille de produits décrit la couverture visée, tandis qu’un test de workflow montre comment ses éléments fonctionnent ensemble.

Ce test peut suivre un agent approuvé dans une tâche réelle, en commençant par la découverte de son environnement et de ses connexions. Avant l’exécution, les évaluateurs peuvent identifier quels contrôles ont évalué ses dépendances et son workflow complet ; pendant l’exécution, ils peuvent retracer les décisions concernant les entrées, les interactions avec les outils, les commandes et l’accès délégué. Ils peuvent ensuite localiser les politiques gouvernant le trafic, la consommation et les coûts, et établir quel système enregistre chaque décision. L’acceptation dépend de la démonstration que les contrôles pertinents fonctionnent aux points requis de la tâche.

Points clés à retenir pour les dirigeants

• L’approbation ouvre une deuxième décision de sécurité : Les agents Claude peuvent accéder à du code privé, à des identifiants et à des commandes dans le cadre des autorisations accordées. Les responsables de la sécurité ont besoin de politiques explicites sur les ressources auxquelles les agents peuvent accéder et les actions qu’ils peuvent effectuer.
• Cartographier l’accès et les dépendances des agents : Les terminaux des développeurs, les compétences réutilisables, les connexions MCP et les intégrations tierces façonnent le comportement des agents. Les responsables des terminaux et des applications ont besoin d’un inventaire de ces connexions pour identifier l’exposition et attribuer les contrôles.
• Évaluer les composants et les workflows : Les équipes de sécurité ont besoin de contrôles avant déploiement pour détecter le code malveillant et les portes dérobées dans les modèles et les compétences, ainsi que de tests des workflows complets d’agents. Les composants connectés peuvent introduire des risques par leurs interactions.
• Contrôler les requêtes en direct et l’exécution : Les responsables des applications et des terminaux ont besoin de contrôles au niveau des prompts, des réponses, des appels d’outils et de l’exécution des commandes. Des identités d’agent vérifiables et un accès limité à la tâche réduisent la dépendance à des identifiants permanents.
• Gouverner le trafic et la consommation : Les responsables de plateforme ont besoin de politiques pour les destinations autorisées, l’accès, les quotas et les limites de débit à travers les communications entre modèles, outils et agents. Les analyses d’usage et de coûts les aident à ajuster ces limites à mesure que l’adoption progresse.
• Valider la coordination à travers des tâches réelles : Les équipes de sécurité et d’ingénierie peuvent suivre un agent approuvé dans un workflow représentatif pour vérifier l’application des règles et les enregistrements de décision. Évaluez la plateforme proposée par Palo Alto Networks à l’aune de la couverture démontrée dans l’environnement propre de l’entreprise.