Recherche KENSAI : les préconditions battent les grandes promesses de sécurité agentique

La leçon utile des dernières opérations KENSAI est simple : la sécurité agentique n’a pas besoin d’une confiance plus bruyante. Elle a besoin de préconditions plus strictes avant qu’un résultat puisse devenir une affirmation.

Le vrai mode d’échec

L’automatisation de sécurité moderne est très forte pour générer de la sortie. Ce n’est pas la même chose que générer de la vérité. Un scanner peut renvoyer un signal passif sans impact. Un runner de tests peut échouer parce que l’API n’a jamais démarré. Un système de publication peut avoir un fichier dans un arbre alors que le miroir servi reste obsolète.

Ce sont des problèmes différents, mais ils partagent la même racine : le système a autorisé une affirmation aval avant de prouver la précondition amont.

Les préconditions sont le plan de contrôle caché

Pour la sécurité agentique, la couche des préconditions doit être traitée aussi sérieusement que la couche modèle. Avant qu’une suite de tests n’annonce des défauts produit, elle doit prouver que les services requis sont sains. Avant qu’une vulnérabilité n’avance vers la soumission, elle doit prouver son impact au lieu de compter de la recon passive comme progrès bounty. Avant de revendiquer la fraîcheur d’un contenu, la route live et l’index dérivé doivent correspondre au fichier source.

Ce que KENSAI impose

C’est moins glamour que d’ajouter une boucle d’agent de plus. C’est aussi plus précieux. Les préconditions transforment l’automatisation d’un narrateur sûr de lui en système contrôlé.

KENSAI applique déjà ce schéma dans les opérations bug bounty : les findings hors scope, à faible impact ou purement recon ne doivent jamais atteindre la soumission. Le même schéma appartient à l’ingénierie et à la publication. Une vérification de route bat une affirmation de dashboard. Un health check live bat un service supposé. Un gate de preuve bat une étiquette de sévérité.

Le principe opératoire

Les preuves de test du 26 avril l’ont encore montré. La suite racine a produit des centaines d’échecs, mais le premier correctif n’est pas de réécrire l’application à l’aveugle. Le premier correctif est de faire vérifier au runner que sa dépendance API est bien en ligne et que ses commandes coverage et e2e existent réellement.

Un agent utile devrait poser trois questions calmes avant de parler fort : le prérequis existait-il, l’artefact a-t-il changé, et la surface publique l’a-t-elle prouvé ? Si une réponse est non, la bonne sortie est un blocage avec preuve, pas un label de succès.

En bref

La norme utile est simple : une affirmation devient réelle quand le prérequis, l’artefact et la route s’alignent. Le travail du jour garde cette norme visible.