# Кто одобряет действия ИИ-агента: ответственность по сменам

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

Я видел, как это происходит в обычных обстоятельствах, без драматического саботажа. Разработчик просит агента разобраться со сбоем сборки. Агент находит связанный рабочий endpoint, запрашивает запись для изменения настройки, а разработчик одобряет её, потому что запрос появился в его терминале. Владелец сервиса узнаёт об изменении позже, во время своей дежурной смены. У него нет контекста и нет полезного ответа на вопрос: «Кто согласился на этот риск?»

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

## Тот, кто начал сессию, редко отвечает за последствия

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

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

Разделите в своей схеме три роли:

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

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

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

NIST SP 800-53 Rev. 5, мера AC-2, требует назначать управляющих аккаунтами и устанавливать процедуры управления аккаунтами. В документе нет требований к экрану одобрения агента, но сам принцип хорошо подходит: ответственность за доступ нужно назначать явно, а не считать доступ свойством того, кто сейчас вошёл в систему. Для действий агента управляющим аккаунтом часто должен быть текущий владелец сервиса, а не пользователь рабочего компьютера.

## Владелец сервиса должен быть привязан к смене

Надёжная запись о владельце называет и сервис, и человека, отвечающего за него сейчас. Статического названия команды недостаточно в 02:00, во время отпуска или посреди инцидента.

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

Используйте границу сервиса, которой пользуются операторы при получении оповещения. «Payments API production» подходит. «Backend» не подходит. Слишком широкое название команды скрывает разные базы данных, поставщиков, классы данных и процедуры отката.

Минимальная запись может выглядеть так:

```yaml
service: billing-api-production
active_owner: billing-oncall
backup_owner: payments-duty-manager
escalation: incident-commander
approval_rules:
  read_customer_records: session
  change_remote_configuration: per_call
  production_database_write: per_call
  create_vendor_credentials: prohibited
```

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

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

## Риск действия определяется целью, а не глаголом

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

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

Практический набор категорий может быть небольшим:

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

Не объявляйте действие малорисковым только потому, что HTTP-методом является GET. Я видел диагностические endpoint, которые возвращали переменные окружения, подписанные ссылки и операционные сведения, не предназначенные для передачи агенту программирования. Классифицировать endpoint должен владелец, который понимает его назначение.

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

В тексте запроса нужно указать конкретную цель. Фраза «Агент запрашивает доступ к API» ничего не говорит владельцу. Фраза «Процесс агента запрашивает PATCH для рабочей конфигурации биллинга с использованием учётных данных billing-admin» даёт достаточно информации, чтобы остановиться и задать правильные вопросы.

## Ограниченная сессия не равна чистому бланку

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

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

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

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

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

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

## При передаче смены нужно передавать полномочия, а не только информацию

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

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

Используйте такую последовательность:

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

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

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

## Во время инцидентов полномочия должны становиться уже, а не держаться на памяти

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

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

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

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

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

## Запросы на одобрение должны помогать принять решение

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

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

Вот разница между полезным и бесполезным запросом:

```text
Request: production configuration change
Process: signed coding-agent process, session 8f3a
Owner: billing-oncall
Credential: billing-admin
Action: PATCH https://api.internal.example/v1/routing/default
Body: {"provider":"secondary"}
Scope: one call
Reason supplied: mitigate provider timeout during INC-482
```

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

Не делайте свободное поле «Причина» основой безопасности. Агенты легко создают убедительный текст. Считайте причину контекстом для человека, а цель, учётные данные и область одобрения контролируйте на уровне системы.

## Журналы аудита должны отвечать на неудобные вопросы

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

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

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

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

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

## Сбои владения обычно начинаются с удобного исключения

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

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

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

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

Такая модель заставляет команды ясно сформулировать сложный вопрос: кто сейчас владеет этой системой и что именно он готов разрешить?

## Проверьте модель владения настоящей сменой

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

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

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

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