Безопасность агентов A2A и MCP: идентификация, делегирование и журналы аудита

Инъекция промптов привлекает основное внимание в области безопасности систем на базе больших языковых моделей (LLM), и это заслужено, но это не вся проблема, когда агенты начинают вызывать инструменты и делегировать работу другим агентам.

MCP предоставляет агенту структурированный доступ к файлам, API, базам данных и системам отслеживания задач (ticketing systems). A2A позволяет одному агенту отправлять задачи, сообщения и артефакты другому агенту, который может принадлежать другой команде, вендору или среде выполнения. Эти протоколы полезны именно потому, что они пересекают границы доверия, что означает, что идентификация, авторизация, лимиты делегирования и журналы аудита становятся первоклассной архитектурой, а не опциональным усилением.

Эта статья является каноническим руководством по безопасности протоколов агентов в кластере Архитектура LLM. Она охватывает модели угроз, идентификацию, шлюзы, реестры, делегирование и чек-листы для производственной среды. Что касается валидации входных данных, фильтрации выходных данных и паттернов безопасности промптов, см. Защитные барьеры LLM на практике.

Защитные барьеры против безопасности протоколов и политики выполнения

Эти три уровня решают разные проблемы и по-разному терпят неудачу при их смешении.

Защитные барьеры LLM работают с входными и выходными данными модели: блокируют паттерны инъекций, фильтруют вредоносный контент, валидируют структуру JSON и применяют правила тона или соответствия к сгенерированному тексту. Они защищают уровень разговора.

Безопасность протоколов работает на границах агентов: кто может вызывать какие инструменты MCP, какой агент может делегировать другому одноранговому агенту, какие области OAuth прикреплены к задаче и может ли downstream-агент действовать от имени пользователя. Он защищает уровень действий.

Политика выполнения (Runtime policy) находится между ними: движок политик, который оценивает запросы по правилам независимо от того, был ли триггером естественный язык или структурированный вызов протокола. Он может требовать одобрения человека перед выполнением инструмента, блокировать исходящий трафик на неизвестные домены или отказывать в делегировании, когда область превышает права исходного пользователя.

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

Модель угроз для систем агентов A2A и MCP

Начинайте с активов и противников, а не со списка покупок средств контроля.

Активы, которые стоит защищать: пользовательские данные в промптах и артефактах, учетные данные для серверов MCP, производственные системы, доступные через инструменты, репутация агентов, счета за оплату, привязанные к использованию токенов, и целостность аудита.

Реалистичные противники: внешние пользователи, злоупотребляющие общедоступными конечными точками агентов, скомпрометированные серверы MCP, возвращающие отравленные результаты инструментов, злонамеренные агенты, искажающие свои навыки в картах агентов (Agent Cards), инсайдеры, чрезмерно делегирующие полномочия, и вмешательство в цепочку поставок с метаданными инструментов, которое манипулирует поведением модели.

Злонамеренные или скомпрометированные инструменты (MCP)

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

Злонамеренные или имитирующие агенты (A2A)

Агент, принимающий задачи, может быть злонамеренным, скомпрометированным или просто иметь избыточные разрешения. Карты агентов (Agent Cards) описывают возможности; они не доказывают идентификацию, если вы не проверяете подписи, TLS и доверие издателю.

Ошибочно назначенный заместитель (Confused deputy)

Агент B имеет разрешение на доступ к финансовому API. Агент A, с меньшими привилегиями, просит B «свести эту инвойс», подбрасывая инструкцию по переводу в артефакт. B выполняет ее, используя свои собственные учетные данные, если область делегирования не принудительно выполняется от начала до конца.

Чрезмерно широкие разрешения и скрытые цепочки делегирования

Пользователь одобряет один шаг. Оркестратор тихо связывает три прыжка A2A и пять вызовов MCP. Пользователь никогда не видит полный граф, но организация все еще несет ответственность за результат.

Инъекция промптов через артефакты и меж-агентные сообщения

Инъекция — это не только проблема пользовательского сообщения. Артефакт PDF, веб-страница, полученная инструментом, или сообщение от агента C могут нести инструкции, направленные на модель агента D. Относитесь ко всем содержимым, передаваемым по протоколу, как к недоверенному вводу на границе модели.

Отравленные или вводящие в заблуждение карты агентов (Agent Cards)

Описания и названия навыков — это поверхность промпта. Карта, рекламирующая safe_read_only_analysis (безопасный анализ только для чтения), но принимающая бэкенды с возможностью записи, — это слой социальной инженерии, а не техническая гарантия.

Модель идентификации для многоагентных систем

Безопасность протокола начинается с четких типов идентификации и того, что каждый из них может доказать.

Карта агента A2A рекламирует поддерживаемые схемы аутентификации (OAuth 2.0, API-ключи, mTLS и аналогичные паттерны, согласованные с практикой OpenAPI) и навыки с опциональными требованиями безопасности. Карта — это метаданные обнаружения, а не якорь доверия. Клиенты получают учетные данные вне протокола и отправляют их в стандартных заголовках HTTP при каждом запросе; серверы должны валидировать при каждом вызове и возвращать 401 или 403, когда аутентификация или область не прошли проверку.

Внутренний и внешний вид одного и того же агента

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

Аутентификация и авторизация для MCP и A2A

Аутентификация отвечает на вопрос кто вызывает. Авторизация отвечает на вопрос что они могут делать.

Доступ к инструментам MCP

Для каждого соединения MCP определите:

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

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

Доступ к агентам A2A

Для каждого отношения между одноранговыми агентами определите:

• какие ID вызывающих агентов могут вызывать какие навыки
• максимальную глубину делегирования
• какие типы артефактов могут пересекать границу
• должен ли контекст пользователя распространяться как подписанные утверждения

Сопоставьте области OAuth (или эквивалент) с навыками, а не с администрированием агента в целом. Наименьшие привилегии на уровне токенов лучше надежды на уровне промптов.

Политика, enforced шлюзом, против политики на уровне агента

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

Шлюз A2A как плоскость управления

Шлюз A2A строго не требуется протоколом, но становится необходимым, когда трафик агентов нуждается в централизованном управлении.

Шлюз обычно обрабатывает:

• завершение аутентификации и обмен токенами
• маршрутизацию к правильному сервису агента по навыку или арендатору
• проверки политик перед принятием или пересылкой задач
• согласование версии протокола
• ограничение скорости и обнаружение злоупотреблений
• структурированное эмиссию аудита при каждом переходе задачи

Когда шлюз — это перебор против необходимости

Шлюз часто является перебором для одного оркестратора и двух специализированных агентов в одном пространстве имен Kubernetes, поддерживаемом одной командой. Он становится необходимым, когда партнеры вызывают ваших агентов, когда несколько бизнес-подразделений делят инфраструктуру, когда соответствие требует единообразного логирования, или когда вы не можете доверять каждой реализации агента правильно enforcing политику.

Сопоставьте шлюз A2A с шлюзом MCP (или прокси MCP), чтобы доступ к инструментам получал такое же обращение: идентификация, списки разрешений, контроль исходящего трафика и аудит на границе инструмента, а не только в интерфейсе чата.

Карты агентов для партнеров против внутренних

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

Безопасность реестра и обнаружения агентов

Обнаружение — часть поверхности атаки. Любой, кто контролирует, какие агенты появляются «доступными», контролирует, куда оркестраторы отправляют работу.

Реестр против хорошо известных URL-адресов карт агентов

Малые развертывания используют хорошо известные URL-адреса для каждого агента (/.well-known/agent-card.json). Корпоративные развертывания добавляют реестр, который индексирует ID агентов, версии, конечные точки, владельцев и теги политик. Реестр — это объект политики: записи должны указывать, какие арендаторы могут обнаруживать какие агенты, а не только где они живут.

Версионирование, устаревание и владение

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

Внутренние корпоративные сети против внешних партнеров

Внутренние меши агентов могут полагаться на mTLS и частный DNS. Партнерским агентам нужны явные правила федерации, контрактно ограниченные навыки и более сильная инспекция артефактов, потому что вы не контролируете их среду выполнения.

Делегирование через границы агентов

Делегирование — это то, где безопасность A2A выигрывается или проигрывается. Когда Агент A отправляет задачу Агенту B, три вопроса должны иметь четкие ответы:

1. Чья власть осуществляется? Пользователя, учетной записи сервиса A или смешанного делегированного токена?
2. Что B разрешено делать с этой властью? Анализ только для чтения или мутирующие инструменты от имени A?
3. Кто несет ответственность, если B превышает область? A, B, политика шлюза или человек, который одобрил неясный промпт?

Распространение намерений пользователя против чрезмерного делегирования

Передавайте подписанные утверждения делегирования, которые включают ID пользователя, ID исходной задачи, разрешенные навыки, срок действия и максимальное количество прыжков. Downstream-агенты должны отклонять задачи, которые расширяют область молча. Если B нуждается в более высоких привилегиях, чем у A, перейдите к input_required и получите явное одобрение человека, а не обновляйте токены невидимо.

Потоки одобрения человека в цикле для рискованного делегирования описаны в Потоки A2A и асинхронные задачи для долгосрочных рабочих процессов агентов, где input_required является первоклассным состоянием задачи, а не ошибкой.

Разделение рассуждений и разрешений на выполнение

Агенту может потребоваться широкий доступ чтения для планирования, в то время как инструменты записи находятся за одобрением. Разделите учетные данные или используйте отдельные профили MCP для планирования против выполнения, чтобы ошибка модели не могла немедленно мутировать производство.

Журналы аудита и происхождение ответов

Если вы не можете восстановить цепочку делегирования, вы не можете объяснить инцидент, пройти аудит или оспорить аномалию в биллинге.

Логгируйте на трех уровнях:

Шлюз: результат аутентификации, решение политики, ID маршрутизированного агента, ID задачи, ID родительской задачи, события ограничения скорости.

Агент: переходы состояний задачи, отправленные/полученные сообщения, вызовы модели/инструментов (аргументы, отредактированные по мере необходимости), созданные артефакты, делегирование наружу.

Сервер MCP: имя инструмента, ID вызывающего агента, контекст пользователя, успех/неудача, задержка, затронутые строки или ID ресурсов (при разрешении политики).

Коррелируйте с ID трассировки на всех уровнях. Наблюдаемость для систем LLM охватывает бэкенды инструментирования; эта статья определяет что должно быть захвачено, чтобы эти бэкенды имели значимый сигнал.

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

Политика выполнения, исходящий трафик и секреты

Движки политик выполнения (OPA, Cedar, пользовательские сервисы правил) оценивают структурированные события: «инструмент X с аргументами Y для пользователя Z». Они дополняют защитные барьеры, потому что не зависят от того, хорошо ли ведет себя модель.

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

Контроль исходящего трафика ограничивает, какие домены серверы MCP и агенты могут вызывать. Агент, который может и читать секреты, и POST на произвольные URL, — это потеря данных, ожидающая своего часа.

Секреты никогда не должны быть в картах агентов или промптах. Хосты MCP должны инжектировать краткосрочные учетные данные во время выполнения из менеджера секретов. Что касается шифрования транспорта, управления ключами и базовых паттернов безопасности инфраструктуры, см. Архитектурные паттерны для защиты данных.

Вебхуки push-уведомлений в асинхронных потоках A2A нуждаются в той же строгости: проверяйте идентификацию отправителя, отклоняйте устаревшие события и никогда не относитесь к полезной нагрузке вебхука как к авторизации по собственному праву.

Референсная архитектура безопасности

Следующая диаграмма суммирует ориентированную на производство компоновку для развертываний A2A снаружи, MCP внутри в масштабе.

Оркестратор видит специализированных агентов через A2A. Специалисты видят инструменты через MCP. Пользователи никогда не получают сырые учетные данные MCP, а партнеры никогда не получают внутренние поверхности навыков без обзора политики.

Что касается концепций протокола (карты агентов, задачи, артефакты), см. Что такое протокол A2A?. Что касается принятия и корпоративного фрейминга, см. Протокол A2A Google в 2026 году. Что касается топологии, когда многие агенты координируются, см. Паттерны оркестрации многоагентных систем.

Чек-лист производства для безопасности A2A и MCP

Перед тем как экспонировать протоколы агентов за пределы доверенного песочницы, проверьте:

Идентификация и аутентификация

• Нет анонимных агентов в производственных путях
• Каждый вызов MCP и A2A аутентифицирован при каждом запросе
• Области OAuth или эквивалент сопоставлены с навыками/инструментами, а не с администрированием в целом
• Публичные и аутентифицированные виды карт агентов определены намеренно

Делегирование и политика

• Токены делегирования несут ID пользователя, ID задачи, область, срок действия, лимит прыжков
• Downstream-агенты отклоняют расширение области без явного одобрения
• Инструменты с высоким риском требуют политики выполнения или одобрения человека
• Рассуждения и выполнение используют отдельные учетные данные, где возможно

Обнаружение и реестр

• Записи реестра агентов имеют владельцев и историю версий
• Карты агентов обновляются по TTL; подписи проверяются, где поддерживается
• Партнерские агенты федерированы с явными списками разрешенных навыков

Аудит и наблюдаемость

• Слой шлюза, агента и MCP эмиссируют коррелированные события аудита
• Цепочки делегирования логируются с ID родительской и дочерней задач
• Происхождение артефактов записано для финальных ответов
• ID трассировки подключены к бэкендам наблюдаемости

Злоупотребления и устойчивость

• Ограничения скорости на пользователя, агента и арендатора
• Политики таймаута на делегированные задачи
• Списки разрешенных исходящих трафиков на серверах инструментов
• Секреты в менеджере, а не в картах, промптах или репозиториях

Заключение

Взаимодействие A2A и MCP мощно, потому что агенты и инструменты могут композироваться через границы команд и вендоров, но эта сила небезопасна без дизайна идентификации, авторизации, лимитов делегирования и аудита. Защитные барьеры защищают разговор модели; безопасность протоколов защищает действия, которые агенты предпринимают от имени пользователей.

Относитесь к картам агентов как к рекламе, к делегированию как к подписанному контракту, к инструментам MCP как к выполнению привилегированного кода, и к журналам аудита как к цепи доказательств, которая вам понадобится, когда что-то интересное случится в 2 часа ночи.

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

Часто задаваемые вопросы

В чем разница между защитными барьерами LLM и безопасностью агентов A2A MCP? Защитные барьеры ограничивают входные и выходные данные модели. Безопасность протоколов ограничивает, кто может вызывать инструменты, делегировать задачи и действовать от чьего имени через MCP и A2A с использованием идентификации, авторизации и журналов аудита.

Как должна работать идентификация агентов в развертывании A2A? Разделяйте идентификацию человека, сервиса агента и задачи. Валидируйте учетные данные при каждом запросе, используйте токены с областью и относитесь к картам агентов как к метаданным обнаружения, а не к доказательству доверия.

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

Нужен ли вам шлюз A2A в производстве? Внутренние развертывания одной команды могут enforcing политику на уровне агента. Многоарендаторные, многовендорные или партнерские сети обычно нуждаются в шлюзе для централизованной аутентификации, маршрутизации, ограничений скорости и аудита.

Что должен содержать журнал аудита A2A MCP? ID пользователя, ID агента, ID задачи, ID родительской задачи, вызовы инструментов, решения политики, артефакты и временные метки, коррелированные с ID трассировки на слоях шлюза, агента и MCP.

Источники

• Протокол A2A – Темы безопасности, готовые для предприятия: https://github.com/a2aproject/A2A/blob/main/docs/topics/enterprise-ready.md
• Протокол A2A – Обзор спецификации: https://a2a-protocol.org/latest/specification/
• Протокол A2A – Безопасность потоков и push-уведомлений: https://a2a-protocol.org/latest/topics/streaming-and-async/