Enquête CTech sur la sécurité de l’IA : l’automatisation relève le niveau pour les chercheurs humains

L’enquête de CTech sur la sécurité de l’IA a révélé que l’automatisation prend désormais en charge une part importante du travail de recherche, tout en relevant les attentes à l’égard des humains qui la supervisent. L’enquête du 18 septembre a couvert 30 chercheurs en sécurité issus d’entreprises israéliennes de cybersécurité. Les participants ont décrit l’utilisation de l’IA pour l’analyse des journaux, la revue de documentation, les premiers scans de code et les investigations parallèles.

Cette efficacité s’accompagne d’un renversement marqué. Une recherche plus rapide ne rend pas un jugement solide moins important. Elle donne aux hypothèses fragiles, aux instructions incomplètes et aux autorisations excessives davantage d’occasions de causer des dégâts à la vitesse des machines.

Les chercheurs en sécurité évoluent donc de l’enquête manuelle vers l’orchestration, la validation et la responsabilité. Leur adversaire émergent n’est pas simplement un modèle d’IA ou un attaquant automatisé. C’est l’automatisation dépourvue de jugement humain fiable.

Le changement dépasse les équipes de recherche spécialisées. Les entreprises remplissent leurs environnements d’agents, de comptes de service, de clés d’interface de programmation applicative et d’autres identités non humaines. Nombre d’entre eux peuvent lire des données sensibles ou effectuer des actions dans des systèmes connectés.

Parallèlement, les attaquants peuvent utiliser une automatisation similaire pour explorer des vulnérabilités et accélérer leur exploitation. Les défenseurs doivent automatiser sans faire confiance à chaque conclusion générée. Ils doivent également sécuriser les agents qui réalisent ce travail.

Le résultat est une nouvelle norme exigeante pour la profession. Les chercheurs ont besoin de la profondeur technique nécessaire pour remettre en question un modèle, de la discipline opérationnelle pour contrôler les agents et des compétences de communication pour définir des objectifs précis.

L’enquête CTech sur la sécurité de l’IA montre ce qui a changé

L’IA a absorbé les tâches de sécurité répétitives, déplaçant la valeur du chercheur de la production manuelle vers l’orientation, la vérification et le jugement technique.

L’enquête auprès des chercheurs en sécurité a recueilli les réponses de 30 professionnels travaillant dans le secteur israélien de la cybersécurité. Il ne s’agissait pas d’une étude contrôlée de productivité. Elle offrait une vue structurée de la manière dont des équipes de recherche actives décrivent l’évolution de leur travail.

Toutes les entreprises interrogées ont déclaré que l’IA avait pris en charge des tâches telles que l’analyse des journaux, la revue de documentation et le premier scan de code. Un quart des répondants ont explicitement décrit cette technologie comme un multiplicateur de force pour la production individuelle.

Yuval Barak, ingénieur de recherche fondateur chez Astelia, a formulé l’affirmation de productivité la plus marquante de l’enquête. Il a déclaré que les agents avaient porté la production de chaque chercheur à environ dix fois son niveau précédent en prenant en charge les tâches laborieuses.

Ce chiffre reflète l’évaluation d’un praticien, et non une référence sectorielle auditée de manière indépendante. Toutefois, le changement sous-jacent des flux de travail est apparu de façon cohérente dans les réponses.

Auparavant, un chercheur devait recueillir des journaux, consulter la documentation, comparer des chemins de code et organiser les résultats potentiels avant de tester une hypothèse. Un agent peut désormais effectuer plusieurs de ces étapes simultanément.

Le rôle humain commence plus tôt et se termine plus tard. Les chercheurs doivent définir la question, sélectionner les outils, limiter les accès, examiner les preuves et décider si une vulnérabilité signalée est réelle.

Roy Itzhaky, chercheur en sécurité au sein de l’organisation du directeur de la technologie de Linx Security, a décrit ce rôle comme celui d’un directeur plutôt que d’un fouilleur. L’agent explore plusieurs pistes, tandis que le chercheur les maintient alignées et évalue les résultats.

Cette distinction importe, car la recherche ne se mesure pas au nombre de pistes qu’un système produit. Une découverte crédible doit être reproductible, pertinente et étayée par des preuves.

Le scan automatisé peut augmenter le nombre d’hypothèses sans en améliorer la qualité. Il peut également masquer l’incertitude derrière une prose assurée ou des artefacts techniques convaincants.

Un modèle peut identifier du code suspect et proposer un chemin d’attaque plausible. Le chercheur doit encore déterminer si ce chemin est accessible, si les contrôles existants le bloquent et si son exploitation entraîne un impact significatif.

Le même principe s’applique au travail sur la documentation. L’IA peut résumer des enquêtes antérieures et faire ressortir des résultats connexes. Elle ne peut pas garantir que le contexte est actuel, complet ou applicable à un nouvel environnement.

Cela transforme la manière dont les équipes gèrent la mémoire institutionnelle. Barak a estimé que la connaissance peut devenir une propriété de l’équipe au lieu de rester attachée à des chercheurs individuels.

Ce résultat exige davantage que l’ajout d’un chatbot à une collection de documents. Les équipes ont besoin de preuves organisées, de décisions traçables et de contrôles d’accès qui distinguent les résultats fiables des spéculations inachevées.

Une base de connaissances consultable peut accompagner cette transition lorsqu’elle préserve le contexte des sources. Sans provenance, une récupération plus rapide peut faire circuler d’anciennes hypothèses aussi vite que des connaissances valides.

L’événement dépasse donc la simple histoire de productivité. L’IA modifie l’endroit où les chercheurs consacrent leurs efforts et où les défaillances de sécurité peuvent s’introduire dans le processus.

Le travail répétitif diminue. La charge consistant à spécifier, superviser et valider le travail automatisé augmente.

Une recherche plus rapide met les équipes de sécurité sous pression

Le gain de productivité crée une nouvelle référence, obligeant les chercheurs à fournir plus vite des résultats validés tandis que les attaquants accèdent à une automatisation similaire.

Les équipes de sécurité sont sous pression des deux côtés du flux de travail. Leurs propres organisations attendent davantage de résultats, tandis que les adversaires peuvent utiliser l’IA pour raccourcir la reconnaissance et l’expérimentation.

L’enquête CTech sur la sécurité de l’IA montre à quelle vitesse les attentes internes se sont ajustées. Si un agent peut examiner de la documentation ou scanner du code en quelques minutes, une longue file d’attente manuelle devient plus difficile à justifier.

Ofri Ziv, cofondateur et vice-président de la recherche chez Tenzai, a déclaré que des travaux auparavant maintenus en recherche pendant des mois doivent désormais être évalués, renforcés et livrés en quelques semaines. Ce changement relie directement les performances de la recherche à la livraison de produits.

Une livraison plus rapide peut améliorer la défense lorsque les équipes préservent la validation. Elle peut aussi encourager des conclusions prématurées, des alertes bruyantes ou des contrôles insuffisamment testés.

La pression est particulièrement visible dans la gestion des vulnérabilités. Les organisations doivent identifier les faiblesses exploitables, les prioriser, développer des correctifs et vérifier ces correctifs dans des environnements en évolution.

L’équipe Mandiant de Google a décrit un modèle opérationnel similaire. Son cadre de revue agentique associe plusieurs agents à une validation structurée et à l’expertise humaine.

Ce cadre est conçu pour aider les experts à examiner le code source, identifier des chemins d’exploitation et tester des vulnérabilités potentielles. Sa structure est importante, car l’exploration non contrainte par des modèles peut faire perdre du temps ou produire des conclusions non étayées.

La rapidité seule ne résout pas le désavantage traditionnel des défenseurs. Un attaquant n’a besoin que d’un chemin viable, tandis qu’un défenseur doit réduire l’exposition sur de nombreux actifs, identités et applications.

L’IA peut aider les défenseurs à paralléliser ce travail. Elle aide aussi les attaquants à automatiser les recherches, adapter des techniques publiques et examiner plus fréquemment des systèmes exposés.

Google Cloud a indiqué que l’intervalle entre la divulgation d’une vulnérabilité et son exploitation active est passé de plusieurs semaines à quelques jours durant le second semestre 2025. Cette observation renforce l’argument en faveur d’une découverte continue et d’une validation défensive plus rapide.

Elle ne prouve pas que l’IA a provoqué chaque réduction de la fenêtre d’exploitation. Elle montre toutefois pourquoi le travail de sécurité périodique devient moins compatible avec les conditions opérationnelles actuelles.

Un test d’intrusion réalisé deux fois par an ne capture qu’une vue temporaire d’un environnement. De nouveaux codes, autorisations, services et intégrations peuvent rendre cette vue obsolète peu après leur mise en production.

Quatre entreprises de l’enquête CTech ont déclaré avoir développé des hackers IA propriétaires ou des environnements de formation internes. Ces systèmes simulent continuellement des attaques et testent la manière dont des faiblesses pourraient apparaître en production.

Les participants à l’enquête ont décrit un objectif de zéro faux positif pour ces programmes. Cette norme est une ambition qui exige des preuves, et non une propriété générale des outils de sécurité basés sur l’IA.

Les faux positifs entraînent encore des coûts réels. Ils mobilisent du temps d’investigation, interrompent les équipes d’ingénierie et peuvent apprendre aux utilisateurs à ignorer les avertissements futurs.

Les faux négatifs sont plus dangereux. Un agent peut manquer une technique nouvelle parce que ses données d’entraînement ou ses outils disponibles ne représentent pas l’attaque.

Les responsables de la sécurité doivent donc évaluer l’automatisation à travers des résultats validés. Parmi les mesures utiles figurent les découvertes reproductibles, la couverture de détection, le délai de correction et le taux de conclusions d’agents rejetées.

La réponse imposée aux chercheurs est claire. Les équipes doivent automatiser la découverte répétitive tout en investissant davantage dans la revue, les tests et la gestion des preuves.

Cette pression devrait perdurer. Dès lors qu’une organisation intègre l’automatisation à son pipeline de recherche, le retour à un rythme manuel plus lent devient difficile.

La question la plus difficile est de savoir si les équipes peuvent faire évoluer le jugement au même rythme que la production générée. Cette question définit le conflit central auquel la recherche en sécurité est aujourd’hui confrontée.

Les chercheurs en sécurité de l’IA deviennent des directeurs, non des fouilleurs

Le principal enjeu de la profession est le jugement humain face à l’automatisation non supervisée, et non la vitesse humaine face à la vitesse des machines.

Les chercheurs en sécurité de l’IA ne créent plus de valeur en accomplissant personnellement chaque étape d’une enquête. Leur valeur dépend de plus en plus de leur capacité à décider quelles étapes doivent être exécutées, sous quelles contraintes et avec quelles exigences en matière de preuves.

Ce rôle s’apparente à une direction technique. Un chercheur peut confier à des agents distincts la revue du code source, la recherche dans la documentation, l’inspection des journaux ou le test d’hypothèses concurrentes.

Le travail parallèle élargit l’espace de recherche. Il crée aussi des problèmes de coordination qu’une enquête manuelle unique pourrait éviter.

Les agents peuvent répéter la même hypothèse erronée dans plusieurs branches. Ils peuvent perdre un contexte pertinent, poursuivre des théories séduisantes mais improductives ou produire des conclusions contradictoires.

Itzhaky a résumé le danger par un contraste percutant. Une réflexion négligente consommait autrefois un après-midi, mais elle peut désormais envoyer une flotte d’agents dans la mauvaise direction.

Cette affirmation illustre le renversement central. L’automatisation réduit le coût de l’action, mais elle peut multiplier le coût d’un objectif mal défini.

Un directeur humain doit traduire un objectif d’investigation en tâches limitées. Chaque tâche nécessite une cible, des outils autorisés, des conditions d’arrêt et une norme définissant ce qui constitue une preuve suffisante.

Le chercheur doit également décider du degré d’indépendance des agents. Plusieurs agents reproduisant le même schéma de raisonnement ne fournissent pas de confirmation significative.

Une meilleure conception sépare les rôles. Un agent peut générer des hypothèses, un autre peut remettre en question les hypothèses, et un outil contrôlé peut reproduire le comportement suspecté.

Même ce processus nécessite une revue humaine. Les modèles partagent des schémas d’entraînement, et un désaccord apparent ne garantit pas un raisonnement indépendant.

Ofek Haviv, chercheur en cybersécurité chez Terra Security, a soutenu que les chercheurs ne rivalisent pas avec les agents sur la vitesse. Leur valeur réside dans l’établissement de la norme que les résultats des agents doivent respecter.

Cette norme comprend la vérité technique, mais aussi la pertinence organisationnelle. Une faiblesse théorique peut avoir peu d’impact lorsque des contrôles rendent le chemin vulnérable inaccessible.

Inversement, une erreur mineure de configuration peut créer une exposition majeure lorsqu’un agent dispose de privilèges étendus. Le contexte détermine si une découverte exige une action urgente.

Les chercheurs doivent aussi comprendre les outils qui sous-tendent les réponses générées. Une personne examinant du code issu d’ingénierie inverse doit reconnaître lorsqu’un modèle invente un comportement ou interprète mal un flux de contrôle.

Idan Revivo, responsable de la recherche en sécurité chez Island, a mis en garde contre les nouveaux venus capables de solliciter des modèles sans avoir jamais appris à faire de l’ingénierie inverse de logiciels. Sa préoccupation n’est pas une résistance à l’automatisation.

Il s’agit d’un avertissement sur la capacité de vérification. Lorsqu’un modèle se trompe avec assurance, quelqu’un doit posséder une profondeur technique suffisante pour le remettre en question.

Cette exigence relève le niveau attendu des chercheurs juniors. Les postes débutants offraient traditionnellement une exposition répétée aux journaux, au code, aux systèmes et aux modes de défaillance courants.

Si les agents absorbent ces tâches, les nouveaux chercheurs risquent d’avoir moins d’occasions de développer leur intuition. Les équipes doivent remplacer délibérément cette pratique perdue par des laboratoires supervisés, des exercices de reproduction et des revues contradictoires.

L’enquête a révélé qu’un cinquième des répondants a mentionné l’effet de l’IA sur la prochaine génération de chercheurs. Roey Vilnai, directeur de la recherche cyber chez Axonius, a déclaré que l’accès aux connaissances a relevé les attentes à tous les niveaux d’expérience.

Tamir Ishay Sharbat, directeur de la recherche en sécurité chez Zenity, a proposé un point de vue complémentaire. Il est entré dans la cybersécurité sans expérience préalable et considère désormais l’utilisation de l’IA comme une exigence pour les chercheurs.

Ensemble, ces perspectives révèlent un défi de formation. L’IA peut élargir l’accès aux connaissances tout en facilitant la confusion entre compétence superficielle et expertise.

Les processus de recrutement devront évaluer à la fois l’utilisation des outils et le raisonnement indépendant. Un candidat doit pouvoir diriger un agent, examiner ses éléments de preuve et poursuivre lorsque le modèle échoue.

Les équipes doivent également préserver des exercices manuels pour les compétences essentielles. L’ingénierie inverse, le développement d’exploits, l’analyse des identités et le raisonnement réseau ne peuvent pas survivre comme savoirs purement théoriques.

Les meilleurs chercheurs combineront une exploration à l’échelle de la machine avec un scepticisme technique ancré dans la réalité. Ils sauront quand automatiser, quand restreindre le périmètre et quand arrêter le système.

Cette combinaison, et non la seule aisance dans la formulation de prompts, devient le nouveau niveau de référence de la profession.

Les identités non humaines élargissent la surface d’attaque

Les agents effectuant des tâches de sécurité deviennent aussi des identités privilégiées que les organisations doivent découvrir, restreindre, surveiller et révoquer.

Onze entreprises de l’enquête CTech ont identifié les agents d’IA comme un changement majeur du périmètre de sécurité. Les répondants ont regroupé ces agents avec les clés API, les comptes de service et d’autres identités non humaines.

Tomer Bar, vice-président associé de la recherche en sécurité chez Semperis, a déclaré que les identités non humaines sont déjà plus nombreuses que les personnes dans certaines organisations clientes. Il a estimé que ce ratio pourrait atteindre dix pour un dans les années à venir.

Cette projection est la prévision d’un dirigeant d’entreprise, et non une mesure de marché vérifiée indépendamment. Le problème sous-jacent des identités reste néanmoins concret.

Un agent a besoin d’accéder à des données, des applications et des outils pour accomplir un travail utile. Ces connexions lui confèrent une identité, un ensemble d’autorisations ou un accès emprunté via un autre compte.

Omer Nissim, chercheur en sécurité chez Sweet Security, a souligné le danger d’associer des autorisations étendues à un processus décisionnel imprévisible. Il a notamment évoqué les agents connectés via des serveurs Model Context Protocol.

Model Context Protocol, ou MCP, est une norme qui permet aux systèmes d’IA de se connecter à des outils externes et à des sources de données. Son utilité dépend de la façon dont ces connexions sont autorisées et limitées.

Un agent disposant d’un accès en lecture au code source présente un certain niveau de risque. Un agent capable de modifier des paramètres cloud, d’envoyer des messages ou de déployer du code en présente un autre.

OWASP décrit l’autonomie excessive comme une situation impliquant des fonctionnalités, des autorisations ou une autonomie excessives. Des sorties de modèle inattendues ou manipulées peuvent alors déclencher des actions dommageables.

Le problème fondamental n’est pas nécessairement une intention malveillante. Une instruction ambiguë, une conclusion hallucinée, un outil compromis ou un prompt injecté peut rediriger un agent par ailleurs légitime.

Le principe du moindre privilège reste la défense principale. Un agent ne devrait recevoir que les outils et les autorisations nécessaires à sa tâche actuelle.

L’accès en lecture seule est préférable lorsque le travail ne nécessite pas de modifications. Les actions à fort impact devraient emprunter des circuits d’approbation distincts et utiliser des identifiants aux privilèges strictement limités.

Les organisations ont également besoin d’identités individuelles pour les agents. Partager un identifiant humain avec un agent complique l’attribution et peut permettre au système d’usurper l’identité de son opérateur.

Les récentes orientations de NIST sur l’identité des agents recommandent de traiter les agents comme des entités distinctes. Chacun devrait disposer d’identifiants, d’identifiants d’accès et de droits liés à l’utilisateur ou au système responsable.

Ces orientations mettent également en évidence les risques liés aux clés API statiques et aux jetons porteurs de longue durée. Toute personne obtenant ces identifiants peut souvent les utiliser sans prouver qu’elle possède une identité spécifique.

Cela fait du stockage et de la rotation des identifiants un élément de la sécurité de l’IA. Les secrets des agents peuvent fuiter via les fichiers de configuration, les journaux, les magasins de mémoire, les sorties d’outils ou les enregistrements de débogage.

L’approbation humaine ne résout pas tous les problèmes. Des demandes d’autorisation constantes peuvent provoquer une fatigue du consentement et encourager les utilisateurs à approuver des actions sans examen attentif.

Une conception plus robuste attribue aux agents des limites opérationnelles approuvées. Ces limites devraient définir les ressources accessibles, les actions autorisées, les durées limites et les conditions d’escalade.

La surveillance doit capturer davantage que la réponse finale. Les équipes de sécurité ont besoin d’enregistrements des appels d’outils, de l’utilisation des identités, des données récupérées, des ressources modifiées et des décisions d’approbation.

Ces éléments soutiennent l’enquête sur les incidents et le contrôle qualité quotidien. Ils permettent aux chercheurs de reconstituer pourquoi un agent est parvenu à une conclusion ou a effectué une action.

La responsabilité doit aussi rester visible. Itzhaky a relevé que les agents peuvent être créés par des employés, des pipelines automatisés ou d’autres agents.

Sans propriétaire responsable, un agent oublié peut conserver des autorisations après la fin de sa tâche initiale. Ce schéma rappelle les comptes de service abandonnés, mais le comportement autonome rend l’exposition plus difficile à prévoir.

La découverte devrait donc inclure les inventaires d’agents, les identifiants, les outils, les accès aux données et les relations parent-enfant. La révocation doit mettre fin à la fois à l’agent et à tout accès délégué qu’il a créé.

C’est ici que le récit de productivité rejoint celui de la sécurité. Une organisation peut déployer des agents plus vite que son programme de gestion des identités ne peut les gouverner.

L’écart qui en résulte devient une nouvelle cible de recherche. Les équipes de sécurité doivent enquêter sur le comportement des agents tout en utilisant des agents pour enquêter sur tout le reste.

L’automatisation ne peut pas remplacer la validation sceptique

L’enquête reflète une véritable évolution des flux de travail, mais ses affirmations les plus fortes sur la productivité et la précision nécessitent encore des mesures indépendantes.

L’enquête CTech sur la sécurité de l’IA offre de précieuses observations de première main de chercheurs en activité. Sa cohorte de 30 personnes reste concentrée dans le secteur israélien de la cybersécurité.

L’article publié ne fournit pas d’échantillon aléatoire, de questionnaire standardisé ni de données de performance auditées indépendamment. Les lecteurs ne devraient pas considérer ses ratios comme des mesures universelles de la main-d’œuvre.

L’estimation d’une productivité décuplée par un répondant peut signaler un changement significatif sans prouver une multiplication par dix des découvertes validées. La production peut désigner des rapports, des hypothèses, des revues de code, des expériences ou des vulnérabilités confirmées.

Ces catégories n’ont pas la même valeur. Dix fois plus de découvertes initiales peuvent créer davantage de travail si la plupart ne résistent pas à la reproduction.

La même prudence s’applique aux affirmations d’absence de faux positifs. Un système peut réduire les fausses alertes en limitant ce qu’il signale, mais ce choix pourrait accroître le nombre de vulnérabilités manquées.

Les équipes doivent mesurer les deux aspects. La précision décrit combien de résultats signalés sont valides, tandis que le rappel décrit combien de faiblesses pertinentes le système détecte réellement.

Un outil peut paraître précis lorsqu’il ne signale que des problèmes évidents. Il peut néanmoins manquer des chaînes d’attaque subtiles, des logiciels inconnus ou des vulnérabilités exigeant un long raisonnement contextuel.

Les orientations de Google Cloud sur les vulnérabilités avertissent que les agents peuvent ignorer silencieusement des techniques nouvelles ou des vulnérabilités zero-day mal représentées dans les données d’entraînement.

Cette limite confère à l’expertise humaine un rôle précis. Les chercheurs doivent reconnaître lorsque la couverture d’une analyse est trop étroite et concevoir des tests en dehors des schémas familiers au modèle.

L’hallucination est une autre préoccupation. Un rapport généré peut citer des fonctions inexistantes, mal comprendre une dépendance ou déduire l’exploitabilité à partir d’un code incomplet.

La reproduction devrait donc se dérouler dans des environnements contrôlés. Un pipeline crédible devrait préserver les entrées, les versions des outils, les prompts, l’état du système et les résultats observables.

Les sorties des agents nécessitent aussi une modélisation des menaces. Un attaquant peut insérer du texte qui manipule un modèle, en particulier lorsque le système lit des sites web, des dépôts, des tickets ou des documents non fiables.

Cette attaque est appelée injection indirecte de prompt. Des instructions malveillantes sont dissimulées dans le contenu récupéré et tentent de rediriger le comportement de l’agent.

La défense ne peut pas reposer entièrement sur le fait de demander au modèle d’ignorer les mauvaises instructions. Les systèmes ont besoin d’outils isolés, d’autorisations limitées, de frontières de contenu et d’une approbation explicite pour les actions conséquentes.

Les chercheurs doivent aussi distinguer la confiance du modèle de la qualité des preuves. Des explications fluides peuvent donner l’impression qu’une découverte faible est complète.

Un processus d’examen robuste pose plusieurs questions concrètes. Le comportement peut-il être reproduit ? Le chemin vulnérable est-il atteignable ? Quels privilèges l’exploitation exige-t-elle ? Quel contrôle la bloque ou la détecte ?

Le processus devrait aussi consigner les hypothèses rejetées. Ces échecs aident les équipes à améliorer les benchmarks et empêchent les futurs agents de répéter le même chemin improductif.

Un benchmark de sécurité est un ensemble défini de tâches servant à tester le comportement d’un système. Les benchmarks internes devraient inclure des preuves trompeuses, un accès partiel, des défaillances d’outils et des catégories de vulnérabilités inconnues.

Les performances en production comptent davantage que les scores de benchmark. Les équipes devraient comparer les découvertes des agents avec les incidents ultérieurs, les revues manuelles et les tests indépendants.

Les relecteurs humains ont besoin d’être protégés contre le biais d’automatisation, c’est-à-dire la tendance à privilégier une recommandation machine simplement parce qu’un système l’a produite.

Faire tourner les relecteurs, masquer le score de confiance d’un agent ou demander une reproduction indépendante peut réduire ce biais. Les découvertes à fort impact méritent une séparation plus forte entre la découverte et l’approbation.

L’argument du sceptique ne signifie pas que les équipes devraient abandonner l’IA. La recherche manuelle manque également des vulnérabilités, suit de mauvaises hypothèses et souffre d’une documentation incohérente.

La conclusion la plus défendable est plus limitée. L’IA élargit la capacité de recherche, mais cette capacité ne devient utile que lorsque les équipes maintiennent une validation rigoureuse.

La nouvelle barre plus élevée n’est pas la perfection. C’est la capacité d’expliquer ce que l’agent a fait, de vérifier le résultat et de contenir les conséquences d’une erreur.

La sécurité continue devient le prochain test

La prochaine phase sera jugée à l’aune de la validation continue, d’une qualité de recherche mesurable et d’un contrôle applicable sur les identités des agents.

Le premier indicateur à surveiller est de savoir si l’évaluation continue de la sécurité remplace les tests périodiques dans les flux de travail de production. Plusieurs répondants à l’enquête ont soutenu que les tests d’intrusion semestriels ne correspondent plus au rythme des logiciels et de l’activité des attaquants.

L’évaluation continue consiste à tester les actifs à mesure que le code, les configurations, les identités et les expositions externes évoluent. Elle doit compléter les revues humaines approfondies, plutôt que de transformer la sécurité en un flux incessant d’alertes de scanners.

Google a décrit un pipeline de sécurité agentique qui analyse le code, produit des preuves et élabore des correctifs. L’entreprise a déclaré appliquer cette approche à des centaines de millions de lignes de code interne.

Ce système fournit un indicateur utile, car il relie la découverte à la reproduction et à la correction. La mesure déterminante est de savoir si d’autres organisations peuvent atteindre une discipline similaire avec des jeux de données, des équipes et des infrastructures plus modestes.

Une adoption large renforcerait l’affirmation centrale de l’enquête. Un bruit d’alerte persistant ou de faibles taux de correction l’affaibliraient.

Le deuxième signal concerne la manière dont les entreprises gouvernent les identités non humaines. Les inventaires d’agents devraient faire partie de la gestion des identités et des accès, et non constituer un document isolé de politique sur l’IA.

Des progrès utiles comprendraient des identifiants uniques pour les agents, des accès de courte durée, une autorisation déléguée, une propriété clairement attribuée et des journaux d’activité complets. Les organisations devraient également pouvoir suspendre un agent sans désactiver son opérateur humain.

Il faut surveiller les normes et produits qui relient les actions d’un agent à un utilisateur, une tâche et une limite opérationnelle approuvée spécifiques. Cette chaîne favorise la responsabilité sans partager d’identifiants personnels.

Si les déploiements continuent de s’appuyer sur des clés API étendues et des comptes de service génériques, la productivité dépassera la gouvernance. Ce résultat renforcerait les inquiétudes concernant les administrateurs fantômes et les voies d’accès imprévisibles.

Le troisième signal porte sur l’évolution du recrutement et de la formation. Les chercheurs débutants ont toujours besoin d’une pratique directe du code, des systèmes, de l’exploitation et de la collecte de preuves.

Les équipes devraient publier des attentes de compétence plus claires pour les rôles assistés par l’IA. Les entretiens et les programmes de formation peuvent vérifier si les candidats détectent des conclusions fabriquées, remettent en question les hypothèses des modèles et reproduisent les résultats manuellement.

Une transition saine créera des parcours d’apprentissage structurés autour de la supervision des agents. Les chercheurs expérimentés peuvent exposer les stagiaires aux exécutions réussies comme aux échecs.

Une transition malsaine supprimera le travail fondamental sans en remplacer la valeur éducative. Elle produirait des chercheurs capables d’utiliser des interfaces, mais incapables de vérifier les systèmes qui les sous-tendent.

Ces signaux comptent autant pour les acheteurs d’entreprise que pour les professionnels de la sécurité. L’utilisation de l’IA par un fournisseur ne dit pas grand-chose sans précisions sur les autorisations, les preuves, les revues et le traitement des défaillances.

Les acheteurs devraient demander qui valide les conclusions, comment les agents s’authentifient, quelles données ils conservent et si les résultats peuvent être reproduits. Ils devraient aussi demander comment le système réagit lorsqu’un outil échoue ou qu’une entrée contient des instructions malveillantes.

Les développeurs doivent s’attendre à ce que les revues de sécurité se rapprochent de chaque modification de code. Ils pourraient recevoir des retours plus rapides, mais les conclusions automatisées devront toujours fournir suffisamment de contexte pour permettre une correction.

Les travailleurs du savoir devraient s’y intéresser, car les problèmes d’identité des agents dépassent les outils de cybersécurité. Tout assistant connecté aux e-mails, aux documents, au code ou aux systèmes métier peut devenir une identité non humaine disposant de privilèges excessifs.

L’enquête de CTech sur la sécurité de l’IA décrit en définitive une redistribution du travail, et non la disparition des chercheurs. Les machines effectuent davantage de collecte et d’exploration. Les humains assument davantage de responsabilités concernant les objectifs, les contraintes et la vérité.

Cette organisation peut améliorer la sécurité lorsque les preuves restent centrales. Elle peut accroître le risque lorsque les organisations confondent activité générée et progrès vérifié.

La question pratique n’est plus de savoir si l’IA a sa place dans la recherche en sécurité. Elle est de savoir si les équipes peuvent rendre l’automatisation responsable avant que son échelle ne dépasse leur capacité à la superviser.

Demandez à vos fournisseurs de sécurité et à vos équipes internes un résultat complet obtenu avec l’assistance d’un agent, y compris ses autorisations, sa piste de preuves, sa revue humaine et sa décision finale. Ce dossier en révélera davantage qu’une vaste promesse de productivité.