Un agent qui fait un travail utile détient un identifiant. La clé d’API, le rôle de base de données, la permission cloud, le périmètre de paiement. C’est ce qui le rend utile. C’est aussi tout le problème.
Un agent lit du texte et agit dessus. C’est le principe, pas un défaut propre au modèle d’un fournisseur en particulier. Donc quiconque peut placer du texte devant votre agent agit avec l’identifiant de votre agent. Un ticket de support. Un PDF de facture. Une page qu’il consulte. Le README d’une dépendance qu’il résume. L’attaquant n’a jamais besoin de votre clé. Il a besoin que votre agent lise une phrase.
La vitesse supprime la seconde ligne de défense. Une personne trompée prend une seule mauvaise décision et s’en aperçoit le plus souvent. Un agent trompé prend la même décision plusieurs centaines de fois avant que quiconque n’ouvre un tableau de bord.
Les filtres sont partiels par construction
Le premier réflexe est de filtrer l’entrée : analyser le ticket, noter le prompt, classer le document, refuser ceux qui paraissent suspects.
Les filtres aident. Ils ne referment pas la faille, et la raison est structurelle plutôt qu’une affaire de réglage. Un filtre est un classifieur sur du texte libre, et c’est l’attaquant qui écrit le texte. Tout classifieur a un taux de faux négatifs. L’attaquant est libre de chercher jusqu’à en trouver un, et vous l’apprenez après coup, si tant est que vous l’appreniez.
Ce compromis convient là où se tromper coûte peu. Ce n’est pas une base pour laisser un logiciel déplacer de l’argent, supprimer des sauvegardes ou modifier une règle de production.
Partez donc du principe que l’injection réussit. Partez du principe que le modèle est manipulé le jour où cela compte. La question utile est alors différente : que l’agent est-il réellement capable de faire une fois manipulé ?
L’autorisation, pas la persuasion
Commencez par ne pas donner d’autorité à l’agent.
Sortez l’identifiant de l’agent. L’agent détient une seule clé, qui permet de demander, pas d’agir. Chaque action part sous forme de proposition signée : cette action, ces arguments, ces ressources. Une proposition est une demande. En détenir une n’accorde rien.
La proposition rencontre une politique que vous avez signée. La politique l’évalue sur ce qu’elle touche, ce qu’elle coûte et sa réversibilité. Les actions courantes sont accordées en quelques millisecondes, de sorte que l’agent n’a jamais à patienter pour une action qui allait de toute façon passer. Les actions dangereuses sont mises en attente. Une action sans règle est refusée, jamais devinée. L’inconnu n’est jamais un risque faible.
Une action mise en attente a besoin de personnes, et elle en a besoin d’une manière précise. Les approbateurs signent les octets exacts qui s’exécuteront, pas leur résumé. La règle est un quorum : mise en attente, quorum 2-of-2 requis. Un approbateur signe et l’autre refuse : le quorum n’est pas atteint et rien ne s’est exécuté. Le silence ne vaut pas consentement. Celui qui a proposé l’action ne peut pas l’approuver.
Vient ensuite l’exécution. Seules les propositions accordées s’exécutent, et elles s’exécutent sous l’identité de ZIFFER, pas sous celle de l’agent. Vos systèmes n’acceptent l’action que depuis cette identité, et depuis aucune autre. Un agent entièrement détourné qui tente d’agir en direct se heurte à un mur, pas à une alerte.
Ce qu’une décision doit laisser derrière elle
Chaque issue écrit un reçu : ce qui a été proposé, comment cela a été évalué, qui a signé, ce qui s’est exécuté. Les reçus sont signés, ajoutés à un registre et ancrés à l’extérieur du système qui les a produits, avant la libération d’une action irréversible. Personne ne réécrit cet historique ensuite, nous compris.
C’est ce qui transforme une politique en preuve. Un journal dit ce qui s’est passé selon un service. Un reçu permet à quelqu’un d’autre de le vérifier, sans accès à la production et sans vous croire sur parole.
La forme de la solution
L’injection de prompt n’attend pas un meilleur prompt, et ce n’est pas un problème de qualité de modèle qui se règle sur la feuille de route de quelqu’un d’autre. C’est ce qui arrive quand on confie des identifiants à quelque chose qui prend ses instructions auprès d’inconnus.
Alors ne lui confiez pas d’identifiants. Laissez-le proposer. Laissez votre politique accorder. Gardez vos équipes sur les actions qui les méritent, et gardez un reçu de tout ce qui s’est exécuté.
L’agent reste exactement aussi capable que vous l’avez construit. Il cesse d’être ce qui décide.
ZIFFER est bâti sur une spécification ouverte, et chaque affirmation qu’elle contient doit pouvoir se rejouer sur votre propre machine. La documentation est le point de départ.