Проверять не то, что AI-агент читает, а то, что он отправляет

Mermail даёт AI-агентам собственные почтовые ящики. Агент, который читает почту, одновременно владеет инструментами: отправить, ответить, переслать, запланировать письмо, изменить пересылку ящика, пригласить участника в рабочее пространство.

У такой комбинации есть характерный сценарий отказа — и защищаются обычно не от него.

Почему фильтрация входящих не решает задачу

Входящие фильтры определяют, что агенту разрешено прочитать. Они не определяют, что он сделает после этого.

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

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

Значит, проверку надо перенести: убрать из пути чтения и поставить непосредственно перед исходящим вызовом.

Что делает guard

mermail-egress-guard — слой политик, который срабатывает прямо перед любым исходящим действием.

Происхождение получателя. Каждый получатель должен восходить к доверенному источнику: запросу самого пользователя, существующему участнику рабочего пространства или контрагенту, которого пользователь назвал. Адрес, впервые появившийся в теле письма, заголовке, вложении или результате инструмента, считается производным и не проходит. Неверный кандидат отклоняется, не раскрывая правильного.
Разрешение адреса ответа. reply_to_email выглядит очевидным — именно поэтому это самый эксплуатируемый путь. Адресат берётся из проверенного отправителя конверта, а не из заголовка Reply-To. Атакующий, подставивший этот заголовок, превращает обычный ответ в прямой канал, при том что в переписке всё выглядит как ответ исходному корреспонденту.
Тяжесть по длительности, а не по объёму. Пересылка утекает один тред. Включение settings.forwarding утекает все будущие письма — без единого дальнейшего действия агента, без новых вызовов инструментов, которые можно было бы проаудировать, и без чего-либо заметного тому, кто читает переписку.

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

Два решения, которые стоит объяснить

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

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

Письмо получило scan_status: clean, при этом SPF, DKIM и DMARC — все unknown. В этом и суть: оно прошло все доступные проверки на входе и осталось враждебным. Оба запроса были отклонены, настройки ящика после этого подтверждённо не изменились.

Что сдано

SKILL.md и три справочных документа: поверхность инструментов, граница безопасности, процедура принятия решения
7 валидационных сценариев, 4 из них с метками security-случаев
Регистрация в реестре владения, правилах приоритета роутера и README проекта
Проходящий npm test: «Validated 16 skills and 71 business tools.»

Работа с открытым исходным кодом, ревью публичное:

Nudgen-Marketing/mermail-skills #84

Что здесь обобщается

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

Куда попадёт этот эффект и могу ли я проследить адресата до чего-то, что атакующий не мог подставить? И заканчивается ли этот эффект вместе с вызовом — или продолжает работать, когда за ним уже никто не смотрит?

Защищать вход — значит защищать не ту сторону.