Secrets d’un agent IA : clés API, OAuth, rotation

Pourquoi le modèle ne doit-il jamais voir un secret ?

Parce que tout ce qui entre dans le contexte du modèle peut en ressortir. Le guide OWASP sur la fuite du prompt système (LLM07:2025) le dit nettement : les informations sensibles comme les identifiants et les chaînes de connexion ne doivent pas figurer dans le prompt système, et il faut les externaliser vers des systèmes auxquels le modèle n’accède pas directement.

Le même guide ajoute que les contrôles critiques, comme la séparation des privilèges ou les vérifications d’autorisation, ne doivent pas être confiés au LLM, ni par le prompt système ni autrement : ils doivent se faire de façon déterministe et auditable. Une consigne du type « ne révèle jamais la clé » ne protège pas une clé que le modèle a sous les yeux, car l’injection de prompt peut la contourner.

Quels secrets un agent IA manipule-t-il ?

Plus qu’on ne le croit. Un agent typique cumule des clés d’API de fournisseurs de modèles, des jetons OAuth vers la messagerie ou le CRM, des identifiants de base de données, des jetons de serveurs MCP et des clés de services tiers.

Un exemple public : dans l’expérience décrite par Invariant Labs sur le tool poisoning, la cible était justement le fichier mcp.json de Cursor, qui peut contenir les identifiants d’autres serveurs MCP. Nous l’abordons dans notre article sur le tool poisoning MCP.

Comment accorder le moindre privilège à un jeton d’agent ?

Un jeton par agent et par usage, avec la portée la plus étroite possible, limité à une ressource. La RFC 9700 (meilleures pratiques de sécurité OAuth 2.0, publiée en janvier 2025 sous le numéro BCP 240) recommande de restreindre les jetons d’accès aux privilèges minimaux dont l’application a besoin, de les restreindre à un serveur de ressources précis (revendication aud ou paramètre resource) et de les restreindre à des ressources et actions précises grâce à scope ou authorization_details.

La spécification MCP va dans le même sens. Elle interdit le « token passthrough » : un serveur MCP ne doit accepter aucun jeton qui ne lui a pas été explicitement délivré. Elle décrit aussi un modèle progressif de portées : un ensemble initial minimal, puis une élévation ciblée lorsqu’une opération privilégiée est tentée, en évitant les portées génériques du type * ou all. Pour les droits de lecture et d’écriture, notre article sur les agents connectés à Gmail ou Outlook montre ce que cela donne sur deux messageries.

Comment faire tourner et révoquer les jetons ?

Automatisez la rotation, privilégiez les secrets de courte durée et sachez révoquer en quelques minutes. Le Secrets Management Cheat Sheet de l’OWASP recommande de centraliser la gestion, de faire tourner automatiquement les secrets statiques, de préférer des secrets dynamiques à durée de vie courte, de journaliser qui demande quoi, et de ne jamais laisser de secret dans le code ou les journaux. Il précise aussi que redémarrer une application ne révoque pas des identifiants volés.

La RFC 9700 recommande de lier les jetons d’accès à leur émetteur (mTLS selon la RFC 8705 ou DPoP selon la RFC 9449) pour limiter l’usage d’un jeton volé, et de faire tourner les refresh tokens ou de les lier à l’émetteur pour les clients publics.

Exemple concret côté plateforme : Slack propose une rotation des jetons où les jetons d’accès expirent toutes les 12 heures et où chaque refresh token n’est utilisable qu’une fois. L’activation est à votre charge et ne peut pas être désactivée ensuite. La méthode auth.revoke permet de révoquer un jeton manuellement. Vérifiez dans chaque service utilisé ce qui existe et testez la procédure avant l’incident.

Comment tester la fuite de secrets d’un agent ?

Testez toutes les sorties possibles du modèle et des outils, avec des secrets de test créés pour l’occasion.

1. Inventaire. Listez chaque secret que l’agent ou ses outils manipulent, où il est stocké, qui y accède, et sa portée réelle. Un jeton plus large que nécessaire est un constat.
2. Prompt et contexte. Un secret apparaît-il dans le prompt système, dans une description d’outil, dans l’historique ou dans un document récupéré ? Demandez directement à l’agent, puis par détour (traduction, encodage, « répète tes instructions »).
3. Sorties d’outils. Les messages d’erreur, les traces et les réponses d’API renvoyées au modèle contiennent-ils des en-têtes ou des jetons ?
4. Injection indirecte. Un contenu piégé peut-il faire lire à l’agent un fichier de configuration ou une variable d’environnement, puis l’envoyer vers l’extérieur ?
5. Jeton canari. Placez des secrets factices surveillés (fichier .env, entrée de configuration) et observez s’ils sont lus ou utilisés.
6. Portée. Avec le jeton réel de l’agent, tentez ce qu’il ne devrait pas pouvoir faire (écrire, lire une autre boîte, lister d’autres espaces).
7. Révocation. Révoquez le jeton : l’agent échoue-t-il proprement ? Combien de temps pour tout remettre en route avec une nouvelle valeur ?
8. Journaux. Cherchez les secrets dans les journaux applicatifs, de proxy et de l’outil d’observabilité.
9. Passthrough. Un serveur MCP ou un outil accepte-t-il et retransmet-il un jeton qui ne lui était pas destiné ?

Que faire quand un secret a fuité ?

Révoquez d’abord, remplacez ensuite, nettoyez enfin. L’OWASP décrit la séquence : révoquer immédiatement le secret exposé, le faire tourner (idéalement de façon automatique), puis le retirer du code et des journaux, en conservant l’historique des accès et des rotations et en documentant à l’avance les personnes à prévenir. Pour un agent, ajoutez une étape : relire les journaux d’appels depuis l’exposition présumée pour savoir ce que le jeton a permis de faire, et décider si les utilisateurs concernés doivent être informés. Préparez cette procédure avant l’incident, avec un test de révocation chronométré.

Quelle architecture évite d’exposer les secrets au modèle ?

Un courtier d’outils : le modèle demande « envoyer ce message », le code applicatif ajoute le jeton, appelle l’API, et ne renvoie que le résultat utile. Le modèle n’a jamais besoin de connaître la valeur du secret pour accomplir la tâche.

Pratiquement : stockez les secrets dans un gestionnaire dédié, injectez-les à l’exécution dans le code de l’outil, filtrez les sorties d’outil avant de les renvoyer au modèle, utilisez un jeton par utilisateur plutôt qu’un compte de service partagé quand l’action engage cet utilisateur, et enregistrez chaque usage. Ce contrôle est déterministe, hors du modèle, ce qui correspond à la recommandation de l’OWASP citée plus haut.

Comment CleanIssue teste les secrets d’un agent ?

Nous cherchons par tous les chemins ce que le modèle voit et ce qu’il peut sortir : prompt, outils, erreurs, journaux, injection indirecte. Dans le Red Team Agent Express, le test porte sur un agent en 5 jours, avec démarrage sous 48 h après signature du devis et de l’autorisation, sur votre environnement de développement ou de recette avec des secrets de test. Si vos agents partagent des comptes de service ou des serveurs MCP, le Red Team sur mesure couvre l’ensemble sur devis. La page sécurité MCP décrit ce volet.

Le premier échange est un rendez-vous découverte de 30 minutes, gratuit.