Moindre privilège pour les agents qui paient

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.

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é.

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.

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.

// 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.

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

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 sont les agents d'opérations internes d'Integra. C'est un nombre différent des agents en production de la plateforme du fonds, et je garde les deux séparés à dessein, car la précision sur ce qu'un agent a réellement fait relève de la même discipline que la précision sur ce qu'il a le droit de faire.

Ce que le confinement vous apporte

Alors, qu'est-ce que cette posture vous apporte concrètement ? Elle vous permet de 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.

FAQ