Ложное предположение
В какой-то момент разработчики агентских фреймворков сделали молчаливое предположение: если агент создал это, значит, следующий агент может этому доверять. Это предположение сейчас заложено в каждой крупной агентской платформе. Об этом не объявляли. Это не обсуждалось. Это просто выпустили, и оно до сих пор там.
Спросите любого поставщика агентских фреймворков об инъекциях промптов — и запаситесь кофе, потому что это надолго. Платформы управления качеством и безопасностью не намного лучше: все соревнуются за лучший уровень ограничений, самый строгий движок политик и самые надежные защитные барьеры. И честно говоря? Эта работа важна. Но вся она направлена на одно и то же. На парадную дверь. Кто стучит, что с собой несет, стоит ли впускать.
Никто не говорит о том, что происходит внутри.
Сообщество специалистов по безопасности не полностью молчит об этом. OWASP прямо упоминает об этом в своей 2026 Top 10 for Agentic Applications: ASI07, Insecure Inter-Agent Communication. В официальном определении говорится, что обмен данными между координирующими агентами лишен надлежащей аутентификации, проверки целостности или ограничений политик. Названо, каталогизировано, присвоен номер. Индустрия знает, что это существует.
И индустрия все еще пытается исправить это с помощью не тех инструментов, потому что большинство людей, создающих средства защиты, в корне не понимают архитектуру агентской передачи.
Когда агент завершает свою работу и передает контекст следующему, происходит кое-что интересное. Принимающий агент не подвергает это сомнению. Не проверяет. Он просто подхватывает эстафету и продолжает работу, как будто так и задумывалось. И, возможно, это кажется нормальным. Но в какой-то момент стоит задать вопрос: кто это решил? Потому что я не думаю, что кто-то действительно принимал такое решение. Оно просто стало стандартным поведением.
Это не ваша платформа управления подводит вас. Это сам фреймворк.
В архитектуре нет контрольных точек
Итак, у меня есть интересный вопрос. Когда один агент завершает свою работу и передает ее другому, где именно происходит эта передача? То есть физически, архитектурно: в какой момент?
Большинство систем, передающих информацию, имеют границы — рубежи, где одно заканчивается и начинается другое. У API-вызова есть отправитель и получатель. Вебхук срабатывает и куда-то доставляется. У очереди сообщений есть сообщение с началом и концом. Эти границы полезны. Именно там вы можете перехватить что-то, изучить, решить, должно ли это двигаться дальше. Этот зазор — и есть вся суть.
При передаче данных от агента к агенту такого нет. Представьте общий документ Google Doc. Один человек перестает печатать, другой продолжает читать. Никакого конверта. Никакого момента передачи. Просто единый непрерывный процесс, который продолжается. Это ближе к тому, как большинство агентских фреймворков передают контекст между узлами: один агент пишет, следующий подхватывает, а поток на самом деле никогда не прерывается.
Что, справедливости ради, объясняет, почему эти системы кажутся быстрыми и слаженными. Непрерывный поток — это преимущество.
Это также объясняет, почему здесь негде разместить контрольную точку. Не потому, что никому не пришло в голову ее добавить. А потому, что в архитектуре физически нет для нее места. Стыки существуют внутри отдельных фреймворков. Чего не существует, так это единой поверхности обеспечения соблюдения правил, которая работала бы во всех них. Эту проблему нельзя решить одной лишь конфигурацией. Сама архитектура должна измениться.
Радиус поражения
LangChain. AutoGen. CrewAI. OpenAI. Anthropic. Выбирайте любой фреймворк. Все они впечатляют: оркестрация, маршрутизация, возможность объединять сложные рабочие процессы в цепочки.
Но найдите ту часть, где один агент принимает решение о том, стоит ли последовательно доверять другому, через каждую границу, независимо от того, какой фреймворк или поставщик находится с любой из сторон. В некоторых фреймворках есть точки вмешательства. В AutoGen есть обработчики, которые могут проверять и изменять сообщения между агентами. Эта работа реальна. Но она привязана к конкретному фреймворку, реализуется внутри него и не распространяется на границы между разнородными системами.
Как только двум агентам из разных фреймворков или от разных провайдеров нужно поговорить друг с другом, эта защита прекращает действовать.
И дело не в том, что я придираюсь к конкретным вендорам. В этом-то и суть. Это общеотраслевое предположение, которое внедрили настолько рано, что никто не додумался записать его на бумаге. Фреймворки создавались, чтобы ответить на вопрос «как агенты работают вместе», и они отлично с этим справились. Никто не задал вопрос «должны ли агенты автоматически доверять друг другу», поэтому этот вопрос просто пропустили.
Исследователи проверяли это. В статье Калабрийского университета 2025 года были протестированы 18 передовых LLM, и выяснилось, что 100% из них могут быть скомпрометированы через эксплуатацию доверия между агентами. Не некоторые. Все до единой. Включая те, которые успешно противостояли прямым инъекциям промптов. Модели, прошедшие проверку на «парадной двери», полностью провалились, оказавшись внутри.
Уязвимость не в моделях. Она в передаче.
Последствия пробела, который никто не закрыл
В официальном FAQ компании OpenAI по поводу Dots об инъекциях промптов — одном из известных способов, с помощью которых вредоносный контент может перехватить управление агентом посреди задачи — говорится следующее:
«Эти средства защиты помогают снизить риск выполнения нежелательных действий под воздействием вредоносных инструкций, но они не устраняют его полностью».
Это прямая цитата. Но вдумайтесь в эту фразу на секунду. Это постоянно работающий агент, который взаимодействует с вашей электронной почтой, календарем, Slack и подключенными приложениями. Он действует проактивно в фоновом режиме, пока вы находитесь на встрече или спите.
Ответом OpenAI на вопросы управления являются автопроверка, пользовательские правила и мониторинг безопасности. Это реальная работа. Но всё это находится внутри их экосистемы. Их правила, их инфраструктура, их средства контроля. Вы можете за этим наблюдать. Но вы не можете этим управлять.
Пробел в доверии, который каждый open-source фреймворк тихо выпустил по умолчанию, не остался в инструментах разработчика. Он просто попал в миллионы учетных записей потребителей и предприятий, работая непрерывно и будучи подключенным практически ко всему.
Это совсем не тот разговор, который индустрия вела до сих пор.
Необходимая основа
Вот тут-то и начинается самое интересное. Поскольку внутри небольшого числа корпоративных агентских развертываний заложен архитектурный паттерн, который действительно создает стык, отсутствующий в индустрии.
MuleSoft называет это Omni Gateway. Идея проста: вместо того чтобы каждый агент в графе обращался к своему провайдеру LLM напрямую, каждый вызов LLM сначала проходит через центральный прокси-сервер моделей. Каждый узел. Каждый провайдер. Каждый вызов. Прокси — это хаб. Агенты — это лучи. Agent Fabric изначально построен на основе этого паттерна — прокси не добавляется поверх, он является основой.
Очевидно, что это решение для управления, но также и нечто структурно более важное. Впервые между агентом и моделью появляется реальный момент взаимодействия. Место, где что-то может быть проверено до того, как пойти дальше. Тот самый стык, для создания которого фреймворк никогда не предназначался.
Хаб существует, и Agent Fabric уже осуществляет маршрутизацию трафика таким образом в корпоративных развертываниях, управляя контролем затрат, ограничением частоты запросов и соблюдением политик на уровне провайдера на уровне прокси. Это самая полная реализация этого паттерна из всех, что я видел в продакшене.
И причина, по которой я пишу об этом, заключается в том, какие возможности открываются с этого момента.
Семантическое слепое пятно
Прокси по схеме «звезда» (hub-and-spoke) может проверять множество вещей. Структуру HTTP. Заголовки аутентификации. Соответствие схеме. Пороговые значения стоимости. Это полезно, но работает только на поверхностном уровне.
Чего он не может делать сегодня, так это заглядывать внутрь сообщения и понимать его смысл.
Когда Узел 1 завершает работу и передает контекст Узлу 2, этот сеанс передачи представляет собой объект беседы. Большинство фреймворков представляют объекты беседы с помощью трех тегов ролей: system (система), user (пользователь) или assistant (ассистент); хотя провайдеры по-разному обрабатывают системную роль на уровне API. Эти теги — не просто украшение. Получающая модель использует их для определения полномочий и намерений. Какие инструкции выполнять. Чьи слова имеют вес. Внедрите контент не в ту роль или нарушите последовательность, и поведение модели изменится так, что прокси этого не заметит. Прокси может проверить конверт. Он не может определить, являются ли назначения ролей внутри него легитимными.
Ни один прокси не делает этого стабильно, во всех фреймворках, у всех провайдеров и в едином месте принудительного контроля. Ни один движок политик не проверяет, является ли последовательность ролей согласованной, соответствует ли она спецификации целевого провайдера или является ли поступившая беседа действительно той беседой, которая была отправлена. Прокси видит корректно сформированный HTTP-запрос и пропускает его. Что находится внутри — для него невидимо.
Это пробел внутри пробела. Индустрия нашла стык. Но никто еще не создал политику, которая понимает, что через него проходит.
Называйте это как хотите. Семантическая валидация. Управление последовательностью сообщений. Структурная наблюдаемость LLM. Название не имеет значения. Эта возможность пока не существует — а в мире, где агенты объединяются в цепочки в реальных системах и работают с реальными данными, ее отсутствие наносит серьезный скрытый ущерб, который никто не измеряет, потому что никто еще не создал инструмент для его измерения.
Архитектурное требование
Стык — это прокси модели, точка, где любой вызов LLM может быть перехвачен до того, как он достигнет провайдера. Omni Gateway от MuleSoft создан именно на этом стыке. Он управляет маршрутизацией, применением политик, ограничением частоты запросов (rate limiting) и аутентификацией для разных провайдеров до того, как будет переслан хотя бы один токен. Эта часть проблемы имеет решение.
У чего пока нет полноценного решения, так это у компонента, который находится на этом стыке и считывает объект беседы перед его пересылкой. Не валидация схемы, которая уже существует и полностью упускает это из виду. Что-то, что читает последовательность ролей и задает вопрос: имеет ли это смысл? Заканчивается ли она так, как ожидает этот провайдер? Примет ли ее любой из провайдеров без проблем или выдаст ошибку слишком поздно, чтобы ее остановить.
Когда что-то не проходит эту проверку, отклонение должно быть предусмотренным сценарием с обработчиком, а не исключением, которое ломает граф или позволяет накапливаться некорректному контексту на последующих этапах. Стык существует для того, чтобы это стало возможным. Этот валидатор пока не существует повсеместно, во всех фреймворках, в едином применимом на практике месте.
Итак, вот вопрос, с которым следует подходить к оценке любого фреймворка и шлюза. Вопрос перестает звучать как «где мы можем перехватить все сообщения?». Он превращается в следующий: как нам сохранить и обеспечить соблюдение семантики доверия, когда контекст перемещается между независимо реализованными агентами и моделями? Для этого требуется среда принудительного контроля, которая работает со всеми ними, является согласованной, не зависит от провайдера и располагается на каждой границе независимо от того, что находится по обе стороны от нее. Agent Fabric построен именно на такой основе.
Агентные системы уже находятся в промышленной эксплуатации. Проблема доверия к ним — не теория. Каждое развертывание, работающее без валидации на уровне беседы, базируется на допущении, что получаемый контекст является согласованным, неизмененным и правильно структурированным. Это допущение никогда не проверялось. Начните задаваться вопросом, должно ли оно проверяться.
Если архитектура из этой статьи имеет отношение к тому, что вы создаете или оцениваете, эти материалы стоит прочитать:
- Обзор MuleSoft Agent Fabric — как Salesforce использует Agent Fabric внутри компании для объединения агентов под управлением единого брокера: Как Salesforce справляется с разрастанием агентов с помощью Agent Fabric.
- Omni Gateway — один шлюз, более 140 LLM, входит в существующие подписки MuleSoft: Любая модель, один шлюз.
- Обзор продукта Agent Fabric — что охватывает плоскость управления (control plane): реестр, мост MCP, шлюз ИИ, управление и оптимизация затрат.
- Начало работы с сетями агентов — официальная документация MuleSoft по развертыванию сети агентов, включая настройку шлюза и целевые среды развертывания.
- — отраслевая структура рисков, упомянутая в этой статье, включая ASI07 о небезопасном межсетевом взаимодействии агентов: genai.owasp.org
Источники: Lupinacci et al., “The Dark Side of LLMs: Agent-based Attack Vectors for System-level Compromise,” arXiv:2507.06850 (2025) · Bappy et al., “Adversarial Attacks in Multi-Agent LLM Pipelines,” arXiv:2608.00718 (2026) · Cai et al., “When Child Inherits: Structural Trust Boundary Violations through Memory Inheritance,” arXiv:2605.08460 (2026) · Paul & Nandy, “Beyond Single-Model Injection: A Threat Model and Defense Architecture for Prompt Injection in Multi-Agent Systems,” arXiv:2609.22949 (2026) · OpenAI, “Dots Privacy, Security, and Safety FAQs,” help.openai.com/en/articles/20001529, OWASP Gen AI Security Project, “OWASP Top 10 for Agentic Applications,” ASI07: Insecure Inter-Agent Communication (2026) · https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/
