Все статьи
forge ai-agents security 5 мин чтения

Всю неделю на HN спорили, что агент не должен держать ваши ключи. Наш их никогда и не держал.

На этой неделе лента разработки с ИИ сошлась на одном тезисе безопасности: не давайте агенту сырые учётные данные — подставляйте их на сетевой границе. OneCLI, Agent Vault от Infisical и крупные платформы за считаные дни выпустили вариации одного и того же. Ответ Forge — не ещё один инструмент, который надо прикрутить: платформа так разрешает учётные данные с самого начала, серверно на границе исходящего трафика, так что секрет никогда не попадает в контекст агента. Вот эта граница и почему «агент его не видит» сильнее, чем «агенту доверено быть аккуратным».

автор Dmitry Creed

Самый громкий тред недели про разработку с ИИ был не про модель. Он был про ключ.

23 июля OneCLI вышел на главную Hacker News с обманчиво простым питчем: сетевой шлюз между вашими ИИ-агентами и сервисами, к которым они обращаются, который — словами самих основателей — «подменяет плейсхолдер настоящими учётными данными и отправляет запрос дальше». Агент просит вызвать API; ключа он при этом не держит. Несколькими днями раньше Infisical выпустил Agent Vault — открытый прокси учётных данных на ровно той же посылке, с целью дать агентам доступ к сервисам без чтения ими секретов. Комментарии наполнились десятком других вариантов той же идеи — gh-proxy, varlock, «просто используйте OIDC», — и все кружили вокруг одного вывода.

Вот тезис, к которому они все пришли, и он верный: агент — последнее место, где должны лежать сырые учётные данные. Агент недетерминирован, уязвим к инъекции промпта и, что важнее всего, он всё записывает. Он кладёт секреты в память, в файлы сессий, в текст, который сам порождает. Как сформулировали основатели OneCLI, агенты «держат их в памяти, а ещё записывают в локальные файлы и свои сессии открытым текстом» и их «легко обмануть и заставить выдать эти API-ключи». Как только секрет попал в контекст агента, вы потеряли контроль над тем, куда он уйдёт дальше.

Именно эту проблему лента переоткрыла на этой неделе. И именно эту проблему Forge решил не допускать в принципе.

Инструмент, который никогда не надо было прикручивать

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

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

Это видно уже по форме самих инструментов. Когда агенту Forge нужен секрет напрямую, выборка записывает значение в файл с правами 0600 и возвращает в контекст агента только метаданные — размер в байтах, префикс хеша. Открытый текст лежит на диске, чтобы его прочитал следующий шаг; в разговоре его нет. И платформа активно стережёт выход: ответы, содержащие строки, похожие на учётные данные, вычищаются и отправляются в карантин. Агента не просят быть аккуратным с секретами. Ему структурно не дают их носить.

Один из комментаторов под запуском OneCLI проговорил идеал вслух: «Я знаю решение, где учётные данные до агента вообще не доходят. Это структурно невозможно». Вот это и есть планка. Структурная невозможность, а не дисциплинированное намерение.

Ограничение области, чтобы утёкшая ссылка ничего не стоила

Держать секрет вне контекста — половина дела. Вторая половина — сделать так, чтобы ссылку, которую агент всё-таки держит, нельзя было пустить в ход в другом месте. Здесь обсуждение недели стало острым: верхний комментарий в треде OneCLI возражал, что вы «всё равно даёте агенту статический токен, который можно вынести и использовать в другом месте». Это правильный вопрос к любой схеме подстановки учётных данных.

Ответ Forge — ограничение по нескольким осям. Секреты и исходящий трафик ограничены на агента, на рантайм, на процесс и на команду, так что ссылка на учётные данные имеет смысл только внутри ровно того контекста, в котором была выдана. Самый показательный вариант этой проверки мы провели на браузерных агентах: агент вёл настоящий Chrome внутри изолированного стенда , и тот же самый ограниченный токен, применённый к продакшен-инфраструктуре, вернул жёсткий HTTP 401. Не троттлинг — структурный отказ. Ссылка, вышедшая за свою область, ничего не открывает, потому что она никогда и не была ключом: это координата, которая разрешается только внутри своей границы.

Человек в контуре — сетевой факт, а не строчка в промпте

Третья опора, к которой сошлись на HN, — подтверждение: человеческий гейт на чувствительных действиях, обеспеченный ниже агента, чтобы он держался, что бы агент ни делал. OneCLI применяет его на сетевом уровне именно затем, чтобы он пережил любой путь — «MCP, CLI, curl или код, который агент написал на ходу».

Forge доказывает то же самое в другой комнате. Когда агент обнаруживает работу-продолжение, он не имеет права запустить её сам — действие ждёт человеческого гейта Approve . Агент предлагает, человек разрешает. Сложите три слоя — и получится полная граница: агент никогда не держит секрет, ссылка, которую он держит, разрешается только в своей области, а последствия ждут человека. Каждый слой закрывает отдельный отказ слоя над ним.

Что из этого следует

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

Попробуйте

Посмотрите на движок процессов , который ведёт контур, вернитесь к рассказу о том, как мы держим браузерных агентов на ограниченном токене, который в продакшене отдаёт 401 , или напишите на support@simple-container.com , если хотите автономных агентов, которые делают настоящую работу, ни разу не притронувшись к вашим ключам.