Le harnais de l'agent est votre vrai périmètre de privilège — et la plupart des équipes le placent au mauvais endroit

De quoi s’agit-il ?

Le 26 mai 2026, Dor Sarig de Pillar Security a publié Your Agent Harness Has More Privilege Than Your Agent. L’argument est court et structurant : dans un agent de codage moderne — Claude Code, Cursor, Codex, Aider, Cline — le modèle est le moteur, mais le harnais est la voiture. C’est le harnais qui détient les clés d’API, qui médie les appels d’outils, qui contrôle les permissions du système de fichiers, qui écrit le journal de session et qui décide même de ce que le modèle voit à chaque tour. Si votre modèle de sécurité considère l’agent (le LLM dans la boucle) comme l’unité de risque, vous avez tracé la frontière au mauvais endroit.

Deux signaux récents et indépendants rendent l’argument concret. La divulgation de Pillar du 14 janvier 2026 concernant Cursor (CVE-2026-22708) a montré comment des builtins shell hors de l’allowlist du harnais permettaient à un attaquant d’empoisonner des variables d’environnement et de transformer un git branch jugé inoffensif en exécution de code arbitraire. Et le post-mortem du 23 avril d’Anthropic sur la qualité de Claude Code attribue deux mois de dégradation perçue à trois changements dans le harnais — pas dans le modèle — dont un bug de cache qui supprimait silencieusement l’historique de raisonnement en cours de session. C’est dans le harnais que se concentre l’effet de levier. C’est aussi là que se concentrent les bugs.

Comment cela fonctionne

Un harnais, c’est l’architecture fixe qui transforme un LLM one-shot en quelque chose capable d’agir. Il détient plusieurs ressources que l’agent — le modèle dans la boucle — ne manipule jamais directement :

Composant                       Détenu par le harnais ?   Détenu par le modèle ?
------------------------------  ------------------------  ------------------------
Clés d'API / secrets            Oui                       Non
Implémentation des outils       Oui                       Non (descriptions seules)
Classifieur de permissions      Oui                       Non
Accès au système de fichiers    Oui                       Routé via les outils
Journal d'événements de session Oui                       Non
Compaction de contexte          Oui                       Non
Assemblage du system prompt     Oui                       Non
Hooks (pré / post tool)         Oui                       Non
Spawn et policy des sous-agents Oui                       Non

Sarig détaille les surfaces d’attaque que cela crée, en s’appuyant sur les recherches Pillar sur Cursor et sur des motifs désormais visibles dans tous les harnais de codage majeurs.

Les descriptions d’outils sont une surface d’injection de prompt. Le modèle est orienté par des descriptions que le harnais charge à chaque tour. Une description empoisonnée — via une compromission supply-chain, un serveur MCP malveillant ou une mise à jour de registre — redirige silencieusement le choix d’outil. Il n’y a généralement aucune entrée de journal qui dise « la description a changé mardi dernier ».

L’assemblage du system prompt parcourt l’arborescence. Les harnais modernes scannent les répertoires parents à la recherche de fichiers comme CLAUDE.md, AGENTS.md, .cursor/rules et injectent ce qu’ils trouvent. Un fichier malveillant déposé n’importe où dans l’arborescence finit dans le system prompt. C’est intentionnel — et c’est un véritable vecteur d’attaque dès que l’agent opère sur un dépôt non fiable.

Les hooks sont le point d’extension le plus puissant — et le plus dangereux. Les hooks pre-tool peuvent autoriser, refuser ou réécrire un appel d’outil. Un hook compromis est un man-in-the-middle silencieux pour chaque appel. Les hooks post-tool voient chaque résultat. L’adoption en entreprise passe de plus en plus par les hooks, ce qui veut dire que la compromission en entreprise peut passer par eux aussi.

La compaction de contexte est une perte de mémoire sélective. Quand la fenêtre de contexte se remplit, le harnais résume ou supprime les contenus anciens. Ce qui est supprimé — y compris une instruction malveillante vue au tour 12 — peut continuer à influencer l’agent au tour 47 sans rester disponible pour un auditeur. Les stratégies de compaction sont généralement heuristiques et rarement testées contre des entrées adverses.

Les classifieurs de permission parsent des chaînes. Les allowlists de style bash sont typiquement décidées en parsant la commande au moment du dispatch. rm saute en approbation complète. ls reste read-only. Mais find . -delete ? Un alias ? Un export PAGER="open -a Calculator" suivi d’un git branch allowlisté ? Cette dernière séquence est le cœur de la CVE-2026-22708 : les builtins shell contournaient entièrement l’allowlist de Cursor, laissant l’injection de prompt empoisonner l’environnement de sorte qu’une commande approuvée devenait un exploit.

Les sous-agents peuvent échapper à la policy du parent. Les sous-agents ont leurs propres listes d’outils et leurs propres permissions. Si le harnais parent n’applique pas la policy de manière cohérente au passage de la frontière de spawn, un attaquant qui peut influencer la création de sous-agents peut utiliser l’enfant pour faire ce que l’agent parent n’a pas le droit de faire.

Le journal de session est un stockage local de secrets. Les journaux d’événements append-only sont l’histoire de durabilité de tous les harnais modernes. Ce sont aussi des transcriptions complètes de chaque secret qui est passé dans le contexte, posées sur le disque du développeur, généralement non chiffrées.

Pourquoi c’est important

Deux glissements méritent d’être suivis.

Le premier, c’est où les bugs atterrissent. Le post-mortem Anthropic est inhabituellement transparent sur ce point : les remontées utilisateur « Claude est devenu moins bon » n’étaient pas des régressions modèle ; c’étaient un changement de niveau d’effort par défaut, un bug d’éviction de cache qui se cumulait au fil des tours, et une instruction de verbosité dans le system prompt. Aucune de ces trois choses ne touchait l’API ni la couche d’inférence. Les trois vivaient dans le harnais. La réaction de Simon Willison vaut d’être citée : « le genre de bugs qui affectent les harnais est profondément complexe, même en mettant de côté la nature non-déterministe des modèles eux-mêmes ». Pour les builders, voilà la leçon. La classe de bugs contre laquelle il faut se prémunir inclut désormais l’état du harnais.

Le second, c’est où les attaques atterrissent. La CVE-2026-22708 est le cas d’école. Le modèle n’a rien fait de neuf ; c’est l’allowlist du harnais qui était l’ancre de confiance, et elle était contournable via des builtins shell que le parser ne classait pas. Le correctif dans Cursor 2.3 a fermé ce bypass précis, mais l’analyse de Pillar est explicite : c’est un problème de classe. Un harnais qui se protège par des allowlists plutôt que par de l’isolation d’exécution continuera de perdre face à une entrée créative tant que l’agent peut être convaincu de la taper. Les divulgations adjacentes — empoisonnement de contexte agent-vers-agent, fichiers AGENTS.md malveillants, dérive de descriptions d’outils MCP — partagent toutes la même forme.

Défenses

Traitez le harnais comme la frontière de privilège qu’il est réellement. Concrètement :

1. Inventoriez le harnais, pas seulement le modèle. Pour chaque agent de codage en production, écrivez quelles clés, fichiers, sockets et outils le harnais peut atteindre. Cet ensemble — pas les capacités nominales du modèle — c’est votre blast radius. La plupart des modèles de menace s’arrêtent à « le LLM a été trompé » ; le vôtre doit continuer avec « et le harnais a ensuite fait X ».

2. Traitez les builtins shell et l’expansion de paramètres comme sensibles. La leçon de la CVE-2026-22708 se généralise : toute allowlist qui classifie « commande externe vs builtin » fuit du privilège dès que les builtins peuvent modifier l’environnement dont ces commandes externes dépendent. Auditez votre propre classifieur de permissions pour la même classe de contournement.

3. Passez des allowlists à l’isolation d’exécution. La recommandation de Pillar, reprise par les nouvelles guidelines de Cursor après correctif, est que les allowlists sont au mieux du best-effort. La réponse robuste est l’exécution sandboxée — conteneurs, VMs, arborescences de processus restreintes — pour que « l’agent a exécuté une commande » ne signifie jamais « l’agent avait un accès ambiant au home directory du développeur ».

4. Auditez l’assemblage dynamique de system prompts. Si votre harnais parcourt les répertoires parents pour des fichiers comme CLAUDE.md, AGENTS.md, .cursor/rules ou .windsurfrules, traitez chacun de ces fichiers comme une entrée non fiable dès que l’agent opère dans un workspace sous influence de l’attaquant. Loggez ce qui est injecté. Rendez l’injection visible à l’utilisateur avant le premier tour.

5. Auditez les descriptions d’outils et les registres MCP. Les descriptions sont des surfaces d’injection de prompt. Épinglez les versions. Comparez les descriptions à chaque mise à jour. Refusez les mutations de registre silencieuses. L’hygiène supply-chain que vous appliquez à vos dépendances s’applique ici.

6. Ajoutez une étape de vérification indépendante. Les agents annoncent régulièrement un succès quand ils ont échoué — et le même mode de défaillance couvre les comportements pilotés par l’attaquant. Une étape de vérification qui lit la trace indépendamment de l’agent (et qui est elle-même hors du contrôle de l’agent) est la défense la moins chère contre la divergence entre « l’agent dit avoir fait X » et « le journal d’outils du harnais dit qu’il a fait Y ».

7. Traitez le journal de session comme un secret. Chiffrez au repos. Rédigez les motifs de secret connus à l’écriture. Définissez une politique de rétention. Tout ce qui vit dans ~/.claude, ~/.cursor, ~/.codex ou l’équivalent sur un poste partagé doit figurer dans votre liste de fichiers sensibles.

8. Recalibrez la réponse aux incidents. Quand quelque chose dérape avec un agent de codage, la première question est désormais « quelle version du harnais, avec quels hooks, contre quel workspace » — pas « quel modèle ». Construisez les champs correspondants dans votre schéma d’incident.

Statut

Élément	Référence	Date	Notes
« Your Agent Harness Has More Privilege Than Your Agent »	Pillar Security (Dor Sarig)	2026-05-26	Article conceptuel — le harnais est la frontière de privilège
« The Agent Security Paradox » / CVE-2026-22708	Pillar Security (Dan Lisichkin)	2026-01-14	Contournement d’allowlist Cursor via builtins shell
Advisory Cursor GHSA-82wg-qcm4-fp2w	GitHub	2026-01-14	Corrigé en Cursor 2.3 ; versions affectées ≤ 2.2
CVE-2026-22708 (NVD)	NIST	2026-01-14	Sévérité High ; CWE-15 / CWE-20 / CWE-74 / CWE-77 / CWE-78 / CWE-94 / CWE-269
Post-mortem Claude Code	Anthropic Engineering	2026-04-23	Trois bugs de la couche harnais identifiés ; tous corrigés au 20 avril (v2.1.116)
Commentaire de Simon Willison	simonwillison.net	2026-04-24	Lecture indépendante du post-mortem

À retenir : aucun harnais en particulier n’est cassé. C’est le harnais — Claude Code, Cursor, Codex, Aider, Cline et les autres — qui est devenu silencieusement le composant le plus privilégié de la pile d’agents, et le travail de sécurité doit suivre. Les questions intéressantes ne sont plus « le modèle est-il sûr ? » ou « les prompts sont-ils sûrs ? ». Ce sont : à quoi le harnais a-t-il accès, qui le contrôle, et comment savez-vous ce qu’il a réellement fait ?