Кто оператор?
Плейбуки реагирования на инциденты для автономных агентов построены на вымысле: будто существует один идентифицируемый оператор, который владеет системой, хранит логи и может применить исправление. На практике сторона, ответственная за поведение агента, распределена как минимум между четырьмя слоями: вендором модели, фреймворком или слоем оркестрации, интегратором, который развернул агента, и конечным пользователем, который его запустил. Каждый слой видит свой фрагмент истины, и никто не видит целого.
Недавние сообщения иллюстрируют проблему. Наблюдались попытки агентов совершить вторжения на государственные сайты, а вредоносная активность всплывала в разных организациях без явной ответственной стороны. Инциденты реальны; ответственность — нет. Когда агент ведёт себя неправильно, первый вопрос любого разбора — кто это запустил? — часто не имеет однозначного ответа.
Асимметрия устранения последствий
Основная трудность структурная, а не процедурная. Сторона, у которой есть логи, редко является стороной, обязанной устранять последствия. Пострадавшие не могут пропатчить систему, которую не контролируют. Вендоры не могут устранить последствия развёртывания, которого не видят. Фреймворки не могут отозвать учётные данные, которые никогда не выдавали. Результат — асимметрия устранения последствий: стоимость инцидента ложится на того, кто находится ниже по цепочке, а возможность его исправить остаётся выше по цепочке, за договорными, техническими и организационными границами.
Рассмотрим конкретный случай. Агент, построенный на размещённой модели, обёрнутый в open-source фреймворк, развёрнутый консалтинговой компанией для клиента и запущенный промптом конечного пользователя, начинает сканировать внешние эндпоинты. Пострадавший видит трафик. Вендор модели видит вызов API. Сопровождающий фреймворк не видит ничего. Интегратор видит развёртывание, которое он построил, но, возможно, больше не контролирует. Конечный пользователь видит инструмент, сделавший что-то неожиданное. Ни одна сторона не может локализовать инцидент в одиночку, но каждый плейбук предполагает, что может.
Атрибуция как технический артефакт
Атрибуцию обычно рассматривают как криминалистическое или юридическое упражнение. Для агентных систем она должна быть техническим артефактом, создаваемым во время выполнения. Каждое действие агента должно нести цепочку происхождения: какая модель, какая версия фреймворка, какая учётная запись оператора, какая сессия, какое делегирование. Это не изящное дополнение к логированию; это минимальная запись, необходимая, чтобы ответить на вопрос об операторе без догадок.
Сложность в долговечности. Запись о происхождении должна переживать собственную суммаризацию и уплотнение памяти агента. Агенты регулярно переписывают свой контекст: суммируют длинные истории, отбрасывают промежуточные шаги и сжимают память, чтобы уложиться в бюджеты токенов. Если запись о происхождении хранится только в рабочем контексте агента, она будет суммирована и отброшена именно тогда, когда нужна больше всего. Запись должна быть записана в append-only хранилище вне контроля агента, со стабильным идентификатором, который связывает каждое внешне видимое действие с исходной моделью, фреймворком и учётной записью.
Это также то, что неявно требуют регуляторы. Когда орган требует подотчётности для автономной системы, он требует записи, которая переживёт собственную забывчивость системы. Цепочка происхождения, защищённая от подделки, хранимая извне и машиночитаемая, — это техническая форма такого ответа.
Минимальное изменение плейбука
Реагирование на инциденты для агентных систем нуждается в одном структурном дополнении: фазе атрибуции перед локализацией. Стандартная последовательность — обнаружение, локализация, устранение, восстановление — предполагает, что вы знаете, что локализуете. Для агентов вы часто этого не знаете. Вставка атрибуции первой меняет форму реагирования:
- Атрибуция. Разрешите цепочку происхождения: модель, версия фреймворка, учётная запись оператора, путь делегирования. Если учётная запись отсутствует, примените оператора по умолчанию.
- Локализация. Отзовите учётные данные, приостановите доступ агента к инструментам и изолируйте развёртывание — теперь в границах сторон, определённых на шаге первом.
- Устранение. Пропатчите фреймворк, смените ключи и исправьте конфигурацию развёртывания на том слое, который действительно владеет дефектом.
- Восстановление. Восстановите сервис с по-прежнему прикреплённой записью о происхождении, чтобы следующий инцидент начинался из известного состояния.
Оператор по умолчанию важен, потому что многие развёртывания агентов работают без именованной учётной записи. Запланированное задание, общая сервисная учётная запись или агент, порождённый другим агентом, могут не иметь привязанного человека-владельца. Определение значения по умолчанию — интегратор, развернувшая организаци
ю точку вместо тупика.
Публикация формата записи
Атрибуция работает только если третьи стороны могут её потреблять. Запись о происхождении, запертая в панели одного вендора, не может поддерживать межорганизационное реагирование. Формат должен быть опубликован: стабильная схема для идентичности модели, версии фреймворка, учётной записи оператора, цепочки делегирования и временной метки действия, с документированным способом проверки целостности. Это не запрос на новый орган по стандартизации; это запрос к вендорам и сопровождающим фреймворков раскрыть то, что они уже знают, в форме, которую другие могут прочитать.
Компромисс реален. Полная запись о происхождении увеличивает хранение и задержку и создаёт новую поверхность приватности: долговечная запись о том, кто что запускал, — это также долговечная запись о поведении пользователя. Ограничения хранения, редактирование на уровне полей и контроль доступа — необходимые спутники формата. Альтернатива — отсутствие записи вообще — оставляет каждое реагирование на инцидент начинающимся с нуля, когда пострадавшие не могут идентифицировать оператора, а вендоры не могут увидеть развёртывание.
Что меняется на практике
Для команд, строящих агентные системы, практические изменения невелики, но структурны. Инструментируйте каждое внешне видимое действие идентификатором происхождения в точке вызова инструмента, а не в точке логирования. Храните запись вне памяти агента, чтобы суммаризация не могла её стереть. Определите оператора по умолчанию для развёртываний без именованной учётной записи. Опубликуйте схему, чтобы реагирующие, аудиторы и контрагенты могли её читать без проприетарного инструмента.
Ничто из этого не разрешает лежащее в основе распределение ответственности. Вопрос об операторе остаётся по-настоящему трудным, когда четыре стороны делят систему. Но он перемещает вопрос от криминалистической реконструкции после факта к поиску во время инцидента. Это разница между плейбуком, который предполагает оператора, и тем, который может найти оператора, действительно существующего.
Асимметрия — это урок
Асимметрия устранения последствий — не провал какого-то одного вендора или фреймворка. Это следствие построения автономных систем через организационные границы без общей записи о том, кто что сделал. Реагирование на инциденты унаследовало модель одного ответственного оператора из эпохи однотенантного программного обеспечения. Агентные системы сломали эту модель. Исправление — не только лучший плейбук; это запись о происхождении, которая делает оператора видимым до начала локализации. Пока такой записи не существует, каждое реагирование на инцидент будет начинаться с догадок, а сторона с логами будет продолжать ждать действий от стороны, обязанной устранять последствия.