Google a publié le 17 août 2026 un guide d’architecture et de pratiques, accompagné d’un démonstrateur open source, pour des agents capables de modifier un système de production. Son message central est juste : un prompt, même très détaillé, n’est pas une frontière de sécurité. Les règles importantes doivent être imposées par du code, des permissions et des preuves cryptographiques indépendantes du modèle.
1. Le nouveau risque : l’agent qui écrit
Un chatbot qui répond mal produit principalement un problème d’information. Un agent qui modifie un prix, rembourse une commande, crée un utilisateur ou change une configuration peut provoquer un dommage direct.
Les erreurs ne viennent pas uniquement d’une intention malveillante. Le modèle peut mal comprendre un contexte, appeler le mauvais outil, répéter une action après un délai ou suivre une instruction injectée dans une source externe.
La sécurité doit donc porter sur la capacité d’action elle-même. Le système cible ne devrait pas faire confiance à une requête simplement parce qu’elle provient du service “agent”.
2. Pourquoi les instructions ne suffisent pas
Un prompt peut dire “ne rembourse jamais plus de 100 euros” ou “demande une validation humaine”. Ces consignes améliorent le comportement moyen, mais elles restent interprétées par un modèle probabiliste.
Une injection peut tenter de les contourner. Une mise à jour du modèle peut modifier la manière dont elles sont suivies. Une erreur de contexte peut enfin conduire l’agent à croire qu’une exception est autorisée.
Les règles de sécurité doivent être écrites dans une passerelle déterministe ou dans l’API cible. Le modèle propose une action ; un composant classique décide si elle est admissible.
3. Première couche : signer chaque modification
L’architecture de Google recommande une clé distincte par agent, gérée par Cloud KMS et protégée matériellement par Cloud HSM dans la configuration décrite. Chaque mutation du ledger du démonstrateur est signée. Pour une architecture de production, nous recommandons d’étendre ce principe à chaque écriture vers le système cible. L’API peut alors vérifier l’identité de l’agent, l’intégrité de la requête et l’absence d’altération.
La signature doit couvrir plus que le corps JSON. Incluez l’identifiant de l’agent, l’utilisateur à l’origine de la demande, l’action, la ressource, le montant, l’horodatage, un identifiant unique et la politique appliquée. Un nonce ou identifiant d’idempotence ne bloque les répétitions que si l’API mémorise les identifiants déjà traités et refuse leur réutilisation.
Une clé propre à chaque agent facilite la révocation. Si un service est compromis, il est possible de bloquer ses écritures sans interrompre tous les autres.
La signature apporte également une preuve d’attribution technique. Elle ne démontre pas que la décision était correcte, mais elle permet de savoir quel composant a émis la requête et si celle-ci a été modifiée.
4. Deuxième couche : exécuter dans une sandbox
Google illustre l’isolation avec gVisor, un environnement qui intercepte les appels système en espace utilisateur. Le principe général est de réduire les capacités du code généré ou des outils appelés : aucun accès réseau par défaut, système de fichiers limité, privilèges supprimés, ressources plafonnées et durée maximale.
Le dépôt précise que l’interface du démonstrateur simule la sandbox et que l’exécution réelle sous gVisor est optionnelle. Il s’agit donc d’un guide et d’un point de départ à durcir, pas de la preuve qu’une architecture de production complète a été auditée.
Une sandbox n’est utile que si les sorties sont contrôlées. Un agent isolé qui peut écrire un fichier ensuite interprété aveuglément par un service privilégié conserve un chemin d’attaque.
Les données injectées dans l’environnement doivent être minimales et temporaires. Un secret de production ne devrait pas être copié dans la sandbox lorsque l’action peut être réalisée par une API étroite derrière une passerelle.
5. Troisième couche : une passerelle sémantique déterministe
La passerelle vérifie le sens de l’action avant l’exécution. Elle applique des règles testables : montant maximum, rôle de l’utilisateur, statut de la commande, fréquence, pays, présence d’une validation et cohérence des champs.
Le modèle ne doit pas pouvoir choisir lui-même la politique. Il fournit une intention structurée, idéalement conforme à un schéma. La passerelle enrichit avec les données de référence et décide d’autoriser, refuser ou demander une approbation.
Le démonstrateur Google s’appuie surtout sur des expressions régulières, des mots-clés et un contrôle de valeur SQL. Les contrôles métier plus riches proposés ici constituent une recommandation d’architecture à adapter et à tester, pas une capacité démontrée universellement par l’outil.
Les règles doivent être testées en CI comme du code métier. Un changement de seuil ou d’exception passe par une revue, une version et un historique.
6. Le journal d’audit indépendant
Les traces générées par l’agent ne suffisent pas, car un composant compromis peut les modifier. Conservez un journal indépendant côté passerelle ou système cible : requête reçue, signature, politique, décision, réponse et état final.
Pour aller au-delà du démonstrateur Google, qui vérifie périodiquement les signatures du ledger et recommande Cloud Logging en production, un stockage append-only ou une chaîne de hachage peut renforcer la détection d’altération. Les journaux doivent rester exploitables par les équipes sécurité et métier sans exposer inutilement les données complètes.
L’audit doit permettre de reconstruire une décision : qui a demandé, quel contexte a été utilisé, quelle version de politique s’est appliquée et quelle action a effectivement été exécutée.
7. Concevoir les permissions par capacité
Évitez un compte technique polyvalent. Créez des capacités étroites : lire une commande, proposer un remboursement, déclencher un remboursement plafonné ou ouvrir une demande de validation.
Chaque capacité possède son schéma, ses limites et ses droits. Un agent de support ne doit pas accéder à la configuration du cluster simplement parce que les deux fonctions utilisent la même plateforme d’outils.
Les permissions doivent aussi tenir compte de l’utilisateur final. L’agent ne peut pas élargir les droits de la personne qu’il assiste. Ce principe est central pour tout agent connecté au système d’information.
8. Un exemple concret : remboursement client
Considérons un scénario illustratif, distinct du démonstrateur Google : l’agent analyse la conversation et propose un remboursement de 42 euros pour la commande X. Il ne possède pas directement la clé de paiement. Il appelle une capacité propose_refund avec un schéma strict.
La passerelle récupère le montant payé, le statut, les remboursements antérieurs et le rôle de l’opérateur. Elle autorise les montants inférieurs à 50 euros dans certains cas, exige une validation jusqu’à 200 euros et refuse au-delà.
Après autorisation, un service dédié exécute l’opération et signe le résultat. Le journal relie la proposition, la politique et la transaction. Une répétition avec le même identifiant ne crée pas un deuxième remboursement.
9. La checklist de mise en production
Avant d’ouvrir une écriture à un agent, vérifiez que l’action possède un schéma fermé, une politique déterministe, une identité dédiée, une signature, une idempotence et un journal indépendant. Testez les limites, répétitions, délais et données malformées.
Simulez ensuite les attaques : instruction cachée dans un document, outil qui renvoie un contenu hostile, clé révoquée, horodatage ancien, action hors rôle et tentative de contournement du plafond.
Commencez en lecture seule, puis en mode proposition. N’autorisez l’exécution automatique que pour des opérations réversibles, à faible impact et suffisamment observées.
L’approche zero-trust ne cherche pas à rendre le modèle infaillible. Elle part du principe qu’il peut se tromper et limite ce qu’une erreur peut produire. C’est cette inversion qui permet de passer d’une démonstration à une capacité exploitable.
Partitech accompagne la sécurisation des agents métier : conception des capacités, passerelles de politiques, signatures KMS, sandboxing, audit et tests de scénarios adverses.