Одобрение сессии или каждого вызова для действий агента

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

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

Ключевая фраза одобрение для сессии и каждого вызова описывает выбор, для которого нужны три исходных параметра: длительность работы, объем полномочий учетных данных и последствия повторного допустимого запроса. HTTP-метод, заявленный агентом план и присутствие разработчика дают менее надежные сигналы.

Одобрение разрешает действовать в определенных границах

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

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

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

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

Это различие важно даже во время обычной задачи программирования. Агент может использовать один API-токен для чтения статуса сборки, а другой для запуска выпуска. Процесс может быть достаточно надежным для проверки первого токена, но все равно требовать явного решения для второго. Идентичность процесса не делает риск одинаковым для всех доступных ему конечных точек.

У хорошей границы одобрения есть четыре свойства:

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

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

Длительность задачи меняет смысл обещания сессии

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

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

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

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

Рассмотрим несколько типов задач:

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

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

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

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

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

Перед выбором уровня одобрения я задаю четыре вопроса:

1. Может ли эта учетная запись изменить состояние за пределами локального компьютера?
2. Может ли она раскрыть информацию, которую нельзя безопасно помещать в контекст или вывод агента?
3. Может ли она предоставить дополнительные права напрямую или через запускаемый рабочий процесс?
4. Может ли вызывающая сторона потратить деньги, израсходовать квоту или создать договорное либо репутационное обязательство?

Положительный ответ не всегда требует одобрения каждого вызова. Но он означает, что для одобрения сессии нужны более узкая задача, строгая область доступа и реалистичный откат. Если положительных ответов несколько, честнее всего обычно спрашивать каждый раз.

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

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

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

Повторение превращает терпимое действие в дорогостоящее

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

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

Идемпотентность тоже часто понимают неправильно. Запрос идемпотентен, если его повторение оказывает на состояние сервера тот же предполагаемый эффект, что и однократное выполнение. Это не значит, что повтор безопасен. PUT, устанавливающий флаг в значение true, может быть идемпотентным, но все равно включать функцию в production. DELETE после первого удаления может оставаться идемпотентным, но удалить важный объект. GET может быть безопасным в смысле протокола и все равно исчерпать лимит запросов, если агент зациклится.

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

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

POST /v1/provisioning-requests HTTP/1.1
Authorization: Bearer injected-by-gateway
Idempotency-Key: agent-run-8b2f1-request-17
Content-Type: application/json

{\"environment\":\"staging\",\"version\":\"2025.04.18\"}

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

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

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

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

Метка «только чтение» не решает вопрос риска

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

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

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

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

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

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

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

Пусть уведомления соответствуют решениям, которые человек действительно может принять

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

Хорошее уведомление называет вызывающий процесс, учетные данные или категорию действия, назначение и существенный эффект. «Разрешить API-запрос» не позволяет принять обоснованное решение. «Подписанный процесс агента запрашивает production-развертывание с учетными данными выпуска» позволяет. Для чувствительного чтения нужно назвать набор данных или цель, а не просто написать «GET-запрос». Для SSH покажите хост и команду либо понятный класс команд.

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

В то же время не заставляйте людей разбирать необработанное тело HTTP для каждого обычного запроса. Это превращает одобрения в ритуал. Помещайте повторяющиеся малозначимые вызовы в ограниченную сессию, а уведомления для каждого вызова оставляйте операциям, пересекающим настоящую границу решения. Человек должен видеть меньше уведомлений, но каждое оставшееся должно иметь значение.

Рядом с каждой конфигурацией учетных данных оставьте короткую заметку об одобрении. Это не язык политик и не должно им становиться. Фраза «сессия только для чтения статуса сборки одного репозитория; каждое production-развертывание одобрять отдельно» делает последующие проверки конкретными. Если команда не может написать предложение, отделяющее обычную работу от значимого действия, учетные данные, скорее всего, слишком широкие.

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

Используйте матрицу решений до смены настройки одобрения

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

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

Рассмотрим пример. Агент расследует неудачное развертывание. Ему нужно прочитать журналы сборки, получить статус определенной staging-среды и, возможно, перезапустить один сервис.

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

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

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

Аудит объясняет неудачное решение, но не отменяет его

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

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

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

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

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

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

Узкое начало лучше широкого исключения

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

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

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

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