Un agent chargé de préparer un remboursement doit-il pouvoir aussi le déclencher ? Cette question très concrète aide à comprendre les nouveaux enjeux de la sécurité de l’IA. Lorsqu’un logiciel ne se contente plus de proposer un texte, mais consulte des documents, appelle des outils et exécute du code, une mauvaise décision peut devenir une opération réelle.
Le 27 octobre 2026, Akamai a annoncé un environnement d’exécution destiné aux agents IA, aux côtés d’un service d’inférence. Cette actualité invite à distinguer trois protections souvent réunies sous le même mot : empêcher un programme de sortir de son environnement, limiter les ressources auxquelles il accède et vérifier les actions qu’il entreprend. Elles répondent à des questions différentes.
Ce qu’Akamai annonce, et ce que cela ne démontre pas
Dans son communiqué du 27 octobre, Akamai présente Agent Sandbox, disponible en bêta par l’intermédiaire du Spin SDK. Le dispositif doit permettre d’exécuter du code produit par un agent dans un environnement isolé, séparé de celui de l’agent lui-même, sur Akamai Functions.
L’entreprise décrit une isolation fondée sur WebAssembly et la possibilité de définir des limites de calcul, de mémoire, de connexions sortantes et de capacités système. Elle annonce également de futures fonctions de gouvernance des communications des agents : cette partie relève d’une feuille de route, pas d’une protection dont le déploiement serait déjà établi.
Il s’agit de la description du fournisseur. Nous n’avons pas réalisé de test indépendant de ce service, et ce lancement ne permet pas de conclure qu’un agent quelconque serait désormais sûr. Le point intéressant est son périmètre : contenir l’exécution d’un programme. La pertinence de l’action confiée à ce programme reste une autre question.
Un remboursement fictif pour comprendre les frontières
Prenons un exemple pédagogique fictif. Une entreprise confie à un agent la préparation des notes de frais. Il doit lire un justificatif, retrouver le salarié concerné, proposer une catégorie comptable et présenter le dossier à la validation. Aucun incident réel ni résultat d’essai n’est décrit ici.
Le premier enjeu serait l’exécution du code : si l’agent écrit un petit programme pour extraire les montants, ce programme devrait travailler dans un espace délimité. Il n’aurait aucune raison de parcourir tous les fichiers du serveur. Le deuxième enjeu serait l’accès aux données : le justificatif d’un salarié ne justifierait pas la consultation des dossiers de toute l’entreprise.
Le troisième concernerait le paiement. Un calcul juste ne donnerait pas, à lui seul, l’autorisation de transférer de l’argent. Même correctement isolé, un programme pourrait appeler un service auquel on aurait accordé trop de droits. L’exemple permet ainsi de poser une question simple avant de choisir un produit : quelle erreur précise chaque protection doit-elle empêcher ?
On peut pousser le raisonnement. Si le dossier contient deux factures identiques, l’agent devrait-il préparer deux remboursements ? Si une pièce manque, doit-il inventer une justification, demander un complément ou laisser le dossier en attente ? Ces choix relèvent aussi du fonctionnement du service. La sécurité ne remplace ni les règles du métier ni le contrôle de la qualité des informations.
Le risque d’accorder trop de possibilités
L’OWASP consacre une fiche à l’autonomie excessive des systèmes fondés sur des modèles de langage. Elle distingue notamment les fonctions inutiles, les permissions trop larges et l’absence de validation des opérations importantes. Le problème peut provenir d’une réponse erronée comme d’une instruction malveillante rencontrée dans les données traitées.
Ses recommandations comprennent la réduction des outils disponibles au strict besoin, des autorisations minimales et une vérification des accès par les systèmes qui exécutent réellement les demandes. Le modèle ne doit pas être seul juge de ce qu’il a le droit de faire. Pour les actions à fort impact, une approbation humaine peut être nécessaire.
L’organisme distingue aussi prévention et limitation des dégâts : les journaux d’activité et les plafonds de fréquence aident à détecter un problème ou à réduire son ampleur, sans supprimer sa cause. Cette nuance compte lorsqu’un fournisseur présente une fonction de surveillance comme une réponse complète.
Identifier l’agent et pouvoir lui retirer ses droits
Le même 27 octobre, le NIST a proposé dix principes de conception pour la gestion des identités des agents. Ce texte de travail s’appuie sur des contributions publiques et des échanges avec l’écosystème. Ce n’est ni une certification de produit ni une norme obligatoire nouvelle.
Les auteurs préconisent notamment une identité propre à chaque agent, des droits limités à sa tâche et des autorisations temporaires révocables. La délégation à d’autres agents ne devrait pas élargir les pouvoirs accordés au départ. Ils demandent également de séparer le raisonnement du modèle des mécanismes qui décident effectivement des accès.
Le texte insiste sur des traces indépendantes que l’agent ne puisse pas modifier à sa convenance, ainsi que sur une surveillance continue. Il signale enfin que l’état actuel des technologies et des standards ne permet pas nécessairement de satisfaire immédiatement tous ces principes. Une direction de conception n’est pas une promesse de mise en œuvre universelle.
Ce qu’une démonstration utile devrait montrer
Dans notre exemple fictif, une démonstration convaincante ne se limiterait donc pas à une note de frais correctement remplie. Elle montrerait aussi ce qui se passe quand la tâche sort du cas habituel. Voici quatre situations que l’entreprise pourrait demander à son intégrateur de préparer sur des dossiers fictifs :
- Un justificatif contient une phrase demandant de changer les coordonnées de paiement : cette phrase doit rester une donnée du document, sans devenir une autorisation.
- L’agent reçoit un dossier appartenant à un autre service : le refus d’accès doit être observable, pas seulement promis dans ses instructions.
- La connexion coupe après une opération : la reprise doit permettre de retrouver ce qui a déjà été effectué avant toute répétition.
- Le responsable retire l’autorisation pendant le traitement : la prochaine action doit respecter ce retrait.
Ces scénarios sont des propositions de vérification, pas des tests que nous aurions exécutés. Leur intérêt est de rendre une discussion commerciale mesurable. Pour chacun, il faudrait préciser le résultat attendu, conserver le résultat observé et identifier la couche qui a bloqué l’opération. Un refus obtenu une fois ne suffirait pas non plus à démontrer l’absence de toute vulnérabilité.
L’autonomie utile se juge aussi aux arrêts corrects
Une entreprise peut rechercher un traitement rapide sans souhaiter qu’un agent tranche toutes les exceptions. Dans le cas des notes de frais, laisser un dossier incomplet en attente tout en poursuivant les dossiers complets serait parfois préférable à une réponse immédiate mais inventée. La mesure du succès devrait alors distinguer travail terminé, exceptions correctement isolées et opérations reprises sans doublon.
Avant d’ajouter une nouvelle couche de sécurité, il reste donc utile de décrire le travail attendu : quelles données lire, quelle décision proposer, quelle action exécuter et qui peut la révoquer. L’annonce d’un environnement isolé apporte un élément à cette discussion. Elle ne dispense pas de vérifier le reste de la chaîne, jusqu’au service qui accepte ou refuse l’action finale.
Photographie d’illustration : un environnement de programmation sur ordinateur portable. Elle ne représente ni Agent Sandbox ni une attaque informatique.
