Secret Guard описывает локальную подмену секретов в запросах ИИ-агентов

README Secret Guard описывает локальный шлюз, который подменяет секреты в запросах к ИИ-модели и восстанавливает их в ответах. Это заявление разработчика, а не независимое подтверждение защиты.

Secret Guard описывает локальную подмену секретов в запросах ИИ-агентов. Тематическая карточка Comrad404.

README Secret Guard описывает локальный шлюз между инструментом ИИ-агента и внешним LLM-сервисом. По замыслу разработчика, шлюз заменяет секреты в исходящем запросе, а при возврате ответа восстанавливает исходные значения, в том числе в аргументах вызова инструмента. Для пользователя это дополнительный слой обработки трафика агента; описание механизма не доказывает, что секреты гарантированно остаются на устройстве.

В README проекта предлагается направить API base URL инструмента агента на локальный шлюз. Запрос проходит через него к поставщику модели, а ответ возвращается тем же маршрутом. README утверждает, что подмена и восстановление выполняются локально.

Подмена, восстановление и альтернативные режимы

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

Для отдельных секретов можно выбрать reject: согласно README, если секрет обнаружен в исходящем запросе, шлюз откажется пересылать его и вернёт ответ 503. В режиме placeholder секрет заменяется явной меткой, которая не восстанавливается. Если настоящий секрет появляется в ответе модели, README обещает предупреждение в журнале и временной шкале веб-интерфейса; сам ответ при этом, как заявлено, проходит без изменений.

Что известно об ограничениях защиты

README также заявляет об автоматической защите токенов API Secret Guard и зарегистрированных ключей поставщиков моделей. В приведённом примере показана строка, похожая по формату на токен, но автор README уточняет, что её значение вымышленное. Это иллюстрация описанного механизма, а не независимое подтверждение его работы.

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