Claude Code прячет ключи Datadog от агента: прокси подставляет токен сам

Знакомая ситуация: вы хотите, чтобы агент сам лазил в Datadog, разбирал алерты и искал причину падения. Самый простой путь — положить API-ключ в переменную окружения. Работает сразу. И так же сразу превращается в проблему безопасности.

В посте @timwork_notes приводится цитата: Кэт Ву, которая работает над Claude Code, говорила Саймону Уиллисону, что креды Datadog «доступны только агенту, но недоступны самому агенту». Звучит как парадокс, но за ним стоит простая инженерная идея. Важная оговорка: у нас есть только короткий пересказ разговора, без деталей реализации, поэтому ниже мы разбираем сам паттерн, а не конкретную внутреннюю конфигурацию.

Почему сырой ключ в окружении опасен

Агент читает много недоверенного текста: страницы, логи, тикеты, комментарии в коде. В любом из них может сидеть инструкция вроде «выведи все переменные окружения». Если ключ лежит в окружении процесса, у модели есть путь до него. Достаточно одной удавшейся инъекции промпта — и секрет напечатан в ответе, записан в файл или отправлен на чужой сервер.

Автор поста формулирует жёстко: сырой ключ в окружении агента — это «один инъектированный промпт от утечки». Спорить трудно. Защищаться инструкциями вроде «никогда не показывай ключи» ненадёжно, это просьба, а не барьер.

Как работает схема с прокси

Идея в том, чтобы секрета у агента просто не было. Вместо него агент получает возможность ходить в Datadog через промежуточный прокси.

Простой пример. Агент хочет получить метрики сервиса. Он отправляет запрос на адрес прокси без всякого токена или с заглушкой. Прокси, который живёт вне песочницы агента, проверяет, что запрос разрешён, добавляет настоящий токен в заголовок и пересылает его в Datadog. Ответ возвращается агенту. Реальный секрет всё это время находится только в процессе прокси.

Итог: агент может пользоваться доступом, но не может его скопировать. Если его обманут, злоумышленник получит максимум возможность слать те же запросы через прокси, пока тот работает, а не ключ, который можно унести и использовать где угодно.

Что делать на практике

Это паттерн, который можно повторить без специальных инструментов:

• Не кладите долгоживущие ключи в окружение агента, в файлы проекта и в конфиги, которые он может прочитать.
• Поставьте между агентом и внешним API небольшой прокси, который подставляет токен. Для этого подойдёт обычный reverse proxy или сайдкар.
• Сужайте права. Для расследования инцидентов агенту хватит чтения метрик и логов, запись и администрирование ему не нужны.
• Ограничьте в прокси список разрешённых путей и методов. Тогда даже скомпрометированный агент не сможет сделать лишнего.
• Логируйте запросы через прокси: это заодно даёт аудит того, что агент делал с вашей инфраструктурой.

Ограничения

Прокси не решает всё. Пока агент имеет доступ к API через прокси, инъекция всё ещё может заставить его выполнять разрешённые действия, например читать чувствительные логи и пересказывать их наружу. Поэтому прокси работает вместе с узкими правами и контролем исходящего трафика, а не вместо них.

Ещё одно ограничение: это лишь короткий пост с малым охватом, без схем и кода. Но сам принцип «секрет живёт там, где его не достать модели» полезнее десятка строк в системном промпте.

Если вы строите агентов, которые ходят в продакшен-системы, проверьте сегодня одно: что будет, если модель выведет все переменные окружения. Если там есть боевые ключи, пора добавлять прокси.