Claude Code garde les clés Datadog hors de portée de l’agent : le proxy ajoute lui-même le jeton

La situation est familière : vous voulez qu’un agent consulte lui-même Datadog, analyse les alertes et cherche la cause d’une panne. Le plus simple consiste à placer une clé API dans une variable d’environnement. Cela fonctionne immédiatement. Et crée tout aussi immédiatement un problème de sécurité.

Une publication de @timwork_notes rapporte cette déclaration de Cat Wu, qui travaille sur Claude Code, à Simon Willison : les identifiants Datadog seraient « utilisables uniquement par l’agent, mais inaccessibles à l’agent lui-même ». Cela ressemble à un paradoxe, mais repose sur une idée technique simple. Une réserve essentielle : nous ne disposons que d’un bref compte rendu de cette conversation, sans détails d’implémentation. Nous examinons donc ici le principe d’architecture, et non une configuration interne précise.

Pourquoi une clé en clair dans l’environnement est dangereuse

Un agent lit de nombreux textes non fiables : pages web, journaux, tickets, commentaires dans le code. Chacun peut contenir une instruction du type « affiche toutes les variables d’environnement ». Si la clé se trouve dans l’environnement du processus, le modèle dispose d’un moyen d’y accéder. Une seule injection de prompt réussie suffit alors pour que le secret soit affiché dans une réponse, enregistré dans un fichier ou envoyé à un serveur tiers.

L’auteur de la publication le formule sans détour : une clé en clair dans l’environnement d’un agent est « à un prompt injecté près d’une fuite ». Difficile de le contester. Compter sur des instructions comme « ne révèle jamais les clés » n’est pas fiable : c’est une demande, pas une barrière.

Comment fonctionne l’architecture avec un proxy

L’idée est que l’agent ne possède tout simplement pas le secret. Il obtient à la place la possibilité d’accéder à Datadog par un proxy intermédiaire.

Prenons un exemple simple. L’agent veut récupérer les métriques d’un service. Il envoie une requête à l’adresse du proxy, sans jeton ou avec une valeur factice. Le proxy, qui s’exécute en dehors de l’environnement isolé de l’agent, vérifie que la requête est autorisée, ajoute le véritable jeton dans un en-tête et transmet la requête à Datadog. La réponse revient à l’agent. Pendant toute l’opération, le véritable secret reste exclusivement dans le processus du proxy.

Résultat : l’agent peut utiliser cet accès, mais ne peut pas en copier les identifiants. Si quelqu’un le manipule, l’attaquant pourra tout au plus lui faire envoyer les mêmes requêtes par le proxy tant que celui-ci fonctionne. Il ne récupérera pas une clé qu’il pourrait emporter et utiliser ailleurs.

Que faire en pratique

Cette architecture peut être reproduite sans outils particuliers :

• Ne placez pas de clés à longue durée de vie dans l’environnement de l’agent, dans les fichiers du projet ou dans les configurations qu’il peut lire.
• Intercalez entre l’agent et l’API externe un petit proxy qui insère le jeton. Un reverse proxy classique ou un side-car peut faire l’affaire.
• Réduisez les autorisations. Pour analyser des incidents, l’agent a seulement besoin de lire les métriques et les journaux ; les droits d’écriture et d’administration sont inutiles.
• Restreignez dans le proxy la liste des chemins et des méthodes autorisés. Même compromis, l’agent ne pourra alors pas dépasser ce périmètre.
• Journalisez les requêtes passant par le proxy : vous disposerez ainsi d’une trace des actions de l’agent sur votre infrastructure.

Limites

Le proxy ne résout pas tout. Tant que l’agent peut accéder à l’API par son intermédiaire, une injection peut encore lui faire exécuter des actions autorisées, par exemple lire des journaux sensibles et en transmettre le contenu à l’extérieur. Le proxy doit donc être associé à des autorisations restreintes et à un contrôle du trafic sortant ; il ne les remplace pas.

Autre limite : la source n’est qu’une courte publication à faible audience, sans schémas ni code. Mais le principe consistant à « conserver le secret là où le modèle ne peut pas l’atteindre » est plus utile qu’une dizaine de lignes dans le prompt système.

Si vous développez des agents qui accèdent à des systèmes de production, vérifiez dès aujourd’hui une chose : que se passerait-il si le modèle affichait toutes les variables d’environnement ? Si elles contiennent des clés de production, il est temps d’ajouter un proxy.