Не тримайте ключі провайдера в агенті: один шлюз, один токен на завдання

🔑 Проблема спільного ключа

Найпростіше налаштування кладе ключ провайдера у файл середовища, і його читає кожен скрипт та кожен агент. Це працює, але унеможливлює три речі. Ви не скажете, яке завдання зробило виклик, бо для провайдера всі вони виглядають однаково. Ви не можете зупинити одне завдання, не зупинивши всі. І будь-який агент, який може прочитати власне середовище, здатен злити ключ через промпт.

Наш власний замір у вересні 2026 показав, що це досі відбувалося в одному runner моста, який брав файл середовища напряму. Саме через цю знахідку з'явився дизайн нижче.

🏗️ Дизайн

Один невеликий сервіс тримає ключі провайдера. Це єдиний код у системі, який їх читає, і тест сканує код, щоб довести, що жоден інший модуль цього не робить. Агенти ніколи не бачать ключа. Вони викликають сервіс і пред'являють токен.

Токен видається під одне завдання. Він прив'язаний до відбитка пакета завдання, тому його не можна використати для іншої роботи. Він несе бюджет і стелю на один виклик, час завершення, і його закривають, коли завдання закінчується. Сервіс зберігає лише хеш токена, ніколи сам токен. Кожен виклик — це рядок у журналі з id завдання, тож у витрат є власник.

Сервіс також веде свої книги окремо від інших грошових шляхів. Він не імпортує торговий код, і це перевіряє тест.

📊 У числах

Від 2026-09-21 сервіс видав 1 415 токенів завдань. 1 367 закрито, а 48 не позначено закритими: частина з них у роботі або покинуті й чекають на завершення терміну. Є 4 резервації бюджету. Файл тестів для меж модулів містить 17 тестів.

🛠️ Практика: винесіть ключ з агента

1. Знайдіть кожне місце, де читається ключ провайдера: файли середовища, конфігураційні файли, скрипти. Складіть їх список.
2. Створіть невеликий сервіс, який тримає ключі й надає той самий інтерфейс викликів, який ваші агенти вже використовують.
3. Видавайте токен на кожне завдання. Прив'яжіть його до хешу опису завдання чи пакета, до бюджету, максимуму на один виклик і терміну дії.
4. Зберігайте лише хеш токена. Покажіть токен тому, хто викликає, один раз.
5. Логуйте кожен виклик з id завдання, моделлю, токенами й вартістю, включно з повторними спробами та резервними варіантами.
6. Додайте тест, який сканує ваш код і падає, якщо якийсь інший модуль читає змінну з ключем.
7. Приберіть ключ із середовища кожного агента і з кожного профілю оболонки, який успадковують агенти.

✅ Перевірте себе

• Виведіть середовище процесу агента. Ключа провайдера там немає.
• Використайте токен завдання після того, як завдання закрито. Виклик відхилено.
• Використайте токен з іншим пакетом. Його відхилено.
• Для будь-якого виклику в журналі минулого тижня назвіть завдання та його бюджет.

🚧 Коли це не працює

• Шлюз стає єдиною точкою відмови. Якщо він лежить, не працює жоден виклик моделі. Запускайте його як керований сервіс із політикою перезапуску.
• Ключі деінде. Якщо профіль оболонки розробника досі експортує ключ, агент його успадковує. Перевіряйте й оболонки.
• Токени з довгим життям. Токен, що живе тиждень, — це ключ із зайвими кроками. Прив'язуйте його до завдання.
• Збій одного провайдера. Шлюз його не усуває. Визначте політику резервних варіантів і логуйте їх.
• Локальні моделі. Модель на вашому власному обладнанні не має ключа. Журнал вам усе одно потрібен.

📊 Докази

➡️ Далі

Подивіться, як бюджет резервується до запуску завдання, у Витрати, бюджети та ліміти, а що перевіряти в з'єднанні — у Контрольний список безпеки сервера MCP.

Джерела

• Витрати, бюджети та ліміти: резервування витрат.
• Контрольний список безпеки сервера MCP: перевірки перед підключенням даних.
• Дозволи та потік даних: чого агент може торкатися.
• Квитанції завдань агента: що вони доводять: докази на кожен запуск.