Модель угроз сформулирована прямо
Наш подход к безопасности начинается с неудобной посылки: LLM-агент — самый недоверенный компонент на пути запроса. Всё, что он может назвать открытым текстом, он может выдать в ответ модели, в аргумент вызова инструмента, в тело коммита или в URL картинки в Markdown. Поэтому мы проектируем с расчётом на утечку, а не в надежде, что её не будет.
Как секрет используется, не будучи раскрытым
Вместо того чтобы получить значение открытым текстом и вставить его в команду curl, агент пользуется secure-curl с плейсхолдерами:
| |
Плейсхолдер {{stripe_api_key}} раскрывается на прокси исходящего трафика Forge — на границе, которой агент не управляет, — а не в процессе агента. Настоящий доступ подставляется в исходящий запрос и уходит дальше. Агент никогда не видит значения, поэтому значение не может оказаться ни в его контексте, ни в транскрипте, ни в синхронизированном снимке сессии
.
Для обнаружения агенты вызывают secret_list, который возвращает только алиасы и метаданные — никогда значения.
Ограничено до минимума
Секреты шифруются при хранении в границах организации и ограничиваются одновременно по четырём осям — по агенту, по процессу, по рантайму и по команде. Персонаж видит только те алиасы, которые разрешает его устав, и это обеспечивается диспетчером инструментов, а не договорённостью.
Аудит без раскрытия
Каждое взаимодействие с секретом порождает строку аудита только на добавление: кто, когда, какой алиас, какой адресат — плюс солёный SHA значения, но не само значение. Цепочка выявляет подделку, а поскольку хеш посолён отдельным перцем организации, компрометации одного лишь журнала аудита недостаточно, чтобы восстановить доступ.
Та же позиция позволяет Simple Container держать зашифрованные в git секреты в безопасности от агентов, читающих ваш репозиторий, — фундамент, который нужен агентному конвейеру, прежде чем ему можно доверить отгрузку.