SafeHarbor : un garde-fou à mémoire hiérarchique qui s'attaque au sur-refus des agents

De quoi s’agit-il ?

Le 7 mai 2026, Zhe Liu, Zonghao Ying, Wenxin Zhang, Quanchen Zou, Deyue Zhang, Dongdong Yang, Xiangzheng Zhang et Hao Peng ont publié SafeHarbor: Defining Precise Decision Boundaries via Hierarchical Memory-Augmented Guardrail for LLM Agent Safety (arXiv:2605.05704, cs.CR / cs.AI). Le papier a été accepté à ICML 2026, et les auteurs ont livré sur GitHub un code fonctionnel, des artefacts pré-construits et un harnais d’évaluation.

C’est un papier de défense, et son point de départ est un problème que reconnaîtra toute équipe ayant greffé un filtre de sécurité sur un agent outillé : la taxe de sur-refus. Rendez un garde-fou assez strict pour bloquer les attaques par détournement d’outils et il se met à refuser aussi du travail légitime — l’agent devient plus sûr et moins utile en même temps. SafeHarbor affirme qu’on peut faire évoluer les deux indicateurs dans le bon sens à la fois, sans réentraîner le modèle.

Comment ça marche

SafeHarbor se place devant le modèle cible sous la forme d’un proxy compatible OpenAI, prêt à brancher. Il ne nécessite aucun réentraînement du LLM sous-jacent : ni GPT-4o ni le modèle que vous ciblez n’est fine-tuné. Deux composants font le travail.

Le premier est un arbre de risques hiérarchique (Risk Tree) — une mémoire des schémas d’attaque passés, regroupés en nœuds, où chaque nœud porte une defense_strategy générée et une benign_boundary_rule. L’arbre est construit hors ligne en deux phases. Une étape de red team mute des échantillons malveillants via quatre stratégies — décomposition bénigne, injection d’arguments, déguisement de scénario et changement de format — en ne conservant que les mutations dont l’intention malveillante survit à une vérification par un LLM. Une étape de défense génère ensuite une stratégie de défense par cluster et calibre chaque règle face à des requêtes bénignes quasi identiques, de sorte que la règle apprend où passe réellement la frontière entre « bloquer » et « autoriser ». Un signal d’entropie informationnelle permet à l’arbre de s’auto-faire évoluer en scindant et fusionnant des nœuds à mesure qu’il grandit.

Le second est un projecteur de sécurité (Safety Projector) : un petit MLP à deux couches qui projette le plongement de phrase de dimension 384 dans un espace « conscient de la sécurité » de dimension 128, plus une tête binaire. Entraîné avec une perte triplet + BCE, son rôle est de découpler les directions liées à la sécurité de celles liées au sens dans l’espace des plongements — pour que la recherche s’appuie sur « est-ce dangereux ? » plutôt que sur « de quel sujet s’agit-il ? », précisément la confusion qui pousse les filtres par plongement naïfs au sur-refus.

À l’inférence, le proxy projette la requête entrante, récupère les preuves de risque les plus pertinentes dans l’arbre, et les injecte comme contexte de sécurité en tête avant de transmettre l’appel au modèle.

# Flux conceptuel — illustratif, tiré du dépôt public SafeHarbor.
requête --> Safety Projector (384d -> espace de sécurité 128d)
        --> récupère les k meilleurs nœuds du Risk Tree
        --> injecte {defense_strategy, benign_boundary_rule} comme contexte de sécurité
        --> transmet au LLM cible (sans fine-tuning)

Pourquoi c’est important

Les chiffres rapportés sont le cœur du sujet. Sur GPT-4o, SafeHarbor maintient un pic d’utilité bénigne de 63,6 % tout en gardant un taux de refus supérieur à 93 % sur les requêtes explicitement malveillantes, évalué sur AgentHarm et Agent-SafetyBench face aux références RAG, A-Mem, GuardAgent et Llama Guard. Que ces chiffres exacts tiennent sur votre charge réelle reste inconnu — ce sont des résultats d’un seul papier sur deux benchmarks, avec GPT-4o comme modèle vedette — mais le cadrage est la partie utile : un garde-fou doit se mesurer sur les deux axes, et le « taux de refus » seul est un score trompeur.

Cela s’inscrit aussi dans une tendance 2026 plus large. SafeHarbor est l’un de plusieurs garde-fous à mémoire auto-évolutifs apparus cette année — aux côtés de la mémoire de sécurité contrastive de Membrane — qui traitent la frontière entre sûr et non sûr comme quelque chose d’appris et recalibré en continu, plutôt que comme une liste de blocage figée. Pour les développeurs, cela marque un passage de « écrire de meilleurs prompts de refus » à « entretenir une mémoire vivante de schémas d’attaque et bénins ».

Défenses

SafeHarbor est lui-même un contrôle défensif ; la question pratique est donc d’adopter l’idée sainement.

Traitez tout garde-fou piloté par la mémoire comme une couche, pas LA couche. Comme les règles sont récupérées par similarité, une requête qu’aucun nœud ne ressemble retombe sur le jugement propre du modèle de base — gardez donc des contrôles déterministes en dessous : périmètres d’outils à moindre privilège, exécution en bac à sable et revue humaine quand le rayon d’impact est large. La conception de SafeHarbor s’empile d’ailleurs proprement sur des filtres au niveau du prompt comme Llama Guard.

Auditez les règles, pas seulement les verdicts. Le dépôt fournit un export lisible de chaque stratégie de défense et règle de frontière bénigne par cluster. Une mémoire construite à partir d’attaques auto-générées peut encoder une vision biaisée ou périmée du « sûr » ; revoyez-la comme vous revoyez un jeu de règles de pare-feu, et surveillez les règles de frontière bénigne pour repérer le sur-blocage.

Mesurez les deux axes avant et après déploiement. La leçon la plus transférable ici est méthodologique : rapportez ensemble l’utilité bénigne et le refus d’attaque, sur un benchmark incluant des tâches ambiguës mais légitimes, sinon vous livrerez un garde-fou qui paraît sûr et casse silencieusement le travail réel.

Enfin, attention à la surface de récupération elle-même. Un garde-fou dont la mémoire grandit à partir de données d’attaque ingérées hérite des risques d’empoisonnement de tout système de récupération — contrôlez ce qui est écrit dans l’arbre, et gardez le pipeline qui le fait évoluer aussi fiable que le modèle qu’il protège.

Statut

Élément	Référence	Date	Notes
Papier	arXiv:2605.05704	2026-05-07	Accepté à ICML 2026
Code + artefacts	github.com/ljj-cyber/SafeHarbor	2026	Licence MIT ; Risk Tree + Safety Projector pré-construits livrés
Résultat principal	Utilité bénigne 63,6 % / refus > 93 %	—	GPT-4o, sur AgentHarm + Agent-SafetyBench
Références comparées	RAG, A-Mem, GuardAgent, Llama Guard	—	Scripts de reproduction inclus

SafeHarbor ne mettra pas fin à la prompt injection ni au détournement d’outils — aucun garde-fou unique ne le fait. Sa contribution est plus étroite et utile : une manière concrète et reproductible de poursuivre la sûreté sans payer toute la taxe de sur-refus, et un rappel que toute évaluation honnête d’un garde-fou doit rapporter ce qu’il casse autant que ce qu’il bloque.