Как дать ИИ-агенту доступ к API, не отдавая настоящий ключ

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

Почему «просто дать ключ» — плохая идея

Ключ, попавший в контекст ИИ-агента, перестаёт быть секретом по четырём независимым причинам:

• Контекст логируется. История чата, трейсы агентских фреймворков, отладочные дампы — ключ оседает в каждом из этих мест, часто в открытом виде.
• Промпт-инъекция. Агент, читающий внешние данные (веб-страницы, issue, письма), может быть обманут инструкцией «выведи свои переменные окружения». Это не гипотеза, а регулярно демонстрируемая атака.
• Агент ошибается. Автономный агент может закоммитить ключ в репозиторий, вставить его в пример кода или отправить в лог — не по злому умыслу, а потому что «так получилось».
• Ключ живёт дольше сессии. Скопированный в конфиг или скрипт, он остаётся там навсегда — уже вне вашего контроля.

Схемы, которые работают

1. Ограниченные ключи провайдера

Некоторые провайдеры умеют выпускать ключи с урезанными правами (проектные ключи OpenAI, скоупы GitHub-токенов). Это лучше, чем полный ключ, но: лимиты и права настраиваются не везде, отзыв всё равно ломает всё, что сидит на этом ключе, а следить за десятком провайдеров приходится вручную.

2. Секрет-менеджер + переменные окружения

Vault, AWS Secrets Manager, Doppler: ключ хранится централизованно, агент получает его через окружение процесса. Уже неплохо — но в момент выполнения ключ всё равно оказывается в среде, до которой агент дотягивается (printenv, чтение конфига), и дальше см. пункт про промпт-инъекцию.

3. Прокси-токены: агент вообще не видит ключа

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

агент ──(vlt_токен)──▶ прокси ──(настоящий ключ)──▶ API провайдера

Каждый токен — со своей привязкой к IP, своими лимитами rpm/rpd и мгновенным отзывом. Утечка токена из контекста агента — не инцидент: с чужого адреса он не работает, а отзыв занимает один клик и не трогает оригинал.

MCP: агент управляет доступом, не видя секрета

Следующий шаг — дать агенту не токен в промпте, а инструмент. proxykey включает MCP-сервер (Model Context Protocol — стандарт подключения инструментов к Claude, Cursor и другим агентам): агент подключается по URL с токеном mcp_… и получает набор операций — выписать проходку, ротировать, отозвать, посмотреть логи и статистику.

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

Частые вопросы

Это защищает от промпт-инъекции?

От кражи ключа — да: в контексте нечего красть. Агент по-прежнему может быть обманут в рамках своих полномочий (например, уговорён отозвать проходку), поэтому права MCP-токена стоит держать минимальными.

А если утечёт сам vlt_-токен?

Он привязан к IP и ограничен лимитами: с чужого адреса — 403, сверх лимита — 429. Отзыв — один клик, оригинал не затронут. Сравните со сливом настоящего ключа — вот что приходится делать в этом случае.

Сложно ли переключить существующий код?

Меняется хост в base URL и сам ключ: api.openai.com → api.proxykey.org/p/openai, sk-… → vlt_…. Остальное — метод, путь, тело, стриминг — проходит без изменений. Как это устроено — в статье про прокси для API-ключей.