Qu’est-ce qu’un modèle cyber ? La catégorie, et ce qu’elle change réellement

Trois produits sont qualifiés de « modèle cyber » chaque semaine et ils n'ont presque rien en commun. L'un est un généraliste dont les données d'entraînement incluent des corpus de sécurité. Un autre est un modèle ordinaire enveloppé dans une boucle qui lui fournit un bac à sable, un fuzzer et des tentatives répétées. Un troisième est le même modèle que celui de tout le monde, derrière un formulaire de vérification. Seul le premier est un modèle différent. Les deux autres relèvent de décisions produit — bonnes, dans certains cas — et sont commercialisés avec la même expression, ce qui explique pourquoi la catégorie résiste à la comparaison. Un tableau comparatif qui ne précise pas lequel des trois il a mesuré ne peut pas être comparé à un tableau qui le précise, et la plupart des tableaux ne le précisent pas. Ceci est un guide sur la distinction, sur le petit nombre de modèles qui appartiennent véritablement à la première catégorie, et sur ce qu'une équipe de sécurité devrait faire de la réponse. C'est aussi la vue de catégorie qui sous-tend les 400 incidents liés à des agents catalogués dans l'archive des incidents d'IA, où la question « le modèle était-il le problème ou le déploiement » revient constamment.

Les trois choses que la phrase couvre

Commencez par la différence qui compte sur le plan opérationnel : ce qui a changé lorsque le fournisseur a construit la chose.

Entraîné pour la sécurité signifie que les poids ont changé. Des corpus de sécurité ont été intégrés au mélange d’entraînement, la base est souvent un modèle généraliste déjà performant, et le modèle obtenu est sensiblement différent sur les tâches où la connaissance en sécurité est le goulot d’étranglement — lire un crash, raisonner sur la disposition de la mémoire, reconnaître un schéma vulnérable dans un large diff. Les modèles de ce groupe sont généralement évalués sur des benchmarks spécifiques à la sécurité tels que CyberGym ou CyberSecEval, et ils peuvent être à poids ouverts ou uniquement accessibles via API.

Enveloppé dans un harnais signifie que la boucle a changé et que le modèle, non. Le fournisseur a ajouté un bac à sable, des outils, une logique de nouvelle tentative, un planificateur, peut-être un fuzzer, et a construit un système qui performe bien sur les tâches de sécurité parce que le système est bien conçu. C'est un produit légitime et souvent sous-estimé. C'est aussi la catégorie où un score devient ambigu, car le chiffre appartient autant au harnais qu'au modèle — et le harnais n'est pas quelque chose que l'on peut remplacer indépendamment.

Conditionné par l’accès signifie que la porte a changé. Le modèle peut être identique à un modèle public ; ce qui diffère, c’est que vous devez être une entreprise vérifiée, effectuant un travail autorisé, selon des conditions qui restreignent l’usage. Il s’agit d’un produit de politique, et d’un produit défendable, mais aucune affirmation de capacité n’en découle. Un modèle dangereux entre de mauvaises mains et sûr entre les bonnes n’est pas devenu plus capable ; il est devenu plus contrôlé.

La conséquence pratique : lorsque vous lisez qu’un modèle est « un modèle cyber », la question suivante est de savoir lequel des trois, car la réponse détermine si vous achetez une capacité, de l’ingénierie ou une autorisation — et ceux-ci ont des prix et des modes de défaillance différents.

Pourquoi la catégorie existe tout court

Le travail de sécurité est particulièrement sensible à deux propriétés que les modèles généraux manifestent de manière incohérente : le raisonnement sur de longs contextes portant sur du code qui n’a pas été écrit pour être lu, et la volonté de décrire une attaque avec suffisamment de détails pour être utile. La première est une question de capacité et explique pourquoi les modèles de ce groupe ont tendance à annoncer des fenêtres de contexte de centaines de milliers ou de millions de jetons. La seconde est une question de sûreté, et c’est la raison pour laquelle cette catégorie est liée au contrôle d’accès.

Un modèle qui raisonne bien sur une base de code mais refuse d’écrire une preuve de concept fonctionnelle est inutile pour le triage, car la preuve de concept constitue la preuve. Un modèle qui écrit librement des preuves de concept est utile à un défenseur et tout aussi utile à quelqu’un qui n’en est pas un. Les modèles ajustés à la cybersécurité sont, en pratique, une tentative de résoudre cette tension en restreignant qui peut poser la question plutôt que de restreindre ce à quoi il peut être répondu — ce qui est une conception cohérente et difficile à appliquer au niveau du modèle, puisque l’application est un processus de vérification plutôt qu’un changement de poids.

Là où la capacité est réellement argumentée

Les avantages revendiqués des modèles ajustés pour la cybersécurité sont précis et vérifiables, ce qui est rafraîchissant dans un domaine où l’on argumente généralement avec des adjectifs. Ceux qui reviennent sont l’ingestion en contexte long d’un dépôt ou d’une piste d’audit entier en une seule passe, une sortie structurée pour une utilisation dans des pipelines, et un appel d’outils ou de fonctions suffisamment stable pour s’intégrer à un flux de travail automatisé. Ce sont autant de promesses d’ingénierie que de promesses de modèle, et elles peuvent être testées sur votre propre corpus en un après-midi.

Le versant évaluation s’est doté de ses propres institutions. Wiz Research gère une Cyber Model Arena qui évalue des agents IA composés d’un modèle de fondation et d’un harnais standard sur des tâches de cybersécurité du monde réel, et rapporte la qualité des modèles en regard de l’efficacité — taux de réussite en fonction du coût, du temps ou du nombre d’étapes par résolution sur k tentatives indépendantes. Ce cadrage mérite d’être adopté intégralement, car il capture ce qu’un taux de réussite brut masque : deux agents peuvent atteindre le même taux de réussite à un coût par résolution très différent, et l’agent coûteux est souvent celui qui a dépensé son budget en nouvelles tentatives.

Notez ce que cette construction implique. Il s’agit d’un benchmark d’agents, pas de modèles — modèle de fondation plus harnais — ce qui correspond exactement à l’ambiguïté de cette catégorie. L’arène est honnête à ce sujet en nommant le harnais dans la définition. La plupart des posts de lancement ne le sont pas.

La porte d’accès, et pourquoi elle constitue la véritable frontière de la catégorie

Si l’on examine la manière dont les modèles ajustés pour la cybersécurité sont réellement livrés, l’étape de vérification est plus déterminante que n’importe quel chiffre de benchmark, car elle détermine qui peut même réaliser l’évaluation. Le schéma est constant : une étape de vérification d’entreprise, des conditions qui limitent l’usage à des travaux de sécurité autorisés, et une politique d’utilisation acceptable au regard de laquelle l’accès est journalisé.

Deux détails de conception dans ce schéma méritent d'être repris, même si vous n'achetez jamais un modèle cyber. Le premier est la vérification de l'entreprise plutôt que l'auto-attestation, car une case à cocher n'est pas un mécanisme de responsabilité. Le second est de co-localiser le portail avec les contrôles d'exécution — la même passerelle qui héberge le modèle héberge aussi le pare-feu, les garde-fous et la journalisation, de sorte que l'autorisation et son application se trouvent au même endroit. Un portail de vérification qui réside sur un système différent de celui du trafic est un portail que l'on ne peut pas auditer.

Notre propre palier cyber suit cette même logique : des modèles pour le travail offensif, des contrôles de passerelle pour le travail défensif, et une vérification en amont des deux. C'est aussi la réponse honnête à la question « puis-je simplement appeler ce modèle » — pour le palier offensif, la réponse est que l'accès est une décision que quelqu'un prend à votre sujet, et non un champ dans une requête API.

Quels sont les modèles cyber existants, et comment les distinguer ?

La population est assez petite pour qu’on puisse la garder en tête, et elle se répartit selon les trois catégories ci-dessus plutôt que par fournisseur.

• Des modèles véritablement ajustés pour la cybersécurité. Entraînés sur des données à forte composante sécurité, généralement évalués sur CyberGym ou CyberSecEval, avec une différence mesurable dans les tâches de lecture de crash et d’écriture de correctifs. Certains sont à poids ouverts, ce qui rend l’évaluation locale possible ; d’autres sont uniquement accessibles via API et sous vérification.

• Généralistes dotés d’un solide comportement en matière de sécurité. Modèles de pointe qui se trouvent être performants dans ce travail sans y avoir été spécialement ajustés. Souvent le bon choix pour les défenseurs, car le même modèle assure aussi le reste de la tâche.

• Produits agentiques. Un modèle plus une boucle spécifique à la sécurité — bac à sable, fuzzer, planificateur — vendu comme un système. Jugez-les sur le coût par résolution et sur ce que fait la boucle lorsqu’elle échoue, pas sur un benchmark de modèle.

• Versions à accès restreint de ce qui précède. Mêmes modèles, accès restreint. La restriction change qui peut les utiliser, pas ce qu’ils peuvent faire.

La comparaison qui compte vraiment pour une équipe de sécurité est rarement modèle contre modèle. C’est de savoir si le travail à accomplir est lié aux connaissances ou lié à l’exécution en boucle. Lire un rapport d’audit et raisonner sur une chaîne d’exploitation est lié aux connaissances et favorise un modèle ajusté. Faire tourner un fuzzer pendant six heures et trier les plantages est lié à l’exécution en boucle et favorise une bonne ingénierie. La plupart des programmes réels ont besoin des deux, c’est pourquoi la question d’achat utile est « pour laquelle de ces deux tâches est-ce que j’achète » plutôt que « quel modèle obtient le meilleur score ».

Que demander avant d’en adopter un

Cinq questions distinguent une décision de catégorie d'une décision marketing.

• Qu'est-ce qui a changé — les pondérations, la boucle ou l'accès ? Le fournisseur devrait pouvoir répondre en une phrase. Si la réponse est « la boucle », évaluez le produit en tant que produit.

• Quel benchmark, réalisé par qui, dans quel harnais ? Un chiffre CyberGym sans le harnais est un chiffre concernant une configuration que vous ne pouvez pas reproduire.

• Quel est le coût par résolution, et non le taux de réussite ? Le cadrage de Wiz est le bon ; deux agents ayant le même taux de réussite ne représentent pas le même achat.

• Que fait le portail lorsque j’échoue ? Tout déploiement qui repose sur un accès vérifié devrait vous indiquer ce qui se passe en cas de faux négatif, car ce sont vos propres ingénieurs qui seront les faux négatifs.

• Que ne peut-il pas faire ? Les variantes exclusivement défensives documentent leurs propres limites, et cette documentation est un atout — un modèle qui ne peut pas être détourné vers l’offensive est un objet de risque différent de celui qui le peut.

La catégorie est réelle, les différences de capacités sont réelles, et l'essentiel de la confusion vient de trois produits différents qui partagent un même nom. Une fois que l'on distingue les poids de la boucle et de la porte, les tableaux comparatifs cessent d'être contradictoires et se mettent à porter sur des choses différentes — ce qui est la seule condition dans laquelle une équipe de sécurité peut s'en servir pour prendre une décision.