AutoSpec : apprendre aux règles de sécurité des agents à corriger leurs faux positifs

De quoi s’agit-il ?

La plupart des équipes qui laissent un agent LLM exécuter des outils finissent par rédiger une liste de règles de sécurité : ne pas lancer rm -rf, ne pas envoyer de courriel hors de l’entreprise, ne pas toucher à l’API de paiement sans validation. Ces règles sont lisibles et faciles à auditer — c’est précisément pour cela qu’on les apprécie. Elles sont aussi fragiles. Trop serrées, elles bloquent l’agent dans son travail légitime ; trop lâches, elles laissent passer des actions dangereuses. Toute personne ayant réglé un garde-fou à la main connaît la partie de taupe qui s’ensuit.

Un article publié sur arXiv fin juin 2026, AutoSpec : Safety Rule Evolution for LLM Agents via Inductive Logic Programming (2606.24245), propose une sortie de cette course sans fin au réglage. Au lieu de demander à des humains de réécrire sans cesse les règles, AutoSpec apprend les modifications automatiquement à partir d’exemples étiquetés de comportements d’agent sûrs et non sûrs, à l’aide d’une technique classique de synthèse de programmes — la programmation logique inductive (ILP) — plutôt que d’une nouvelle boîte noire neuronale. Le résultat reste un ensemble de règles lisibles par un humain : on conserve donc l’auditabilité qui rendait les règles séduisantes au départ.

Comment ça marche

La boucle centrale est la synthèse inductive guidée par contre-exemples (CEGIS). On part des règles rédigées par les experts que l’on possède déjà, plus un jeu de données d’actions d’agent annotées comme sûres ou non sûres. AutoSpec répète alors un cycle simple :

1. Évaluer les règles courantes sur les données étiquetées.
2. Extraire les erreurs :
     - faux positifs  = actions sûres bloquées à tort
     - faux négatifs   = actions non sûres autorisées à tort
3. Lancer l'ILP pour trouver les prédicats qui discriminent les deux —
   des caractéristiques fréquentes dans les faux négatifs mais rares
   dans les faux positifs (ou inversement).
4. Proposer des modifications de règles candidates bâties sur ces prédicats.
5. Vérifier chaque candidate ; conserver la révision au meilleur score.
6. Répéter jusqu'à ce que les règles cessent de s'améliorer.

L’astuce est à l’étape 3. L’espace des modifications possibles est exponentiel, si bien que le parcourir à l’aveugle est sans espoir. L’ILP l’élague en identifiant quels prédicats — des propriétés comme « l’outil est shell.exec », « le chemin cible est hors de l’espace de travail », « le domaine du destinataire est externe » — séparent réellement les erreurs des décisions correctes. On transforme ainsi « deviner une meilleure règle » en « combiner les quelques caractéristiques qui expliquent les erreurs », ce qui devient traitable.

Comme l’ensemble opère sur des règles symboliques et non sur des poids de modèle, chaque changement est inspectable. On peut faire un diff du jeu de règles avant et après, lire la nouvelle clause en logique claire, et la rejeter si elle paraît fausse. C’est une différence de fond avec le réglage d’un classifieur, où le « pourquoi » reste enfoui dans les paramètres.

Pourquoi c’est important

Les garde-fous d’agents occupent une position réellement difficile. L’espace d’actions est vaste, un même appel d’outil peut être sûr ou catastrophique selon le contexte, et le coût d’un faux négatif — un agent qui efface une base de production ou exfiltre un secret — n’est pas symétrique de celui d’un faux positif. Les équipes répondent en sur-bloquant, ce qui pousse les utilisateurs à désactiver le garde-fou, situation pire que de n’en avoir aucun.

AutoSpec rapporte des scores F1 de 0,98 et 0,93 sur deux domaines et réduit les faux positifs jusqu’à 94 %, tout en produisant des règles qui généralisent à des scénarios absents de l’entraînement. Si ces chiffres tiennent en réplication indépendante, le gain pratique n’est pas seulement l’exactitude : c’est que l’on peut abaisser le taux de faux positifs sans relâcher discrètement la sécurité, puisque le même processus fait simultanément baisser les faux négatifs. Cela s’inscrit dans un courant plus large visant à contraindre les agents pilotés par LLM à l’aide de spécifications explicites et vérifiables plutôt qu’à espérer que le modèle se comporte bien, illustré par des travaux antérieurs sur l’application de contraintes aux agents robotiques.

Deux réserves méritent d’être posées clairement. D’abord, des règles apprises ne valent que ce que valent les étiquettes : un jeu d’annotations biaisé ou trop maigre produit des règles confiantes et fausses. Ensuite, une couche de règles est un moteur de politique, pas une compréhension sémantique de l’intention — elle ne détectera pas une action non sûre qui ressemble, caractéristique par caractéristique, exactement à une action sûre. C’est un composant de défense en profondeur, pas une solution miracle.

Défenses

Pour quiconque exploite des agents outillés, les enseignements sont concrets.

1. Conservez un corpus étiqueté de décisions d’agent. Que vous adoptiez AutoSpec ou non, la matière première de tout garde-fou améliorable est un ensemble croissant d’actions marquées sûres ou non sûres. Instrumentez votre agent pour journaliser les appels d’outils avec assez de contexte (nom de l’outil, arguments, cible, appelant) pour les étiqueter ensuite.

2. Privilégiez les couches de politique interprétables quand c’est possible. Une règle que l’on peut lire et différencier est une règle que l’on peut auditer, annuler et raisonner pendant un incident. Réservez les classifieurs opaques aux cas où des règles symboliques ne peuvent réellement pas exprimer le signal.

3. Mesurez les deux types d’erreur, pas seulement les blocages. Suivez les faux négatifs (actions non sûres autorisées) autant que les faux positifs (actions sûres bloquées). Un garde-fou qui ne rapporte que ses blocages masque ses défaillances les plus dangereuses.

4. Traitez le jeu de règles comme du code versionné et relu. Si les règles évoluent — à la main ou automatiquement — chaque changement doit passer par une relecture de diff, et les ajouts appris à partir des données doivent être éprouvés contre des exemples adverses avant mise en production.

5. Superposez les couches. Combinez un moteur de règles/politique avec de la surveillance à l’exécution, un cadrage d’outils au moindre privilège et une validation humaine pour les actions à fort rayon d’impact. Aucune couche unique, apprise ou écrite à la main, ne doit être votre seule ligne.

Statut

Élément	Référence	Date	Notes
Article AutoSpec	arXiv 2606.24245	2026-06 (fin)	Évolution de règles ILP/CEGIS à partir d’étiquettes sûr/non sûr
Résultats rapportés	Idem	2026-06	F1 0,98 / 0,93 ; faux positifs réduits jusqu’à 94 %
Travaux antérieurs liés	Brown H2R « Safety Chip »	2024	Application de contraintes explicites aux agents pilotés par LLM
Référence de cadrage	OWASP LLM Top 10	2025	Agentivité excessive / gestion non sûre des sorties

La bonne lecture n’est pas « les garde-fous sont résolus ». C’est que l’arbitrage faux positifs / faux négatifs qui rend épuisantes les règles d’agent écrites à la main peut s’attaquer comme un problème d’apprentissage — et, surtout, s’attaquer de manière à laisser des règles qu’un humain peut encore lire. Cette combinaison, exactitude plus auditabilité, est ce qui manque à la plupart des garde-fous en production aujourd’hui.