Бюджет задержки одобрения для более безопасных действий агентов

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

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

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

Бюджет задержки одобрения это срок для решения человека

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

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

У бюджета есть три части:

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

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

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

Это примеры, а не универсальная политика. У команды развертывания с дежурством окно может отличаться от окна одного разработчика. Важно заранее назвать ожидание, до того как сформируется очередь.

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

Измеряйте жизненный цикл запроса, а не нажатие кнопки

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

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

{
  "request_id": "req_7f31",
  "run_id": "run_241",
  "action_class": "bounded_write",
  "target": "issue tracker/project-amber",
  "created_at": "2025-03-08T14:02:01Z",
  "presented_at": "2025-03-08T14:02:03Z",
  "opened_at": "2025-03-08T14:09:18Z",
  "decided_at": "2025-03-08T14:10:06Z",
  "decision": "allow",
  "executed_at": "2025-03-08T14:10:07Z",
  "outcome": "success"
}

В такой структуре ожидание в очереди считается как opened_at - presented_at, время решения как decided_at - opened_at, а время запуска как executed_at - decided_at. Сохраняйте и created_at. Это помогает обнаружить менее заметный дефект: брокер удерживает запрос еще до того, как его кто-либо увидит.

Измерения можно получить обычным запросом, без сложной аналитической системы:

SELECT
  action_class,
  percentile_cont(0.50) WITHIN GROUP (ORDER BY opened_at - presented_at) AS p50_queue_wait,
  percentile_cont(0.95) WITHIN GROUP (ORDER BY opened_at - presented_at) AS p95_queue_wait,
  percentile_cont(0.95) WITHIN GROUP (ORDER BY decided_at - opened_at) AS p95_decision_time,
  count(*) FILTER (WHERE decision = 'deny') AS denied,
  count(*) AS total
FROM approval_requests
WHERE created_at >= current_timestamp - interval '14 days'
GROUP BY action_class;

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

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

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

Ожидание в очереди и время проверки указывают на разные дефекты

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

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

Время решения увеличивается, когда карточка заставляет проверяющего восстанавливать намерение агента. Запрос вроде «POST /v1/resources» невозможно нормально проверить. Нужно знать назначение, операцию, количество объектов, использованные полномочия и видимое последствие. Проверяющему не должно приходиться открывать терминал, изучать исходный код и выяснять, создает ли запрос черновик или отправляет сообщение клиентам.

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

1. Какой запуск агента создал запрос и какой подписанный процесс запустил этот запуск?
2. Какая внешняя цель получит действие?
3. Что изменится или какие данные покинут компьютер?
4. Какие ограниченные полномочия это разрешают?
5. Что произойдет, если проверяющий отклонит запрос или ничего не сделает?

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

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

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

Очередь проверки показывает, что процессу нужна другая форма

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

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

В 9:30 разработчик внимательно одобряет первые несколько операций чтения. В 9:45 у него встреча. К 10:30 агент уже поставил в очередь повторы и связанные вызовы. Разработчик возвращается, видит стену запросов к тому же сервису и быстро одобряет их. Один запрос создает публичный комментарий вместо черновика, потому что конечная точка и ожидаемый результат были спрятаны в необработанном тексте запроса. В этой очереди у разработчика не было реальной возможности его отличить.

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

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

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

Та же логика относится к SSH. Запрос на просмотр журнала сервиса и запрос на запуск миграции могут проходить через одно соединение, но им не место в одном классе одобрения. Идентичность соединения не равна идентичности действия.

Область одобрения должна следовать последствиям, а не способу передачи

Хорошая граница одобрения описывает, на что именно соглашается человек. HTTP и SSH, команда и вызов API, локальный и удаленный процесс это детали передачи. Они важны для реализации, но не объясняют проверяющему, обратимо ли действие, затрагивает ли оно внешнюю систему и насколько дорого обойдется.

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

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

• Цель: названный хост, репозиторий, проект или среда.
• Операция: чтение, создание черновика, обновление указанного поля или выполнение определенного семейства команд.
• Набор объектов: конкретные записи, файлы или сервисы.
• Длительность: одно действие, один запуск агента или короткое запланированное окно.
• Последствие: личное, обратимое, видимое извне или разрушительное.

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

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

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

Сначала меняйте рутинную работу, а уже потом ослабляйте контроль

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

Разбирайте медленный класс в таком порядке:

1. Выберите запросы из p95 и изучите всю последовательность вокруг каждого. Отдельно посчитайте повторы и дублирующие вызовы, отделив их от необходимых.
2. Отметьте первое действие, в котором меняется последствие. Часто именно там нужно явное решение.
3. Объедините детерминированные операции чтения в узкую область задачи с известной целью и сроком действия до завершения запуска.
4. Вынесите внешнюю публикацию, удаление, изменение разрешений и экспорт больших объемов данных в отдельные запросы.
5. Повторите задачу с реальным проверяющим, который не проектировал этот процесс. Если он не может назвать ожидаемый результат до одобрения, снова сузьте запрос.

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

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

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

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

Экран одобрения должен упрощать правильное решение

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

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

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

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

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

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

Назначайте ответственность и эскалацию до появления срочного запроса

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

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

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

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

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

Проверяйте очередь как последовательность решений

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

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

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

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

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

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