🤖 AI

SecureClaw: Clawing Back Control of LLM Agents

SecureClaw est une architecture de sécurité à double frontière pour les agents LLM utilisant des outils qui empêche les actions externes non autorisées et l'exposition de données sensibles en imposant une passerelle de confiance pour les opérations de lecture et un protocole PREVIEW-to-COMMIT pour les opérations d'écriture, atteignant un taux de réussite d'attaque proche de zéro sur plusieurs benchmarks tout en maintenant l'utilité des tâches.

Auteurs originaux : Yuhan Ma, Stefan Schmid

Publié 2026-06-09

📖 5 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Yuhan Ma, Stefan Schmid

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous engagiez un assistant personnel très intelligent, mais peu fiable (l'Agent LLM) pour gérer vos tâches sensibles, comme payer des factures, lire vos e-mails privés ou gérer votre calendrier.

Le problème est que cet assistant est un peu imprévisible. Si vous lui donnez un document contenant votre numéro de compte bancaire, il pourrait accidentellement (ou malicieusement) le lire à voix haute à un étranger, ou bien il pourrait être piégé par une note cachée dans un e-mail pour envoyer votre argent à un escroc.

Les gardes de sécurité actuels essaient généralement d'empêcher l'assistant de faire la mauvaise chose (comme envoyer l'argent), mais ils échouent souvent à l'empêcher de voir le secret en premier lieu. Une fois que l'assistant a vu le secret, il peut le chuchoter à d'autres programmes ou l'écrire dans ses notes avant même qu'un garde n'ait le temps de l'arrêter.

SecureClaw est un nouveau système de sécurité conçu pour résoudre ces deux problèmes à la fois. Il traite le fait de « voir » et le fait de « faire » comme deux tâches distinctes qui nécessitent deux verrous différents.

Voici comment cela fonctionne, en utilisant une analogie simple :

Les deux verrous de SecureClaw

1. Le « Bandeau » pour la lecture (La Passerelle)

Imaginez que votre assistant doive consulter une facture secrète pour savoir quel montant payer.

L'ancienne méthode : Vous donnez à l'assistant la facture papier réelle. Il peut lire les chiffres, les copier ou même les lire à voix haute à un pirate qui écoute.
La méthode SecureClaw : Vous ne lui donnez pas la facture. À la place, vous lui donnez une boîte mystère (une « poignée opaque ») et une petite note simplifiée (un « résumé borné »).
- La note dit : « Facture de l'entreprise A, 4 200 $, échéance vendredi. »
- La boîte mystère est un code que seul le coffre-fort sécurisé sait ouvrir.
- L'assistant peut planifier son travail en utilisant la note et le code, mais il ne peut pas ouvrir la boîte pour voir les détails réels de la facture. Il ne peut pas copier les vrais chiffres car il ne les a jamais vus.

2. Le « Double Vérification » pour l'action (L'Exécuteur)

Maintenant, imaginez que l'assistant veuille envoyer un e-mail pour payer cette facture.

L'ancienne méthode : L'assistant écrit l'e-mail et appuie sur « Envoyer ». Si un pirate a piégé l'assistant pour changer l'adresse e-mail vers celle d'un escroc, l'argent part chez l'escroc.
La méthode SecureClaw : L'assistant peut seulement proposer l'e-mail. Il rédige un brouillon et dit : « Je veux envoyer ceci. »
- Un Gardien de Confiance (l'Exécuteur) récupère le brouillon.
- Le Gardien vérifie : « Avez-vous bien demandé d'envoyer ceci ? Le destinataire est-il correct ? Le montant est-il exact ? »
- Crucialement, le Gardien vérifie les détails exacts en les comparant à un reçu scellé et immuable de ce qui a été initialement approuvé.
- Si l'assistant avait tenté de changer discrètement l'adresse e-mail pour celle d'un escroc après avoir obtenu l'approbation, le Gardien verrait l'incohérence et bloquerait l'e-mail. Seul le Gardien a le pouvoir de réellement appuyer sur « Envoyer ».

Pourquoi est-ce une avancée majeure ?

Le papier a testé ce système contre trois différents « terrains de jeu pour hackers » (AgentDojo, AgentLeak et ASB) où des attaquants ont tenté de piéger les agents pour voler des données ou envoyer de l'argent aux mauvaises personnes.

Le résultat : SecureClaw est le seul système qui a réussi à stopper 100 % des transferts d'argent non autorisés (0 % de succès d'attaque) et a réduit les fuites de données secrètes à presque zéro.
La recette secrète : Le papier prouve qu'on ne peut pas utiliser un seul verrou.
- Si vous n'utilisez que la « Double Vérification » (arrêter l'envoi), l'assistant peut toujours lire le secret et le divulguer via ses notes internes.
- Si vous n'utilisez que le « Bandeau » (cacher le secret), l'assistant pourrait quand même être piégé pour envoyer un message à la mauvaise personne s'il n'a pas le secret au départ.
- SecureClaw utilise les deux. Il garde les secrets cachés de l'assistant et garantit que l'assistant ne peut pas forcer une action sans une vérification finale de confiance.

Que se passe-t-il quand il dit « Non » ?

Parfois, le système bloque une requête parce qu'elle semble suspecte. Par le passé, cela aurait simplement arrêté tout le flux de travail, frustrant l'utilisateur. SecureClaw possède une fonction de « Récupération Sécurisée ».

Si le Gardien bloque une requête, au lieu de simplement dire « Erreur », il donne à l'assistant une voie pré-approuvée et sûre pour réessayer.

Exemple : « Je ne peux pas envoyer cet e-mail à l'étranger. Mais je peux préparer un brouillon pour que vous puissiez le réviser d'abord. »
Cela permet de maintenir le travail en cours sans abaisser les standards de sécurité.

L'essentiel

SecureClal est comme engager un garde du corps qui porte un bandeau lorsqu'il lit votre journal intime (pour ne pas mémoriser vos secrets) et qui détient les clés de votre voiture (pour ne pas vous conduire vers un endroit dangereux sans vérifier la carte au préalable). Il sépare la capacité de planifier de la capacité d'agir, garantissant que même si l'assistant est piégé, les dégâts sont contenus.

Résumé Technique : SecureClaw

Énoncé du Problème

Les agents de modèles de langage (LLM) utilisant des outils font face à deux modes de défaillance de sécurité distincts et non interchangeables que les défenses existantes ne parviennent souvent pas à traiter simultanément :

Effets Externes Non Autorisés : Le risque qu'un agent, potentiellement compromis par une injection de prompt ou un comportement d'exécution adverse, exécute des actions (ex: envoyer des e-mails, transférer des fonds) qui n'étaient pas autorisées pour le contexte, la session ou l'appelant spécifique.
Exposition de Texte Clair au Moment de l'Exécution : Le risque que des données sensibles (ex: factures, dossiers médicaux) soient exposées en texte clair au runtime LLM non fiable. Même si une action ultérieure est bloquée, le runtime peut déjà avoir « lu » le secret et peut le transmettre via des canaux internes (messages inter-agents, mémoire partagée, journaux) que les mécanismes d'audit de type « sortie uniquement » ne détectent pas.

Les défenses actuelles protègent généralement une seule frontière : soit le planificateur/runtime (via le filtrage de prompt), soit le récepteur d'action (via la vérification des arguments). L'article soutient que protéger le récepteur ne permet pas d'empêcher la fuite interne si le runtime a déjà accédé aux secrets bruts, et que protéger le runtime ne permet pas d'empêcher les engagements non autorisés si le récepteur n'est pas médiatisé.

Méthodologie : Architecture SecureClaw

SecureClaw introduit une architecture à double frontière qui sépare le contrôle des effets externes de l'accès aux données sensibles en texte clair. Elle repose sur une infrastructure de confiance (Passerelle, Magasin de Handles, Moteur de Politiques, Exécuteur) distincte du runtime de l'agent non fiable.

1. Chemin de Lecture : Confinement par Handles Opaques

Mécanisme : Lorsque le runtime demande des données sensibles, une Passerelle de Confiance intercepte la lecture. Au lieu de retourner le texte clair brut, la passerelle stocke les données dans un Magasin de Handles de Confiance et retourne un handle opaque (une référence symbolique à haute entropie) au runtime.
Déclassification : Si l'agent nécessite des informations pertinentes pour la tâche afin de planifier, la passerelle fournit un résumé limité (ex: « facture du Fournisseur A, 4,2 k$ »). Ce résumé est traité comme une interface de déclassification explicite, et non comme une fuite de texte clair.
Contrainte : Le runtime peut router et stocker des handles mais ne peut pas les déréférencer pour récupérer les secrets bruts. Les canaux internes (C2, C5) transportent des références symboliques, pas des secrets.

2. Chemin d'Écriture : Protocole PREVIEW $\rightarrow$ COMMIT

Mécanisme : Le runtime propose une action à effet (intention + entrées). Une Passerelle de Confiance ajoute un contexte authentifié (appelant, session, champs de destination) et canonicalise la requête en un digest de liaison ( $h$ ).
Autorisation : Un Moteur de Politiques autorise la requête canonique exacte et retourne un artefact d'autorisation lié à $h$ .
Exécution : Un Exécuteur de Confiance est le seul composant capable d'atteindre le récepteur externe. Avant de valider (commit), il :
1. Re-calcule le digest de liaison $h$ .
2. Vérifie l'artefact d'autorisation.
3. Vérifie la fraîcheur, le statut de rejeu et la résolution du handle.
4. Valide l'action uniquement si la requête correspond exactement à la forme canonique autorisée.
Intégrité : Toute mutation de la requête (ex: changer un destinataire) après la phase de preview altère la forme canonique, invalidant l'artefact d'autorisation et provoquant l'échec par défaut (fail-closed) de l'exécuteur.

3. Récupération Sensible au Refus (Deny-Aware Recovery)

Pour maintenir l'utilité lorsque les actions sont bloquées, le système utilise un mécanisme de récupération sensible au refus. Au lieu de terminer le flux de travail, le système retourne un refus structuré avec une raison grossière et un indice de prochaine étape sécurisé (ex: « brouillon pour confirmation » au lieu de « envoyer »), préservant la continuité du flux sans relâcher les invariants de sécurité.

Contributions Clés

Décomposition de la Sécurité : L'article identifie deux exigences de sécurité non substituables pour les agents utilisant des outils : l'autorisation liée à la requête pour les effets externes et le confinement du texte clair sensible loin du runtime non fiable.
Architecture à Double Frontière : SecureClaw implémente ces exigences via une passerelle de confiance (pour le confinement de la lecture) et un exécuteur de confiance (pour l'autorisation d'écriture), en utilisant des handles opaques et une déclassification explicite.
Évaluation en Environnement Commun : Les auteurs évaluent SecureClaw par rapport à quatre bases de référence (Plain, IPIGuard, DRIFT, Faramesh) à travers trois benchmarks (AgentDojo, AgentLeak, ASB) en utilisant un harnais identique pour garantir une comparaison équitable.

Résultats Expérimentaux

Évalué sur gpt-4o-mini avec une température de 0 :

Agent Security Bench (ASB) : SecureClaw a atteint un Taux de Succès d'Attaque (ASR) de 0 %, surpassant de manière significative les bases de référence (ex: DRIFT à 87,75 % d'ASR). Il a maintenu une utilité de 88,90 % sur les tâches bénignes.
AgentDojo : A obtenu un ASR de 0,64 % (4/629 attaques), contre 2,38 % pour la meilleure base de référence suivante (DRIFT).
AgentLeak : A atteint une fuite globale de 3,23 % sur la voie de parité attaquée. Crucialement, il a réduit les fuites de relais internes (C2 et C5) à presque zéro (0,20 % et 0,00 % respectivement), alors que les bases de référence comme Faramesh (qui manque de confinement de lecture) présentaient une fuite interne élevée (92,74 % sur C2).
Études d'Ablation : La suppression du mécanisme de handle a fait réapparaître les fuites C2/C5, tandis que la suppression de la frontière d'exécution n'a pas affecté la fuite interne mais n'a pas réussi à arrêter les engagements non autorisés. Cela confirme que les deux mécanismes protègent des surfaces distinctes.
Robustesse : Dans une suite de contournement de 29 scénarios adverses (altération d'artefacts, rejeu, mélange de sessions), SecureClaw a refusé les 25 tentatives d'attaque tout en autorisant 4 contrôles légitimes.
Surcharge (Overhead) : La vérification de l'exécuteur est inférieure à la milliseconde ; l'autorisation de service unique ajoute environ 15 ms. Ces coûts sont négligeables par rapport aux latences d'inférence des LLM (500–2000 ms).

Signification et Revendications

L'article affirme que la sécurisation des agents LLM nécessite une séparation structurelle plutôt que des défenses locales au runtime.

Non-Substituabilité : L'évaluation démontre que l'autorisation côté récepteur et le confinement côté lecture sont complémentaires ; l'un ne peut substituer l'autre. Un engagement bloqué ne peut pas annuler un secret déjà relayé via la mémoire, et un handle ne peut pas empêcher un runtime compromis de tenter des actions non autorisées.
Modèle de Confiance : SecureClaw déplace la confiance du runtime non fiable vers un ensemble minimal de composants de confiance (Passerelle, Magasin de Handles, Moteur de Politiques, Exécuteur). Il ne prétend pas garantir la correction sémantique des actions autorisées par la politique (ex: si une politique est trop large, l'agent pourrait encore agir sur le mauvais objet), ni survivre à la compromission de ses propres composants de confiance.
Résiduels : Les échecs restants se concentrent sur le plan de déclassification (les résumés autorisés révélant des informations) ou le désalignement de la politique (actions autorisées qui sont sémantiquement erronées par rapport à l'intention de l'utilisateur), plutôt que sur des contournements des invariants de sécurité de base.

Les auteurs concluent que SecureClaw est le seul système évalué dans leur étude qui parvient simultanément à réduire les effets externes non autorisés à zéro/proche de zéro et à éliminer le relais de texte clair interne, tout en conservant une utilité de tâche élevée grâce à la récupération sensible au refus.