Ключи провайдера — вне агента: один шлюз и один токен на задачу

🔑 Проблема общего ключа

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

Наше собственное измерение в сентябре 2026 показало, что именно это ещё происходило в одном мостовом раннере, который подключал файл окружения напрямую. Эта находка и есть причина дизайна ниже.

🏗️ Дизайн

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

Токен выдаётся на одну задачу. Он привязан к отпечатку пакета задачи, поэтому его нельзя использовать для другой работы. Он несёт бюджет и потолок на вызов, срок действия, и закрывается, когда задача кончается. Сервис хранит только хэш токена, а не сам токен. Каждый вызов — строка в леджере с идентификатором задачи, так что у расхода есть владелец.

Сервис также ведёт свои книги отдельно от других денежных путей. Он не импортирует торговый код, и тест это проверяет.

📊 В цифрах

С 21 сентября 2026 сервис выдал 1 415 токенов задач. 1 367 закрыты, а 48 не отмечены закрытыми: часть в полёте или брошена и ждёт истечения срока. Резервирований бюджета — 4. В файле тестов границ модулей 17 тестов.

🛠️ Практика: уберите ключ из агента

1. Найдите все места, где читается ключ провайдера: файлы окружения, конфиги, скрипты. Составьте список.
2. Создайте небольшой сервис, который держит ключи и предлагает тот же интерфейс вызова, к которому привыкли ваши агенты.
3. Выдавайте токен на задачу. Привяжите его к хэшу описания или пакета задачи, бюджету, максимуму на вызов и сроку.
4. Храните только хэш токена. Показывайте токен один раз вызывающему.
5. Логируйте каждый вызов с идентификатором задачи, моделью, токенами и стоимостью, включая повторы и переключения.
6. Добавьте тест, который просматривает ваш код и падает, если любой другой модуль читает переменную ключа.
7. Уберите ключ из окружения каждого агента и из каждого профиля shell, который агенты наследуют.

✅ Проверьте себя

• Выведите окружение процесса агента. Ключа провайдера в нём нет.
• Используйте токен задачи после её закрытия. Вызов отклоняется.
• Используйте токен с другим пакетом. Он отклоняется.
• Для любого вызова из леджера прошлой недели вы можете назвать задачу и её бюджет.

🚧 Когда это не работает

• Шлюз становится единственной точкой отказа. Если он лежит, не работает ни один вызов модели. Запускайте его как управляемый сервис с политикой перезапуска.
• Ключи в других местах. Если в профиле shell разработчика ключ всё ещё экспортируется, агент его унаследует. Проверяйте и оболочки.
• Долгоживущие токены. Токен на неделю — это ключ с лишними шагами. Привязывайте его к задаче.
• Сбой одного провайдера. Шлюз его не убирает. Решите политику запасного варианта и логируйте переключения.
• Локальные модели. У модели на вашем железе ключа нет. Леджер всё равно нужен.

📊 Доказательства

➡️ Дальше

Как резервируется бюджет до запуска задачи, читайте в Расходах, бюджетах и лимитах, а что проверять в подключении — в Чек-листе безопасности MCP-сервера.

Источники

• Расходы, бюджеты и лимиты: резервирование расхода.
• Чек-лист безопасности MCP-сервера: проверки перед подключением данных.
• Права и потоки данных: что агент может затрагивать.
• Квитанции задач агента: что они доказывают: доказательства по запуску.