Moindre privilège pour les agents qui paient

ANS DE LOGIQUE DE TRANSFERT

code de permission on-chain

AUTEURS NOMMÉS D'ERC-3643

je suis l'un des cinq

L'injection de prompt ne sera pas résolue

L'injection de prompt ne sera pas résolue, alors cessez de concevoir comme si elle allait l'être. Le geste qui tient vraiment, c'est le confinement : supposez que l'agent peut être retourné contre vous, et faites en sorte que le pire qu'il puisse faire reste petit. Pour des agents qui déplacent de l'argent, cela veut dire le moindre privilège, imposé par la ressource, pas demandé à l'agent.

Je ne suis pas arrivé à cette conclusion par le versant sécurité de l'IA. J'y suis arrivé par dix ans passés à écrire de la logique d'éligibilité au transfert dans des smart contracts, et par la co-écriture d'ERC-3643, un standard de token dont le seul rôle est de refuser un transfert que l'appelant n'a pas le droit de faire. Le modèle de confinement que le champ de la sécurité des agents réinvente aujourd'hui est celui que ce standard applique en production depuis des années.

Imposer la permission au bord, pas chez l'appelant

Voici l'analogie qui reformule tout le problème pour moi. Dans un token naïf, la conformité est une vérification que le code appelant est censé lancer avant de transférer. Un front-end de confiance l'appelle, le transfert passe, tout le monde est content. Puis une intégration oublie la vérification, ou un attaquant appelle directement la fonction de transfert, et un détenteur inéligible se retrouve sur la table de capitalisation. La vérification existait. Rien ne l'a forcée à s'exécuter.

ERC-3643 fait un autre pari. La fonction de transfert du token demande elle-même à un registre d'identité on-chain si le destinataire est éligible, et annule sinon. Il n'y a aucun contournement, car la vérification vit dans la fonction que tout le monde doit appeler. Vous ne pouvez pas l'oublier, et vous ne pouvez pas passer à côté.

Un agent victime d'injection de prompt est exactement l'appelant non fiable de cette histoire. Si votre sécurité dépend du fait que l'agent choisit de lancer la vérification, l'injection lui retire ce choix. Vous déplacez donc la vérification au bord : le compte, le rail de paiement, la ressource elle-même refuse une action que l'agent n'est pas autorisé à faire, quoi qu'on ait convaincu l'agent de demander.

CHEMIN D'APPLICATION

La vérification n'est pas quelque chose que l'appelant lance, c'est quelque chose qu'il ne peut pas éviter. Remplacez le token par un rail de paiement et l'appelant par votre agent : la même forme confine un agent injecté.

Faire confiance à l'appelant

La vérification de permission est quelque chose que l'agent est censé lancer avant d'agir. Un agent détourné, tout simplement, ne la lance pas, ou s'en sort par la parole. La barrière ne vaut que l'honnêteté de l'appelant, et l'appelant est justement ce dont vous venez de perdre le contrôle.

Imposer au bord

La ressource refuse l'action elle-même. Dans ERC-3643, le transfert annule quand le destinataire n'est pas éligible, peu importe qui l'a demandé. Pour un agent, le rail de paiement refuse un transfert hors du périmètre de l'agent, peu importe ce que disait le prompt. La vérification ne dépend pas du bon comportement de l'appelant.

Pour le mécanisme on-chain dont ceci s'inspire, ERC-3643 impose la permission au moment du transfert, à l'intérieur du token lui-même.

Les quatre schémas de confinement qui tiennent

Le moindre privilège pour un agent qui paie n'est pas un seul contrôle. Ce sont quatre, et ils ne fonctionnent qu'ensemble. Chacun suppose que la couche au-dessus a échoué.

DÉFENSE EN PROFONDEUR

Quatre couches, chacune supposant que celle du dessus est déjà tombée. Le moindre privilège plafonne ce que détient un agent détourné, les identifiants éphémères expirent un jeton volé, la validation humaine verrouille chaque mouvement de valeur, et la piste d'audit prouve ce qui s'est passé quand les trois premières n'ont pas suffi.

Schéma

Ce qu'il confine

Ce qu'il vous coûte

Périmètre de capacités

Un agent détourné ne peut atteindre que ce que sa tâche a reçu. On ne lui a jamais confié les clés du reste.

Vous définissez des périmètres par tâche au lieu d'un identifiant permanent.

Identifiants éphémères

Un jeton volé est expiré au moment où il est exfiltré. Les identifiants sont émis par tâche et meurent en quelques minutes.

De l'émission à courte durée et de la rotation, au lieu d'un secret durable dans une variable d'environnement.

Validation humaine de la valeur

L'injection peut proposer un paiement. Elle ne peut pas l'exécuter. Une personne signe l'étape irréversible.

De la latence, et un humain dans la boucle pour tout ce qui déplace de l'argent.

Piste d'audit immuable

Vous pouvez prouver après coup ce qui a bougé, qui l'a approuvé et pourquoi, même face à un agent qui ment à ce sujet.

Du stockage en écriture unique et la discipline de journaliser l'intention, pas seulement le résultat.

Ce qu'un agent qui paie ne doit jamais faire seul

La ligne la plus importante à tracer, c'est quelles actions un agent n'a jamais le droit de mener seul jusqu'au bout. Non parce que l'agent est bête, mais parce que ces actions sont irréversibles ou confèrent du pouvoir, et ce sont exactement celles que l'injection vise.

On-chain, je l'ai appris sans détour : un transfert est définitif. Aucun ticket de support ne le renvoie. La question de conception n'est donc jamais « l'agent peut-il faire ceci », c'est « que se passe-t-il le jour où l'agent a tort, et quelqu'un peut-il le défaire ». Si la réponse est non, un humain signe.

LA LIGNE

Trois branches sur quatre finissent chez un humain. Non parce que ces actions sont difficiles, mais parce que personne ne peut les défaire. L'agent les propose toutes, avec le contexte complet et une recommandation.

FLUX D'APPROBATION

L'injection atteint la première étape et s'arrête. Chaque étape qui déplace de la valeur au-delà de « proposer » exige une signature humaine que l'agent ne détient jamais : un agent détourné peut déposer un paiement, jamais le régler.

C'est aussi là que se loge la responsabilité. Quand un agent autonome paie, quelqu'un doit répondre de la signature, et c'est un problème difficile à part entière.

Pourquoi la piste d'audit doit être immuable

Quand on entend « piste d'audit », on imagine un fichier de logs. En finance régulée, c'est plus proche d'une preuve. Si un agent a déplacé de l'argent, vous devez pouvoir montrer, plus tard, exactement ce qu'il a fait, sur quelle approbation et pourquoi, à un auditeur qui présume la mauvaise foi. Un journal que l'agent pourrait éditer discrètement ne vaut rien dans cette pièce.

La piste d'audit doit donc être en ajout seul et infalsifiable. Voici la forme que j'utilise : chaque action devient un enregistrement, et chaque enregistrement porte le hash du précédent.

audit-entry.ts

// One money-moving action, one append-only record.
// prevHash chains each entry to the last, so editing any
// past entry breaks every hash after it.
interface AuditEntry {
  seq: number
  actor: string        // which agent, under which task-scoped identity
  action: 'propose' | 'approve' | 'execute' | 'abstain'
  intent: string       // what it meant to do, in its own words
  target: string       // the account, contract, or rail it touched
  amount?: string      // value at risk, when money moves
  approver?: string    // the human who signed a value-moving step
  ts: string           // ISO-8601, from a trusted clock
  prevHash: string     // hash of the previous entry
  hash: string         // hash(this record + prevHash)
}

// The agent can append to the log. It cannot rewrite it.
// A value-moving action with no approver is not a bug to
// clean up later. It is an incident.

Le champ qui compte n'est pas amount, c'est prevHash. Chaînez chaque entrée à la précédente et toute édition silencieuse de l'historique casse tous les hash qui suivent, si bien que la falsification devient détectable sans avoir à faire confiance à celui qui détient le journal. L'agent a le droit d'ajouter. Il n'a pas le droit de réécrire.

PREUVE DE FALSIFICATION

Ici, la falsification n'est pas empêchée, elle est rendue bruyante. Une seule édition discrète invalide tous les enregistrements qui suivent : c'est prevHash qui porte tout le poids.

C'est le moment où le passé de développeur de smart contracts cesse d'être une analogie et devient le mécanisme réel. On-chain, en ajout seul et infalsifiable ne sont pas des fonctionnalités qu'on implémente, c'est ce qu'est un registre. ERC-3643 s'appuie exactement là-dessus : le transfert et la raison pour laquelle il a été permis sont tous deux permanents, et aucun appelant ne peut prétendre après coup que la règle était différente. Les pistes d'audit hors chaîne essaient de racheter cette propriété dans de l'infrastructure ordinaire.

Ce que j'ai réellement exploité en production

AGENTS IA, OPS INTERNES INTEGRA

un rôle passé, pas la plateforme du fonds

Rien de tout cela n'est une théorie que j'ai lue. J'ai exploité des agents en production sous exactement ces contraintes, et j'ai dépensé un effort réel à essayer de casser les miens.

Chez Ilayer, j'ai construit la plateforme d'agents du fonds régulé et je l'ai red-teamée moi-même, en fournissant délibérément aux agents des entrées conçues pour les faire agir hors de leur périmètre, car « ça marchait dans la démo » n'est pas un argument de sécurité. Chez Integra, où j'étais CTO jusqu'à la fin de ce rôle en 2026, j'ai déployé environ 46 agents IA pour les opérations internes. Ces 46 étaient les agents d'opérations internes d'Integra, un décompte délibérément distinct des agents en production de la plateforme du fonds. La précision sur ce qu'un agent a fait relève de la même discipline que la précision sur ce qu'il a le droit de faire.

BOUCLE DE RED TEAM

Red-teamer son propre agent teste le confinement, pas le modèle. Si le rail refuse un prompt hostile, l'injection à laquelle vous n'avez jamais pensé est survivable elle aussi.

Red-teamer mes propres agents relève du même réflexe que la suite d'évals qui verrouille une release : on ne livre pas sur la démo, on livre sur la preuve.

Ce que le confinement vous apporte

Cette posture vous achète une seule chose : vous pouvez placer des agents à côté de l'argent sans jouer l'entreprise sur un problème de recherche qui resterait résolu. Vous n'avez plus besoin que l'injection de prompt soit vaincue. Vous avez besoin qu'elle soit survivable.

C'est une conversation d'achat très différente. « Notre agent ne peut pas être injecté » est une affirmation qu'aucun ingénieur honnête ne peut faire. « Un agent compromis atteint quatre permissions périmétrées, ne peut pas déplacer d'argent sans un humain, et laisse une trace infalsifiable » est une affirmation que vous pouvez réellement défendre, y compris devant un auditeur.

C'est toute la posture derrière livrer de l'IA en finance régulée : rendre l'échec survivable, puis défendre cette affirmation devant un acheteur.

CHECKLIST DE CONFINEMENT

Chaque agent tourne sur une identité périmétrée par tâche, jamais un identifiant permanent tout-puissant.
Les identifiants sont à courte durée et émis par tâche, pas stockés durablement.
Aucune valeur ne bouge, et aucune permission ne s'élargit, sans une signature humaine.
Chaque action est ajoutée à un journal infalsifiable, chaîné par hash.
Vous avez red-teamé vos propres agents avant qu'un attaquant ne le fasse.

Commencez par l'argent. Trouvez chaque chemin par lequel un agent peut déplacer de la valeur ou changer qui le peut, et placez une signature humaine devant chacun d'abord, avant de refactoriser quoi que ce soit d'autre. Cette seule étape convertit votre pire cas de « un agent injecté vide un compte » à « un agent injecté dépose une proposition qu'un humain rejette ». Le périmètre et les identifiants éphémères comptent, mais ils réduisent le rayon d'explosion. La validation humaine de la valeur est celle qui plafonne le risque absolu, elle passe donc en premier.

FAQ

Non. Chaque défense actuelle, filtrage des entrées, délimiteurs, modèles classificateurs, augmente le coût d'une attaque sans prouver que les attaques échouent. Traitez-les comme utiles, pas suffisantes. L'ingénierie qui survit à une erreur sur un filtre, c'est le confinement : supposez que l'agent peut être compromis et faites en sorte qu'un agent compromis n'atteigne presque rien.

L'agent ne détient que les permissions dont sa tâche courante a besoin, le temps que la tâche dure, et rien de plus. Un agent détourné ne peut alors pas atteindre ce qu'on ne lui a jamais accordé. En pratique, ce sont des identités périmétrées par tâche plus des identifiants éphémères par tâche, au lieu d'une seule clé durable que l'agent transporte partout.

Parce qu'ERC-3643 a déjà résolu la version structurelle de ce problème. Il impose la permission à la ressource, pas à l'appelant : la fonction de transfert du token vérifie l'éligibilité et annule, si bien qu'un appelant non fiable ne peut pas forcer un mouvement. Un agent victime d'injection de prompt est cet appelant non fiable. J'ai co-écrit le standard, c'est donc le schéma vers lequel je vais en premier.

Ça aide, et vous devriez en faire tourner un, mais ça reste un filtre, et les filtres ont un taux de faux négatifs que vous ne pouvez pas ramener à zéro. Si la seule chose entre un prompt injecté et un virement est un classificateur, un seul raté déplace de l'argent. Le confinement signifie que le raté ne peut toujours pas exécuter le paiement, parce que le paiement exigeait une signature humaine que l'injection n'a jamais eue.

Les étapes irréversibles et celles qui confèrent du pouvoir : envoyer des fonds, modifier une liste d'autorisation ou une attestation d'identité, relever une limite de dépense, accorder une capacité à un autre agent, ou éditer la configuration d'audit. L'agent peut proposer chacune avec le contexte complet. Une personne approuve celles qui déplacent réellement de la valeur ou élargissent l'accès.