Где агент хранит доступы: четыре границы вместо одного слова «безопасно»

Когда агент умеет читать почту, создавать задачи или обращаться к CRM, главный вопрос действительно меняется. Не «насколько умно он отвечает», а «какие полномочия получил, где лежит секрет и что остановит опасное действие». Ответ «в зашифрованном хранилище» важен, но неполон. Безопасный контур складывается минимум из хранения, выдачи, использования и одобрения.

AiHummer предоставляет защищённое хранилище для секретов, персональные подключения OAuth, API-ключи с ограниченными областями прав и гейты одобрения. Эти механизмы не делают все интеграции безопасными автоматически. Оператор выбирает область прав, подключает провайдера, определяет список инструментов, требующих одобрения человеком, настраивает сеть и следит за ротацией. Поэтому маркетинговый текст должен показывать границы, а не обещать абсолютную защиту.

Граница 1. Секрет хранится отдельно

Пароль или токен не должен находиться в профиле агента, системном промпте, сообщении пользователя, репозитории или обычном логе. Документация защищённого хранилища описывает зашифрованное хранилище и отделение значения от контекста модели. Инструмент получает учётные данные в момент вызова через разрешённый механизм выбора, а модель оперирует именем действия и аргументами, не самим секретом.

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

Не храните Bearer-токен в URL. RFC 6750 подчёркивает, что любой обладатель токена предъявителя (bearer token) получает соответствующий доступ, поэтому токен нужно защищать в хранении и транспорте, передавать по TLS и не помещать в URL, которые попадают в историю и логи.

Граница 2. Полномочие минимально

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

Документация API-ключей с ограниченными областями прав перечисляет chat, admin:read, admin:write, mcp, a2a и полный *. Последний оставляют для редких аварийных случаев. Для интеграции чата нужен chat, для панели только для чтения — admin:read. Не выдавайте admin:write, потому что «потом пригодится».

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

Граница 3. Секрет выбирается по контексту

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

Проверьте негативные случаи: нет привязки; две пересекающиеся привязки; пользователь отозвал OAuth; токен истёк; обновление токена не удалось; канал изменился; агент переключён. Безопасный результат — отказ или запрос подключения, а не автоматический выбор наиболее привилегированной учётной записи.

Не пересылайте в модель сообщение «токен истёк: abc…». Ошибка должна назвать провайдера, тип подключения и действие для оператора, но редактировать секрет. В интерфейсе показывают метаданные — владелец, метка, область прав, дата — без значения.

Граница 4. Одобрение человеком перед последствием

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

Одобрение человеком работает только для инструментов в списке. Если новый инструмент забыли добавить, универсального барьера не появится. Поэтому каталог действий должен иметь класс риска и автоматическую операционную проверку соответствия политике. Проверяющий должен видеть фактические аргументы: сумму, получателя, объект и последствие. Кнопка «одобрить действие» без деталей создаёт ритуал вместо контроля.

После одобрения выполняются именно просмотренные аргументы. Изменение между проверкой и выполнением недопустимо. Побочный эффект должен быть идемпотентным, чтобы восстановление хода не повторило отправку. Отклонение означает отсутствие вызова, а не «выполним позже». Истечение решения об одобрении и отзыв проверяющего тоже требуют правила.

Моделируемый сценарий OAuth-почты

Пользователь подключает личный почтовый аккаунт через OAuth. Защищённое хранилище содержит токены; интерфейс показывает только метаданные. Агент получает запрос подготовить письмо и формирует адресата, тему и текст. Инструмент отправки требует одобрения человеком. Пользователь видит итоговые аргументы, исправляет или отклоняет. После одобрения инструмент выбирает учётные данные действующего пользователя, обновляет токен доступа при необходимости, отправляет письмо один раз и записывает аудит без токена и полного чувствительного содержимого.

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

Операционная ревизия

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

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

Ограничения

Защищённое хранилище не означает, что данные никогда не покидают сервер: инструмент обращается к внешнему провайдеру по назначению. OAuth не гарантирует минимальную область прав — его выбирает конфигурация и провайдер. Одобрение человеком не покрывает все действия без явного списка и не исправляет вредные просмотренные аргументы. Шифрование хранения не заменяет TLS, политику исходящих соединений, аудит, ротацию и защиту ключевого материала. Возможности зависят от конкретного инструмента и плана.

Чек-лист

1. Удалить секреты из промптов, дампов окружения, URL и логов.
2. Хранить значения в защищённом хранилище или специализированном менеджере.
3. Выдать отдельную учётную запись и минимальную область прав.
4. Привязать учётные данные к правильному владельцу и целевому ресурсу.
5. Проверить обновление, истечение срока, отзыв и повторное подключение.
6. Запретить привилегированный резервный маршрут при ошибке разрешения.
7. Классифицировать инструменты по риску.
8. Включить одобрение человеком для нужного списка и показать точные аргументы.
9. Сделать побочные эффекты идемпотентными и сверяемыми.
10. Провести учебную ротацию и отзыв.

Если вы проектируете новый инструмент, начните не с API-метода, а с таблицы: кто действует, под какой учётной записью, с какой областью прав, какие аргументы видит проверяющий и что происходит при неизвестном результате. Такая таблица превращает слово «безопасность» в проверяемые границы.