Запросы обнаружения и мутации для более безопасных ИИ-агентов

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

На практике это разделение не так очевидно, как кажется. Конечная точка, которая считается доступной только для чтения, обновляет кэш. Предварительный просмотр выделяет удалённую задачу. Маршрут обновления принимает пустой фильтр и затрагивает все записи. Команда SSH выглядит безобидно, пока подстановка оболочки не превращает узкий путь в широкий. Имена методов и добрые намерения не защитят производственный аккаунт.

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

Для обнаружения нужна другая форма разрешений

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

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

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

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

Полезная классификация задаёт вопрос: что удалённая система сможет наблюдать после завершения запроса?

1. Запрос обнаружения возвращает информацию и не меняет значимое бизнес-состояние, рабочее состояние или состояние биллинга.
2. Запрос мутации создаёт, обновляет, удаляет, выполняет, публикует, отправляет или иным образом меняет состояние, видимое за пределами системы.
3. Неоднозначный запрос нужно считать мутацией, пока кто-то не докажет обратное.

Третья категория важнее, чем обычно думают команды. Если никто не может объяснить побочные эффекты конечной точки по её контракту и контролируемому тесту, не включайте её в автоматический набор обнаружения только потому, что её название звучит безобидно.

HTTP-методы дают подсказку, но не решают вопрос о разрешении

Названия HTTP-методов помогают классифицировать вызовы, но не заменяют проверку конечной точки. RFC 9110 определяет GET, HEAD, OPTIONS и TRACE как «безопасные» методы, то есть клиент не запрашивает изменение состояния. При этом RFC предупреждает: сервер всё равно может записывать запросы в журнал, списывать плату с аккаунта или создавать другие побочные эффекты.

Эту разницу легко упустить. Безопасность HTTP описывает предполагаемую семантику запроса, а не криптографическую гарантию того, что реализация ничего не сделала. RFC 9110 возлагает на владельца ресурса ответственность за недопущение опасных действий, когда пользователи следуют соглашениям безопасных методов. Если сервис нарушает это обещание, агент не сможет его принудительно выполнить.

Считайте следующие правила отправной точкой, а не окончательным решением:

1. GET и HEAD обычно входят в список кандидатов на обнаружение. Сначала проверьте параметры запроса и документацию конечной точки.
2. POST, PUT, PATCH и DELETE относятся к мутациям, если только конкретная конечная точка не имеет документированного и проверенного поведения только для чтения.
3. OPTIONS может показывать возможности сервера, но некоторые платформы включают сведения, зависящие от аккаунта, и им тоже нужны ограничения области доступа.
4. Тест вебхука, предварительный просмотр задачи, экспорт отчёта или поиск могут использовать POST и при этом только наблюдать. Проверьте конкретный маршрут, а не выдавайте доступ ко всем POST-запросам.

Обратная ошибка тоже встречается часто. Разработчики иногда привязывают действие к ссылке или маршруту GET, потому что так удобнее. URL вроде /reports/monthly?refresh=true может пересобрать дорогой кэш отчёта. GET-маршрут с ?send=true может отправить уведомление. Агент будет следовать описанию API. Не рассчитывайте, что модель заметит, как разработчик сервера проигнорировал семантику HTTP.

Ищите в документации слова «создаёт», «запускает», «обновляет», «генерирует», «отправляет», «записывает», «синхронизирует» и «списывает». Такие глаголы должны вывести вызов из категории обнаружения, даже если маршрут использует GET. Затем протестируйте конечную точку на одноразовом аккаунте и сравните состояние до и после, включая очереди задач, уведомления, счётчики использования и записи аудита.

Ответ HTTP тоже помогает классифицировать запрос. Идентификатор задачи, идентификатор операции или URL нового ресурса часто означают, что удалённый сервис начал работу. Код 200 доказывает только, что сервер обработал запрос. Он не доказывает, что запрос был наблюдательным.

Определите ресурсы и эффекты до создания списков разрешений

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

Для каждого внешнего действия используйте запись вроде этой. Названия не важны, важны подтверждающие данные.

Action: repository pull request list
Channel: HTTP
Target pattern: GET /repos/{owner}/{repo}/pulls
Class: discovery
Data returned: title, status, branch names, review metadata
Side-effect evidence: API reference defines this endpoint as a list operation
Scope limit: named repositories only
Review date: 2025-02-14

Action: repository merge pull request
Channel: HTTP
Target pattern: PUT /repos/{owner}/{repo}/pulls/{number}/merge
Class: mutation
Effect: changes merge state and source history
Required control: explicit approval for each call

Такой перечень заставляет принять решение, которое команды часто оставляют расплывчатым: агенту разрешено знать об этом ресурсе или изменять его? Это разные права. В системе обработки задач можно разрешить просматривать название и статус, но запретить тексты комментариев, потому что в них есть данные клиентов. В облачном аккаунте можно разрешить список строго ограниченной рабочей нагрузки, но запретить доступ к идентификаторам аккаунта и платёжным сведениям.

Храните область доступа в записи о действии. GET /projects не описывает полезное разрешение, если учётные данные позволяют перечислить все проекты, когда-либо созданные компанией. Лучше указать организацию, репозиторий, пространство имён, аккаунт или путь, которые нужны агенту. Если внешний сервис не умеет так ограничивать учётные данные, задайте список разрешённых целей на шлюзе действий или не делайте это обнаружение автоматическим.

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

Запрос на чтение тоже может навредить системе

У доступа на чтение есть радиус поражения, поэтому ему нужны собственные ограничения. Агент, которому разрешено просматривать каждый репозиторий, имя секрета, заметку об инциденте, запись клиента и событие развёртывания, получает достаточно контекста, чтобы причинить ущерб, если злоумышленник контролирует процесс агента или его инструкции.

Популярная рекомендация звучит так: «сначала выдайте доступ только для чтения». Она кажется осторожной и совпадает с привычными названиями ролей IAM. Но она ошибочна, если широкая роль чтения подменяет анализ классификации данных. Широкое обнаружение часто становится главным источником утечки информации в дизайне.

Разделяйте два вопроса:

• Может ли запрос изменить удалённое состояние?
• Может ли ответ раскрыть информацию, которую агент не должен получать?

Запрос можно отнести к обнаружению только после положительного ответа на первый вопрос. Разрешать его вообще следует только после положительного ответа на второй. Не сводите обе проверки к одной метке.

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

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

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

По возможности разделяйте права на уровне учётных данных

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

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

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

Чистая схема часто включает три класса учётных данных:

1. Учётные данные обнаружения с доступом только к тем ресурсам, которые агент может просматривать.
2. Учётные данные мутации для ограниченных записей, которые всё равно требуют решения о подтверждении.
3. Экстренные учётные данные, которыми агенты никогда не пользуются, а люди получают только в рамках процесса реагирования на инцидент.

Не позволяйте учётным данным мутации по умолчанию выполнять запросы обнаружения. Это кажется безобидным, потому что конечная точка доступна только для чтения, но усложняет будущую проверку. Запись о том, что мощные учётные данные запросили ресурс, не объясняет, требовались ли агенту такие полномочия. Идентичность должна оставаться осмысленной.

Sallyport хранит API- и SSH-учётные данные в зашифрованном хранилище и сам выполняет исходящее действие, поэтому MCP-агент получает результат, а не секрет. Благодаря этому узкий маршрут обнаружения можно открыть агенту, не помещая bearer-токен или закрытый SSH-материал в его контекст.

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

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

Используйте авторизацию сессии, чтобы определить, какой процесс агента может пользоваться набором обнаружения. Затем требуйте отдельного подтверждения мутаций и показывайте запрос словами, понятными человеку. «POST /v1/jobs» плохо подходит для подтверждения. Формулировка «Запустить экспорт данных проекта northwind в архивный бакет, расчётный срок 30 дней» даёт проверяющему то, что нужно сверить.

Карточка подтверждения должна содержать цель, операцию, значимые параметры и идентификатор учётных данных. Не прячьте цель в длинном JSON. Если действие затрагивает несколько ресурсов, покажите количество и небольшой пример. Когда количество превышает обычный диапазон, потребуйте открыть полный список до подтверждения.

Запрос на ограниченное обновление может выглядеть так:

{
  "action": "update_issue",
  "target": {
    "repository": "payments-api",
    "issue": 1842
  },
  "changes": {
    "labels_add": ["needs-review"],
    "assignee": "release-manager"
  },
  "reason": "The release checklist is complete."
}

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

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

Удаление и внешнее выполнение требуют отдельного класса

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

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

Отдельный контроль для каждого вызова нужен, например, для таких действий:

1. Удаление, очистка, архивирование, если архив меняет доступность, и массовое удаление.
2. Изменение прав, членства, ролей, секретов, учётных данных и политик доступа.
3. Развёртывание, перезапуск, масштабирование, миграция и удалённое выполнение команд.
4. Отправка писем, публикация сообщений, создание внешних задач и запуск платных операций.

До того как подтверждение попадёт к человеку, заставьте агента разрешить идентификаторы и подготовить предварительный просмотр. Запрос удаления records?filter=status=inactive должен показать точное количество, фильтр и примеры имён. Ещё лучше, если агент сначала получит идентификаторы кандидатов и отправит список, который шлюз сравнит с запросом выполнения. Это не устраняет гонки, но помогает поймать самую частую ошибку: фильтр означает не то, что предположил агент.

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

SSH требует классификации на уровне команд

SSH сложнее классифицировать, чем хорошо спроектированный API: командная строка может одновременно просматривать и менять данные, вызывать оболочку, учитывать псевдонимы или менять поведение в зависимости от окружения. Нельзя безопасно считать весь хост доступным только для чтения лишь потому, что агент собирается выполнить команду просмотра.

Начните с явных команд и аргументов. git status --short, git log -n 20 --oneline и kubectl get pods -n staging могут быть действиями обнаружения, если ограничить рабочий каталог, контекст кластера и пространство имён. git push, kubectl apply, kubectl delete, rm, установка пакетов и перезапуск сервисов относятся к мутациям или опасному выполнению.

Отклоняйте составные команды оболочки при автоматическом обнаружении. Вот пример команды, которая выглядит как запрос списка, но возвращает управление оболочке:

find "$WORKDIR" -maxdepth 2 -type f -name '*.log' -print; $EXTRA_COMMAND

Даже если во время теста агент передаёт пустое значение EXTRA_COMMAND, позднее туда можно подставить что угодно, разрешённое SSH-идентификатором. Не одобряйте грамматику команд с ;, &&, ||, подстановкой команд, перенаправлениями, раскрытием шаблонов по неконтролируемым путям или вызовом интерпретатора, если само действие не проверяется как выполнение.

Используйте структурированные аргументы. Шлюз может принять действие list_recent_logs, проверить фиксированный каталог и числовой лимит, а затем сам собрать удалённую команду. Если можно использовать типизированное действие, агент не должен отправлять строку оболочки.

Тот же принцип относится к инструментам с глаголами чтения. kubectl get может раскрыть секреты, если ресурс и пространство имён заданы слишком широко. git show способен показать случайно добавленные в репозиторий учётные данные. Формируйте разрешения для команд с учётом исполняемого файла, подкоманды, аргументов, рабочего каталога и удалённой идентичности. Одного глагола недостаточно.

Журнал аудита должен показывать, что граница сработала

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

Записывайте и попытки, и завершённые действия. Отклонённый запрос на удаление важен: он может означать, что агент неправильно понял область доступа, что prompt injection попыталась направить его действия или что кто-то проверяет границу. Указывайте причину отказа, но не записывайте секреты и чувствительные тела ответов в журнал, доступный более широкому кругу людей, чем исходная система.

Для каждого действия сохраняйте в защищённой от незаметного изменения записи как минимум:

• идентификатор процесса агента и идентификатор сессии;
• класс действия: обнаружение, мутация, опасное действие или внешнее выполнение;
• идентификатор цели, метод запроса или форму команды и безопасное представление параметров;
• событие подтверждения, включая человека, который его дал, если подтверждение требовалось;
• результат, статус удалённой системы, ссылку на результат и временные отметки.

Цепочка хешей помогает обнаружить изменение журнала, но не делает расплывчатое событие полезным. Сохраняйте каноническую запись действия до выполнения, а запись ответа связывайте с ней. Если в журнале указано только POST /jobs, проверяющий всё равно не поймёт, запустил ли агент безобидный отчёт или дорогой экспорт.

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

Проверяйте границу на ошибках, а не только в штатных сценариях

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

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

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

Для каждого класса действий храните один полный пример трассировки. Хорошая трассировка достаточно коротка для чтения и достаточно конкретна, чтобы показать несоответствие:

09:14:03  discovery  GET /projects/acme/services?limit=20  allowed
09:14:05  discovery  GET /projects/acme/services/api-7/events  allowed
09:14:11  mutation   POST /projects/acme/services/api-7/restart  approval required
09:14:32  mutation   POST /projects/acme/services/api-7/restart  approved by operator
09:14:34  mutation   result: accepted, operation=op_481

Если в третьей строке вместо этого указано GET /services/api-7?action=restart, значит модель классификации уже обнаружила дефект. Исправьте контракт действия или оставьте этот маршрут под контролем мутаций. Не создавайте исключение только потому, что конечная точка неудобна.

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