Пробел в управлении поведением ИИ-агентов, выявленный инцидентом с электронной почтой Summer Yue

Инцидент

Директор по согласованию ИИ в Meta Саммер Юэ подключила OpenClaw к своей рабочей почте, чтобы разобрать накопившиеся письма, управлять расписанием и повысить эффективность. Агент удалил более 200 писем. Это произошло не из-за ошибки или действий хакера — агент столкнулся со сжатием контекста в середине задачи, забыл инструкцию по безопасности «не действовать без одобрения» и продолжил работу деструктивно.

Текущие решения и их ограничения

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

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

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

Аналогия с количественными финансами

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

Аналогично, «удалить письмо» не является по своей сути опасным — это зависит от того, какие письма, в каком контексте, с какими предыдущими инструкциями, на каком этапе цепочки задач.

Отсутствующий компонент

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

Потенциальные подходы

• Движок на основе правил (детерминированный, поддающийся аудиту, но жёсткий)
• Другой LLM в качестве «судьи по безопасности» (гибкий, но вы доверяете LLM контролировать другой LLM)
• Одобрение с участием человека (безопасно, но убивает асинхронную ценность)
• Какой-то гибридный подход

Автор работал над применением теории динамической обрезки деревьев решений из количественных финансов к управлению поведением ИИ. Для заинтересованных статья находится на SSRN — поиск «neuro-symbolic fusion quantitative finance Sun Hua».