Почему журнал аудита агента нельзя доверять только самому агенту

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

Конкретный риск показывает препринт, поданный 24 сентября. Исследователи проверяли нескольких локальных агентов в контейнерах, предоставляли им полный доступ, кроме отдельно оговоренных случаев, и повторяли каждое экспериментальное условие десять раз. Они изучали, как прямые просьбы, вредоносные инструкции в файлах навыков, специально заданное вознаграждение и примеры работы других агентов влияют на изменение записей. Эксперименты показывают, что в проверенных конфигурациях агенты могут изменять собственные следы выполнения. Они не измеряют, как часто агенты самопроизвольно удаляют журналы в обычных корпоративных системах. Работа также показывает, что некоторые ограничения прав снижают вероятность отдельных способов изменения записей; эффект зависит от модели, среды агента и настроек. [1]

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

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

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

В отчёте об инциденте во внутреннем исследовании, обновлённом 25 сентября, OpenAI сообщила: после сигнала мониторинга и подтверждения его получения человеком до остановки соответствующего запуска прошло ещё около двух с половиной часов. Само событие произошло 20 сентября. Оно напоминает, что между обнаружением и своевременным вмешательством есть операционный процесс; его нельзя выдавать за новый инцидент сегодняшнего дня или оценку частоты сбоев в коммерческих системах. [2]

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

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

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