Une étude de SecurityHQ sur les agents IA révèle que les politiques devancent la responsabilité en cas d’incident

SecurityHQ a publié une étude montrant que 76 % des responsables de la cybersécurité interrogés disposent de politiques formelles de responsabilité liées à l’IA, tandis que seuls 17 % pouvaient reconstituer l’activité d’un agent en quelques minutes. Menée avec Datadog, l’étude de SecurityHQ sur les agents IA met en évidence une tension concrète : attribuer une responsabilité ne rend pas nécessairement une décision automatisée explicable.

Publiés le 15 octobre 2026, ces résultats interviennent alors que les agents d’entreprise obtiennent l’autorisation d’exécuter des tâches dans les systèmes métier. Les agents IA sont des systèmes logiciels qui utilisent des modèles et des outils connectés pour accomplir des tâches. Leur degré d’autorité soulève des questions auxquelles les seules politiques écrites ne peuvent répondre.

L’extension par Microsoft de Security Copilot offre un exemple concret de cette évolution vers un travail de sécurité délégué. La pression pèse désormais sur les responsables de la sécurité, les propriétaires d’applications et les fournisseurs pour relier les actions automatisées à des éléments de preuve et à une autorité humaine responsable.

L’étude de SecurityHQ sur les agents IA distingue politique et préparation

L’étude a interrogé 204 responsables de la cybersécurité dans des organisations de taille moyenne et de grande taille. Selon l’annonce de l’étude, 45 % avaient connu un incident impliquant des agents IA ou de l’automatisation pour lequel la responsabilité n’était pas claire.

Cette formulation mérite attention. La catégorie des incidents inclut l’automatisation ; le résultat n’établit donc pas que 45 % ont subi une compromission causée par un agent IA autonome. Une responsabilité floue décrit également un problème organisationnel, plutôt qu’une défaillance technique particulière ou un niveau de dommages précis.

Cette conclusion concerne la capacité des organisations à expliquer les actions déléguées lorsque la responsabilité est contestée. Une politique peut désigner un responsable sans indiquer quelle instruction, autorisation ou interaction système a produit un résultat.

Les conclusions publiques sur la responsabilité de SecurityHQ distinguent également la visibilité historique de la capacité d’enquête immédiate. Seuls 49 % ont déclaré pouvoir reconstituer intégralement les actions d’un agent au cours des 30 jours précédents.

Cette distinction change la manière dont les acheteurs devraient interpréter les résultats. Conserver des traces et répondre à des questions urgentes sont des capacités liées, mais elles répondent à des besoins opérationnels différents. Une organisation peut conserver des éléments de preuve pertinents tout en devant effectuer un travail manuel considérable pour les relier.

À l’inverse, un tableau de bord peut résumer l’activité récente sans conserver suffisamment de détails pour une enquête ultérieure. Aucune de ces possibilités n’établit ce qui s’est produit au sein des organisations interrogées. Elles expliquent toutes deux pourquoi une simple affirmation de visibilité exige un examen plus approfondi.

Le changement important réside dans le cadrage de l’étude. SecurityHQ place la responsabilité définie par les politiques à côté de la capacité à établir une séquence d’actions, rendant visible l’écart entre ces deux capacités.

Pour les acheteurs d’entreprise, cela crée une question d’approvisionnement plus exigeante. L’explication d’un fournisseur concernant sa gouvernance devrait être reliée aux éléments de preuve qu’un client reçoit après l’action d’un agent.

Pour les équipes internes de sécurité, cette même distinction affecte le reporting. L’existence d’un processus d’approbation n’établit pas que les enquêteurs peuvent retrouver l’approbation associée à une action contestée.

Une politique de responsabilité reste utile, car elle définit les attentes. Sa valeur opérationnelle dépend de la capacité des personnes à appliquer ces attentes à un événement précis.

L’enquête n’établit pas que les organisations disposant de politiques ont connu moins d’incidents. Elle ne montre pas non plus que l’achat de capacités de surveillance supplémentaires résoudrait l’incertitude quant à la responsabilité.

Sa contribution plus limitée reste néanmoins importante. Les entreprises peuvent attribuer formellement des responsabilités tout en ne disposant pas des éléments de preuve nécessaires pour exercer cette responsabilité sous pression.

C’est pourquoi cette histoire importe au-delà d’une nouvelle enquête sur les risques liés à l’IA. L’étude remet en question la capacité des mesures de gouvernance habituelles à décrire la préparation réelle dès lors qu’un logiciel reçoit une autorité déléguée.

Le travail de sécurité délégué met les acheteurs et les opérateurs sous pression

Les responsables de la sécurité sont soumis à cette pression parce que les agents opèrent au sein de systèmes qui répartissent déjà les responsabilités entre différentes équipes. Un propriétaire d’application peut autoriser un flux de travail, tandis qu’une autre équipe gère ses identifiants et qu’une troisième traite les incidents.

Un identifiant est la preuve numérique qu’un logiciel présente lorsqu’il demande un accès. Lorsque plusieurs flux de travail partagent cette preuve, identifier le compte peut ne pas suffire à déterminer l’initiateur réel.

Une question de responsabilité apparemment simple se divise alors en plusieurs interrogations. Qui a approuvé la tâche, qui a accordé l’accès, qui a maintenu l’intégration et qui pouvait arrêter l’exécution ?

Ces rôles ne doivent pas nécessairement appartenir à la même personne. La difficulté apparaît lorsque l’organisation ne peut pas les relier au cours d’une enquête.

Déléguer du travail accroît l’importance de savoir où l’autorité commence, évolue et s’arrête. Un dirigeant désigné ne peut pas résoudre un incident par sa seule présence dans un document de gouvernance.

Les conséquences opérationnelles dépassent les services de sécurité. Les responsables métier doivent comprendre si l’action d’un agent a servi un objectif approuvé. Les équipes applicatives ont besoin d’un contexte suffisant pour distinguer un comportement attendu d’un usage abusif.

Les équipes juridiques et de gestion des risques font face à une autre préoccupation : déterminer si les traces disponibles étayent l’explication que l’entreprise fournit ensuite. Un récit assuré a une valeur limitée lorsque les éléments qui le soutiennent restent fragmentés.

Les fournisseurs sont également sous pression, car les clients dépendent de la conception des produits pour obtenir une partie de ces traces. Les clients ne peuvent pas récupérer indépendamment des informations qu’un service n’expose ni ne conserve.

Microsoft illustre pourquoi ces questions sont devenues immédiates. Son annonce d’agents de sécurité de mars 2025 a présenté des agents destinés notamment au triage du phishing, c’est-à-dire au classement et à l’évaluation de messages soupçonnés d’être trompeurs.

L’entreprise a présenté ces capacités comme un moyen de réduire le travail de routine des défenseurs. Cela fournit un contexte de déploiement concret sans établir que les produits Microsoft présentent les lacunes signalées par SecurityHQ.

La comparaison porte sur la proposition d’achat. Microsoft décrit le travail que les agents peuvent prendre en charge ; SecurityHQ se demande si les organisations peuvent rendre compte de l’activité déléguée par la suite.

Ces propositions relèvent de la même discussion d’achat. Une promesse d’efficacité devient plus utile lorsque les acheteurs peuvent également évaluer l’effort d’enquête, les options d’intervention et la disponibilité des éléments de preuve.

Pour un centre des opérations de sécurité, l’équipe chargée de surveiller les menaces et d’y répondre, la réduction de la charge de travail routinière présente un attrait évident. Mais les actions non élucidées créent du travail ailleurs.

Un analyste qui reçoit la conclusion d’un agent doit encore en comprendre le fondement lorsque les circonstances changent. Un autre enquêteur peut devoir réexaminer cette décision une fois la tâche initiale terminée.

La pression concerne donc à la fois l’approbation du déploiement et les opérations continues. Les acheteurs ont besoin d’éléments de preuve sur le comportement du système après son adoption, y compris lorsque ses actions exigent une explication.

Cela ne rend pas l’autonomie intrinsèquement inadaptée au travail de sécurité. Cela fait de l’étendue de l’autorité déléguée un élément central pour déterminer si le compromis opérationnel en vaut la peine.

Une automatisation utile exige toujours une trace d’action explicable

La tension centrale oppose le temps que les agents font gagner dans le travail ordinaire à l’effort nécessaire pour expliquer des résultats exceptionnels. Une exécution plus rapide ne crée de valeur qu’à l’intérieur de limites que l’organisation peut défendre.

Prenons le triage du phishing comme flux de travail illustratif, et non comme incident signalé par SecurityHQ. Un agent examine un message suspect, consulte des informations connectées et produit une décision.

Une enquête utile relierait le message, les informations consultées, l’identité de l’agent et l’action qui en résulte. Si une approbation s’appliquait, les enquêteurs devraient également relier cette approbation à l’action.

Enregistrer qu’une tâche a été achevée répond à une question plus restreinte. Cela établit un résultat final sans nécessairement expliquer comment le système y est parvenu.

Une piste d’action responsable doit relier les instructions, l’autorité, l’exécution et le résultat. Cette connexion importe, car chacun de ces éléments peut devenir la partie contestée d’un incident.

L’instruction pouvait être appropriée tandis que l’autorisation était excessive. L’autorisation pouvait être appropriée tandis que les informations rencontrées au cours de l’exécution redirigeaient la tâche.

L’agent peut aussi avoir suivi correctement le flux de travail demandé alors que la règle métier sous-jacente était erronée. La responsabilité doit également laisser place à cette possibilité.

Un enregistrement centré entièrement sur le modèle risque de négliger ces distinctions. Un modèle n’est qu’une partie de l’application qui reçoit des instructions, récupère des informations et appelle des outils connectés.

Une interface de programmation d’applications, ou API, est une interface logicielle par laquelle un système demande les fonctions d’un autre système. L’activité des agents peut traverser ces interfaces et leurs traces distinctes.

Chaque service peut décrire avec exactitude son interaction locale tout en rendant difficile la reconstitution de la tâche globale. L’élément manquant est la relation entre des traces par ailleurs valides.

Les conclusions de Salt Security sur la sécurité des agents du 13 octobre offrent un autre éclairage sur ce problème. Son étude a combiné plus de 380 réponses à une enquête avec de la télémétrie de production.

Seuls 12,5 % des répondants ont déclaré pouvoir suivre de manière cohérente les parcours complets des agents pour l’ensemble des agents. Salt a également indiqué que 17,5 % pouvaient arrêter automatiquement en production un agent au comportement inattendu.

Ces chiffres mesurent des capacités différentes des questions de SecurityHQ sur la reconstitution. Ils ne devraient pas être combinés dans un score commun ni traités comme des estimations équivalentes.

Leur intérêt est conceptuel : suivre une action et interrompre une action sont deux composantes distinctes du contrôle. Une explication complète après un incident n’en annule pas les conséquences.

De même, arrêter un flux de travail n’explique pas pourquoi il s’est comporté de manière inattendue. Les acheteurs doivent évaluer les deux capacités sans supposer que l’une garantit l’autre.

La comparaison commerciale est donc plus large qu’une concurrence entre fournisseurs individuels. SecurityHQ met l’accent sur la responsabilité opérationnelle, Microsoft décrit les tâches de sécurité déléguées, et Salt souligne la traçabilité et le confinement.

Ces perspectives se rejoignent autour d’un problème commun aux clients. Les entreprises ont besoin que le travail délégué reste compréhensible au-delà des frontières des produits, où la responsabilité devient souvent plus difficile à établir.

L’approbation humaine ne peut assumer seule tout le poids de la responsabilité

L’examen humain reste une réponse séduisante, car il place une personne à proximité d’une décision importante. Son utilité dépend de ce que cette personne peut examiner et autoriser.

Une approbation associée à un objectif vague laisse place au désaccord sur les actions autorisées. Une approbation associée à une action précise établit une limite plus claire.

Même dans ce cas, les enquêteurs doivent savoir si l’exécution correspondait à la demande approuvée. L’approbation et l’exécution décrivent des moments différents, potentiellement séparés par l’évolution des informations ou des conditions du système.

La supervision humaine contribue à la responsabilité lorsque le registre d’approbation correspond à l’autorité réellement exercée. L’implication d’une personne ne fournit pas automatiquement l’historique technique manquant.

Cette distinction est importante pour les dirigeants qui s’attendent à ce qu’un relecteur final assume la responsabilité de l’ensemble d’un flux de travail. Un relecteur ne peut pas évaluer de manière pertinente les informations que le système ne révèle pas.

Elle compte également pour les équipes produit qui décident où placer les étapes d’approbation. Interrompre chaque action crée des frictions, tandis qu’approuver une tâche entière délègue une marge de manœuvre plus large.

Le compromis pratique porte sur les décisions qui exigent une intervention et les limites que le logiciel peut appliquer directement. Des flux de travail différents justifient des réponses différentes, car leurs conséquences possibles diffèrent.

Un système qui se limite à recommander une réponse soulève une question d’autorité différente de celle d’un système qui modifie les accès. La comparaison pertinente concerne l’action autorisée, plutôt que la présence d’une étiquette IA.

L’identité devient également plus importante à mesure que les agents agissent au-delà des frontières organisationnelles. L’authentification établit qui ou quoi effectue une demande ; l’autorisation détermine ce que ce demandeur peut faire.

Aucune de ces fonctions ne suffit à expliquer l’objectif métier d’une demande. Une enquête gagne à relier l’identité technique à la tâche et à la personne ou au processus qui l’a déléguée.

Les travaux du NIST sur l’identité des agents offrent une référence institutionnelle pour ce défi. En septembre, l’organisme a identifié le développement logiciel comme premier cas d’usage de mise en œuvre.

Ces travaux portent sur l’identification, l’authentification et l’autorisation des agents au sein du cycle de développement logiciel. Il s’agit d’un effort de mise en œuvre, et non d’une preuve que la responsabilité en entreprise a été résolue.

Cette orientation importe, car la responsabilité dépend en partie de la manière dont l’autorité circule dans les logiciels. Des normes et des démonstrations peuvent aider à exprimer ces relations plus systématiquement.

Cependant, une identité technique ne peut pas décider qui doit assumer un résultat métier contesté. Les organisations ont toujours besoin de responsabilités explicites pour le déploiement, la maintenance, la revue et l’intervention d’urgence.

Des registres clairs et des rôles clairs se renforcent mutuellement. Les registres aident à établir ce qui s’est produit, tandis que les rôles déterminent qui doit évaluer ces éléments et y répondre.

La même distinction s’applique aux connaissances organisationnelles. Une base de connaissances d’équipe interrogeable peut faciliter l’accès aux politiques et aux responsabilités, tandis que les preuves d’exécution établissent ce que les systèmes ont réellement fait.

Maintenir ces fonctions distinctes aide à éviter une erreur familière. Documenter le flux de travail attendu ne prouve pas qu’une exécution particulière l’a suivi.

L’enquête soulève des questions qu’elle ne peut pas trancher

L’étude de SecurityHQ sur les agents IA fournit des éléments sur l’expérience et la confiance déclarées par les répondants. Elle ne mesure pas de façon indépendante le comportement de chaque agent au sein de leurs organisations.

L’état de préparation déclaré peut différer des performances lors d’un incident réel. Les répondants peuvent interpréter différemment la reconstitution, la responsabilité et l’activité des agents.

Un dirigeant peut décrire une forte supervision centrale alors que des déploiements décentralisés restent hors de ce champ de vision. Un autre peut signaler une préparation limitée malgré des équipes compétentes utilisant des processus internes peu familiers.

Ces possibilités n’invalident pas les résultats. Elles limitent la certitude des conclusions qui peuvent en être tirées.

L’enquête justifie un examen attentif de la préparation des entreprises, plutôt qu’une estimation universelle des défaillances d’agents. Ses résumés publics ne doivent pas se substituer aux tests de déploiements individuels.

L’annonce publique et la page de présentation ne fournissent pas suffisamment de détails méthodologiques pour établir une large représentativité. Les lecteurs devraient éviter de supposer que l’échantillon reflète tous les secteurs ou toutes les tailles d’entreprise.

L’association des agents IA et de l’automatisation dans la question sur les incidents crée une autre limite. Elle ne permet pas de savoir clairement quelle part de l’incertitude déclarée provient d’agents plus récents plutôt que de flux de travail automatisés établis.

Cette distinction compte pour interpréter la nouveauté. Les organisations peinent depuis longtemps à attribuer les responsabilités entre intégrations logicielles, services externalisés et processus opérationnels partagés.

Les déploiements d’agents peuvent compliquer ce problème existant sans rendre nouvelle chacune de ses faiblesses sous-jacentes. Traiter l’ensemble du sujet comme étant propre à l’IA risque de masquer des défaillances de contrôle déjà connues.

La relation entre les politiques et les incidents reste également non résolue. Les résultats agrégés n’établissent pas quels répondants disposaient de politiques lorsque des incidents particuliers se sont produits.

Ils ne peuvent donc pas démontrer que les politiques n’ont pas empêché les incidents, ni que les organisations sans politiques ont obtenu de moins bons résultats. Chacune de ces affirmations nécessiterait des preuves supplémentaires.

L’étude de SecurityHQ sur les agents IA provient également d’organisations ayant des intérêts commerciaux dans la sécurité et la surveillance. Ce contexte mérite d’être signalé sans pour autant écarter automatiquement leurs observations.

La réponse sceptique appropriée consiste à examiner les définitions, la méthodologie et les preuves reproductibles. Un parrainage commercial et des résultats utiles peuvent coexister.

Une prudence comparable s’applique aux comparaisons avec les résultats de Salt. Des questions, populations et méthodes de mesure différentes empêchent d’établir un classement net de la préparation des entreprises entre les études.

Un accord sur une préoccupation générale ne démontre pas un accord sur la prévalence mesurée. Les études apportent des observations distinctes sur la visibilité, l’autorité et l’intervention.

La recherche n’établit pas non plus que centraliser davantage de registres améliore toujours la sécurité. Les registres peuvent contenir des informations sensibles, et l’accès aux éléments d’enquête crée ses propres responsabilités.

L’implication analytique est plus limitée : les organisations ont besoin de preuves suffisantes pour les décisions qu’elles délèguent. Ce qui est suffisant dépend de l’action et de ses conséquences.

Une réponse convaincante montrerait comment un flux de travail spécifique reste attribuable lors d’une défaillance. Une affirmation plus large selon laquelle une plateforme rend tous les agents responsables exige une base probante bien plus solide.

Surveiller les preuves d’incidents, les contrôles produit et les mises en œuvre d’identité

Au cours des prochains mois, les évolutions les plus utiles montreront si les organisations peuvent transformer une responsabilité déclarée en capacité opérationnelle démontrable. Les seules annonces d’adoption laisseront cette question sans réponse.

Le premier signal est la qualité des reconstitutions d’incidents et des exercices contrôlés publiés. Des comptes rendus utiles relieraient la tâche déléguée, l’autorité pertinente, la séquence d’actions et l’intervention.

Ils devraient également préciser ce que les enquêteurs n’ont pas pu récupérer. Une reconstitution incomplète mais sincère apporte davantage de preuves qu’une assurance selon laquelle une équipe a conservé le contrôle.

Des démonstrations répétées dans différents flux de travail renforceraient la confiance dans le fait que les pratiques de responsabilité fonctionnent au-delà d’un exemple préparé. Des lacunes persistantes conforteraient la préoccupation soulevée par SecurityHQ.

Le deuxième signal est la preuve produit reliant l’exécution des agents à l’enquête et au confinement. Les acheteurs devraient observer ce que les fournisseurs exposent à leurs clients, plutôt que de se fier à un langage général sur la gouvernance.

Une démonstration significative montrerait comment un enquêteur suit une tâche à travers des services connectés. Elle montrerait également ce qui se passe lorsqu’un opérateur autorisé interrompt le flux de travail.

Le moment et la portée de l’interruption sont importants. Empêcher l’action suivante diffère de l’annulation de modifications déjà effectuées, et les démonstrations produit devraient rendre cette distinction compréhensible.

Des contrôles plus clairs soutiendraient une délégation plus large lorsque les clients peuvent vérifier leur comportement. Des écarts inexpliqués entre les registres locaux renforceraient l’argument en faveur d’une autorité plus limitée.

Le troisième signal est l’avancement de la mise en œuvre autour de l’identité et de l’autorisation des agents. Le cas d’usage annoncé par le NIST pour le développement logiciel offre un point concret à surveiller pour les résultats techniques.

Des exemples pratiques pourraient clarifier comment l’autorité déléguée reste attribuable lorsque les logiciels passent d’un service à un autre. Leur valeur dépendra de la capacité des organisations à appliquer cette approche à des flux de travail réels.

Les progrès réduiraient l’ambiguïté autour de l’identité technique, tout en laissant les décisions d’appropriation métier à l’entreprise. Les retards obligeraient les clients à s’appuyer davantage sur des approches propres à chaque produit.

Le prochain repère utile consiste à déterminer si les organisations peuvent expliquer et interrompre une activité déléguée dans des conditions réalistes. Ce repère relie les résultats de la recherche aux décisions auxquelles les acheteurs sont déjà confrontés.

Pour les lecteurs qui évaluent un déploiement, l’étude de SecurityHQ sur les agents IA offre une raison d’examiner les preuves qui étayent les garanties existantes. Commencez par un flux de travail conséquent qui a déjà un responsable. Demandez à ce responsable d’expliquer une exécution terminée à l’aide des registres disponibles aujourd’hui. Suivez l’instruction, l’autorisation, l’action et le résultat. Identifiez ensuite qui peut intervenir lorsque ces éléments cessent de correspondre. Les liens manquants révèlent un problème plus précis qu’une préoccupation générale concernant la sécurité de l’IA. Ils permettent également une discussion plus claire avec les fournisseurs et les équipes internes sur ce qui doit être amélioré. Avant d’accorder une autorité plus large, demandez une démonstration qui rende visibles l’historique des actions et la limite d’intervention. Votre organisation peut-elle défendre cette explication lorsque le résultat est contesté ?