Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Выбор формы промежуточного сообщения оказался отдельным каналом утечки в многоагентных системах: даже разрешённый текст может выдать закрытое состояние агента. В работе Jinghan Xu и соавторов, которая не прошла рецензирование и содержит замеры самих авторов, компилятор SICC сохранил работу протокола без обнаружимого прироста точности атакующего. Для архитектуры это означает, что проверять нужно не только поля сообщения, но и причину, по которой система выбрала именно такую форму.
Как форма сообщения выдаёт закрытое состояние
Контроль доступа обычно отвечает на вопрос, какие данные разрешено передать. После этого агент всё ещё может выбирать между несколькими допустимыми вариантами: короткой квитанцией, объяснением причины, списком полей или более общей формулировкой.
Если выбор зависит от закрытого контекста, сама форма становится сигналом. Например, кадровый агент может всегда передавать разрешённый маршрут «нужна координация с HR», но добавлять краткую причину только для случаев, связанных с визой. Получатель не видит прямого упоминания визы, однако учится восстанавливать это состояние по наличию объяснения.
Авторы называют это утечкой через канал выбора. Наблюдаемой формой считается тип сообщения, его структура и уровень детализации. Замена слов, удаление закрытой метки и выравнивание длины не закрывают канал, если закрытые данные продолжают влиять на выбор варианта.
Для проверки утечки сравнивают точность атакующего до и после чтения сообщения. Разница показывает, сколько информации добавил журнал общения сверх уже доступного публичного контекста. Это не абсолютная мера секретности: разрешённые поля сами могут коррелировать с закрытым состоянием.
Как SICC разрывает зависимость между данными и формой
SICC разделяет авторизацию и представление сообщения. Сначала процесс получает аутентифицированное требование получателя и независимую от текущего случая схему разрешённых полей. Затем он извлекает только разрешённые значения, выбирает форму по публичному требованию и проверяет, что сообщение полностью закрывает нужды протокола.
Детерминированная реализация сопоставляет каждому типу требования каноническую форму. Запрос маршрута получает квитанцию о маршруте, запрос краткой причины — фиксированную структуру с грубой категорией причины, запрос координационных данных — сообщение по заданной схеме. Выбирать вариант по оценке риска или по закрытому контексту нельзя.
Фиксированный текст при этом не обязателен. SICC допускает случайный выбор формулировки, если источник случайности независим от закрытых данных и определяется до доступа к ним. Поэтому контракт относится к зависимостям генератора, а не к конкретному языку шаблонов.
Последний элемент — точная проверка полезности. Если сообщение не выполняет требование получателя, система отправляет одинаковый сигнал отказа или передаёт случай на эскалацию. Это условие не даёт превратить само решение «пропустить или отклонить» в новый побочный канал.
На контролируемых задачах редактирование и передача операционных фактов повысили точность атакующего на 73,8 процентного пункта. Диагностический селектор, который выбирал среди очищенных сообщений с учётом закрытого состояния, сохранил прирост в 22,5 пункта. В воспроизведении 132 сценариев AgentLeak SICC передал все разрешённые значения без наблюдаемого раскрытия целевых и лишних полей; в 100 исполняемых задачах LangGraph он выполнил все требования, а измеренный дополнительный прирост точности составил 0.
Проверка охватывает подготовленные задачи из закупок, здравоохранения и кадровых процессов, воспроизведение одного шага AgentLeak и короткий процесс LangGraph. Доказанная гарантия действует только относительно корректной схемы авторизации: компилятор не скрывает уже разрешённые значения, не исправляет ошибочную политику доступа и не обеспечивает сквозную секретность всего процесса.
Когда работа меняет архитектурные планы
Работа меняет планы команд, которые собирались защищать межагентные сообщения только подсказками, удалением чувствительных слов или проверкой финального ответа. Если сообщения сохраняются в журналах, проходят через оркестратор или доступны скомпрометированному агенту, выбор формы следует считать частью политики информационных потоков.
Практический сдвиг состоит в том, чтобы вынести коммуникацию из свободной генерации LLM в отдельный проверяемый слой. У этого слоя должны быть аутентифицированные требования получателя, каталог разрешённых полей, проекция контекста на эти поля, генератор с публично проверяемыми зависимостями и точная проверка результата. В реализации из работы этот путь не требует вызовов LLM, перебора кандидатов или модели-оценщика.
SICC не требует размечать закрытое состояние во время работы и не строит модель конкретного атакующего. Это упрощает внедрение там, где команда может формально описать требования и разрешённые поля. Для процессов со свободными текстовыми запросами сначала понадобится надёжно превратить запрос в аутентифицированную схему: естественно-языковой разбор политик в работе не проверяли.
Главный вывод относится не к шаблонам как таковым. Безопасная коммуникация требует, чтобы после авторизации закрытый контекст больше не влиял ни на поля, ни на структуру, ни на уровень подробности, ни на решение отправить сообщение.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
