Seguridad de los agentes A2A y MCP: identidad, delegación y registros de auditoría

La inyección de prompts recibe la mayor parte de la atención en materia de seguridad en los sistemas de LLM, y merece esa atención, pero no es el único problema una vez que los agentes comienzan a invocar herramientas y delegar trabajo a otros agentes.

MCP otorga a un agente acceso estructurado a archivos, APIs, bases de datos y sistemas de tickets. A2A permite que un agente envíe tareas, mensajes y artefactos a otro agente que puede pertenecer a un equipo, proveedor o entorno de ejecución diferente. Estos protocolos son útiles precisamente porque cruzan límites de confianza, lo que significa que la identidad, la autorización, los límites de delegación y las trazas de auditoría se convierten en arquitectura de primer nivel en lugar de endurecimiento opcional.

Este artículo es la guía canónica sobre seguridad de protocolos de agentes en el clúster de Arquitectura de LLM. Cubre modelos de amenazas, identidad, puertas de enlace, registros, delegación y listas de verificación para producción. Para validación de entrada, filtrado de salida y patrones de seguridad de prompts, consulte Salvaguardas de LLM en la Práctica.

Salvaguardas vs. Seguridad de Protocolo vs. Política de Ejecución

Estas tres capas resuelven problemas diferentes y fallan de distintas maneras cuando se confunden.

Las salvaguardas de LLM operan sobre la entrada y salida del modelo: bloqueando patrones de inyección, filtrando contenido dañino, validando la estructura JSON y aplicando reglas de tono o cumplimiento en el texto generado. Protegen la capa de conversación.

La seguridad de protocolo opera en los límites del agente: quién puede invocar qué herramienta MCP, qué agente puede delegar a qué par, qué ámbitos de OAuth se adjuntan a una tarea y si un agente aguas abajo puede actuar en nombre de un usuario. Protege la capa de acción.

La política de ejecución se sitúa entre ambas: un motor de políticas que evalúa las solicitudes contra reglas independientemente de si el desencadenante fue lenguaje natural o una llamada de protocolo estructurada. Puede requerir aprobación humana antes de que se ejecute una herramienta, bloquear la salida a dominios desconocidos o denegar la delegación cuando el ámbito excede al del usuario original.

Mi opinión es contundente: las salvaguardas sin seguridad de protocolo producen chatbots educados que aún así exfiltran datos a través de una llamada a herramienta. La seguridad de protocolo sin salvaguardas produce agentes bien autenticados que aún así siguen instrucciones maliciosas incrustadas en un artefacto. Necesita ambos, más política de ejecución para acciones de alto riesgo.

Modelo de Amenazas para Sistemas de Agentes A2A y MCP

Comience con los activos y los adversarios, no con una lista de compras de controles.

Activos dignos de protección: datos de usuario en prompts y artefactos, credenciales para servidores MCP, sistemas de producción accesibles a través de herramientas, reputación del agente, cuentas de facturación vinculadas al uso de tokens e integridad de la auditoría.

Adversarios realistas: usuarios externos que abusan de los puntos finales públicos de los agentes, servidores MCP comprometidos que devuelven resultados de herramientas envenenados, agentes maliciosos que falsifican habilidades en las Tarjetas de Agente, insiders que delegan autoridad en exceso y manipulación de la cadena de suministro con metadatos de herramientas que manipulan el comportamiento del modelo.

Herramientas maliciosas o comprometidas (MCP)

Un servidor MCP es código más datos expuestos al modelo. Un servidor hostil puede devolver descripciones de herramientas engañosas, exfiltrar argumentos pasados por el modelo o realizar acciones más allá de lo que el usuario pretendió cuando el host ejecuta llamadas de herramientas sin credenciales con ámbito definido.

Agentes maliciosos o suplantados (A2A)

Un agente que acepta tareas puede ser malicioso, comprometido o simplemente con permisos excesivos. Las Tarjetas de Agente describen capacidades; no prueban la identidad a menos que verifique firmas, TLS y confianza del emisor.

Delegado confundido

El Agente B tiene permiso para acceder a una API de finanzas. El Agente A, con privilegios más bajos, le pide a B que “resuma esta factura” mientras se cuela una instrucción de transferencia en un artefacto. B ejecuta usando sus propias credenciales a menos que se aplique el ámbito de delegación de extremo a extremo.

Permisos excesivamente amplios y cadenas de delegación ocultas

El usuario aprueba un paso. El orquestador encadena silenciosamente tres saltos A2A y cinco llamadas MCP. El usuario nunca ve el gráfico completo, pero la organización sigue siendo responsable del resultado.

Inyección de prompt a través de artefactos y mensajes entre agentes

La inyección no es solo un problema de mensajes de usuario. Un artefacto PDF, una página web obtenida por una herramienta o un mensaje del Agente C puede携带 instrucciones dirigidas al modelo del Agente D. Trate todo el contenido transportado por el protocolo como entrada no confiable en el límite del modelo.

Tarjetas de Agente envenenadas o engañosas

Las descripciones y los nombres de habilidades son superficie de prompt. Una tarjeta que anuncia safe_read_only_analysis (análisis seguro de solo lectura) mientras acepta backends con capacidad de escritura es una capa de ingeniería social, no una garantía técnica.

Modelo de Identidad para Sistemas Multi-Agente

La seguridad del protocolo comienza con tipos de identidad claros y lo que cada uno está permitido probar.

La Tarjeta de Agente de A2A anuncia los esquemas de autenticación compatibles (OAuth 2.0, claves API, mTLS y patrones similares alineados con la práctica de OpenAPI) y las habilidades con requisitos de seguridad opcionales. La tarjeta es metadatos de descubrimiento, no un ancla de confianza. Los clientes obtienen credenciales fuera de banda y las envían en encabezados HTTP estándar en cada solicitud; los servidores deben validar en cada llamada y devolver 401 o 403 cuando falla la autenticación o el ámbito.

Vistas internas vs. externas del mismo agente

Los agentes de producción a menudo publican una Tarjeta de Agente pública con una lista limitada de habilidades y una tarjeta autenticada más rica para llamadores internos. La especificación A2A permite tarjetas extendidas para clientes autenticados. Use esa división deliberadamente: los socios no deben ver habilidades internas, y los orquestadores internos no deben confiar únicamente en el descubrimiento público para la autorización.

Autenticación y Autorización para MCP y A2A

La autenticación responde a quién está llamando. La autorización responde a qué pueden hacer.

Acceso a herramientas MCP

Para cada conexión MCP, defina:

• qué host de agente puede conectarse
• qué herramientas están habilitadas para ese host
• qué usuario del sistema operativo o cuenta de servicio ejecuta efectos secundarios
• si el usuario humano debe aprobar cada llamada mutante

Prefiera las listas de permitidos de herramientas sobre las configuraciones MCP de “conectar todo”. Un agente de codificación no necesita servidores MCP de nómina en el mismo perfil que un bot de soporte público.

Acceso de agente A2A

Para cada relación de pares de agentes, defina:

• qué IDs de agente llamante pueden invocar qué habilidades
• profundidad máxima de delegación
• qué tipos de artefactos pueden cruzar el límite
• si el contexto del usuario debe propagarse como afirmaciones firmadas

Mappe los ámbitos de OAuth (o equivalentes) a habilidades, no a la administración general del agente. El privilegio mínimo en la capa de token supera a la esperanza en la capa de prompt.

Política aplicada por puerta de enlace vs. política por agente

La política por agente funciona cuando un equipo posee todo el gráfico y las liberaciones están coordinadas. La política aplicada por puerta de enlace funciona cuando múltiples equipos, inquilinos o proveedores comparten una red de agentes y necesita un lugar para aplicar listas de permitidos, límites de tasa y auditoría.

Puerta de Enlace A2A como Plano de Control

Una puerta de enlace A2A no es estrictamente requerida por el protocolo, pero se vuelve necesaria cuando el tráfico de agentes necesita gobernanza centralizada.

Una puerta de enlace típicamente maneja:

• terminación de autenticación e intercambio de tokens
• enrutamiento al servicio de agente correcto por habilidad o inquilino
• verificaciones de política antes de que las tareas sean aceptadas o reenviadas
• negociación de versión de protocolo
• limitación de tasa y detección de abuso
• emisión estructurada de auditoría en cada transición de tarea

Cuando una puerta de enlace es excesiva vs. necesaria

Una puerta de enlace a menudo es excesiva para un solo orquestador y dos agentes especialistas en un espacio de nombres de Kubernetes mantenido por un solo equipo. Se vuelve necesaria cuando los socios invocan sus agentes, cuando múltiples unidades de negocio comparten infraestructura, cuando el cumplimiento requiere registro uniforme o cuando no puede confiar en que cada implementación de agente aplique la política correctamente.

Combine una puerta de enlace A2A con una puerta de enlace MCP (o proxy MCP) para que el acceso a las herramientas reciba el mismo tratamiento: identidad, listas de permitidos, controles de salida y auditoría en el límite de la herramienta en lugar de solo en la UI de chat.

Tarjetas de Agente para socios vs. internas

Publique metadatos de descubrimiento diferentes para llamadores externos e internos. Las tarjetas externas exponen habilidades estrechas y autenticación más estricta. Las tarjetas internas pueden listar habilidades de mantenimiento o administración, pero nunca deben ser accesibles sin una autenticación más fuerte que la que implica la tarjeta pública.

Registro y Seguridad de Descubrimiento de Agentes

El descubrimiento es parte de la superficie de ataque. Cualquier persona que controle qué agentes aparecen “disponibles” controla a dónde envían los orquestadores el trabajo.

Registro vs. URL de Tarjeta de Agente bien conocida

Los despliegues pequeños usan URL bien conocidas por agente (/.well-known/agent-card.json). Los despliegues empresariales agregan un registro que indexa IDs de agente, versiones, puntos finales, propietarios y etiquetas de política. El registro es un objeto de política: las entradas deberían registrar qué inquilinos pueden descubrir qué agentes, no solo dónde viven.

Versionado, obsolescencia y propiedad

Los registros del registro necesitan propietarios, historial de cambios y fechas de obsolescencia. Un orquestador que almacena en caché Tarjetas de Agente debe actualizar según el TTL y verificar firmas donde se soporten. Las tarjetas obsoletas son cómo las habilidades retiradas siguen recibiendo tráfico mucho después de que se parchea una vulnerabilidad.

Redes internas empresariales vs. socios externos

Los mallas de agentes internos pueden confiar en mTLS y DNS privado. Los agentes de socios necesitan reglas de federación explícitas, habilidades con ámbito contractual y una inspección de artefactos más fuerte porque no controla su entorno de ejecución.

Delegación a Través de los Límites de los Agentes

La delegación es donde se gana o se pierde la seguridad de A2A. Cuando el Agente A envía una tarea al Agente B, tres preguntas deben tener respuestas claras:

1. ¿De quién se está ejerciendo la autoridad? ¿Del usuario, de la cuenta de servicio de A, o de un token delegado combinado?
2. ¿Qué se le permite hacer a B con esa autoridad? Análisis de solo lectura, o herramientas mutantes en nombre de A?
3. ¿Quién es responsable si B excede el ámbito? A, B, la política de la puerta de enlace, o el humano que aprobó un prompt poco claro?

Propagación de la intención del usuario vs. sobre-delegación

Pase afirmaciones de delegación firmadas que incluyan ID de usuario, ID de tarea original, habilidades permitidas, expiración y conteo máximo de saltos. Los agentes aguas abajo deben rechazar tareas que expandan el ámbito silenciosamente. Si B necesita mayor privilegio que el que tenía A, transicione a input_required (entrada requerida) y obtenga aprobación humana explícita en lugar de actualizar tokens de forma invisible.

Los flujos de aprobación humana en el bucle para delegación riesgosa se cubren en Transmisión A2A y Tareas Asíncronas para Flujos de Trabajo de Agentes de Larga Duración, donde input_required es un estado de tarea de primer nivel en lugar de un error.

Separar el razonamiento de los permisos de ejecución

Un agente puede necesitar acceso de lectura amplio para planificar mientras las herramientas de escritura se encuentran detrás de una aprobación. Divida las credenciales o use perfiles MCP distintos para planificación vs. ejecución para que un error del modelo no pueda mutar la producción inmediatamente.

Trazas de Auditoría y Proveniencia de Respuestas

Si no puede reconstruir una cadena de delegación, no puede explicar un incidente, pasar una auditoría o disputar una anomalía de facturación.

Registre en tres capas:

Puerta de enlace: resultado de autenticación, decisión de política, ID de agente enrutado, ID de tarea, ID de tarea principal, eventos de límite de tasa.

Agente: transiciones de estado de tarea, mensajes enviados/recibidos, invocaciones de modelo/herramienta (argumentos redactados según sea necesario), artefactos creados, delegación hacia afuera.

Servidor MCP: nombre de la herramienta, ID del agente llamante, contexto de usuario, éxito/fracaso, latencia, filas afectadas o IDs de recursos (según la política).

Correlacione con el ID de traza en todas las capas. Observabilidad para Sistemas de LLM cubre backends de instrumentación; este artículo define qué debe capturarse para que esos backends tengan una señal significativa.

La proveniencia de la respuesta final debe responder: qué usuario, qué tarea del orquestador, qué agentes especialistas, qué herramientas, qué artefactos influyeron en el texto que vio el usuario y qué puertas de política se activaron en el camino.

Política de Ejución, Salida y Secretos

Los motores de política de ejecución (OPA, Cedar, servicios de reglas personalizados) evalúan eventos estructurados: “herramienta X con argumentos Y para usuario Z”. Complementan las salvaguardas porque no dependen de que el modelo se comporte bien.

La aprobación humana pertenece en la política de ejecución para acciones irreversibles o de alto costo: pagos, correo electrónico externo, cambios de configuración de producción, concesiones de privilegios.

Los controles de salida limitan a qué dominios pueden llamar los servidores MCP y los agentes. Un agente que puede tanto leer secretos como POST a URLs arbitrarias es una pérdida de datos esperando suceder.

Los secretos nunca deben estar en Tarjetas de Agente o prompts. Los hosts MCP deben inyectar credenciales de corta vida en el momento de la ejecución desde un gestor de secretos. Para cifrado de transporte, gestión de claves y patrones de seguridad de infraestructura básica, consulte Patrones Arquitectónicos para Asegurar Datos.

Los webhooks de notificación push en flujos A2A asíncronos necesitan el mismo rigor: verificar la identidad del remitente, rechazar eventos obsoletos y nunca tratar la carga útil de un webhook como autorización por sí sola.

Arquitectura de Seguridad de Referencia

El siguiente diagrama resume un diseño orientado a la producción para despliegues a escala de A2A fuera, MCP dentro.

El orquestador ve agentes especialistas a través de A2A. Los especialistas ven herramientas a través de MCP. Los usuarios nunca reciben credenciales MCP sin procesar, y los socios nunca reciben superficies de habilidades internas sin revisión de política.

Para conceptos de protocolo (Tarjetas de Agente, tareas, artefactos), consulte ¿Qué es el Protocolo A2A?. Para adopción y marco empresarial, consulte Protocolo A2A de Google en 2026. Para topología cuando muchos agentes se coordinan, consulte Patrones de Orquestación Multi-Agente.

Lista de Verificación de Producción para Seguridad de A2A y MCP

Antes de exponer protocolos de agentes más allá de un sandbox de confianza, verifique:

Identidad y autenticación

• No hay agentes anónimos en rutas de producción
• Cada llamada MCP y A2A autenticada en cada solicitud
• Ámbitos de OAuth o equivalentes mapeados a habilidades/herramientas, no a administración general
• Vistas de Tarjeta de Agente pública vs. autenticada definidas intencionalmente

Delegación y política

• Los tokens de delegación llevan ID de usuario, ID de tarea, ámbito, expiración, límite de saltos
• Los agentes aguas abajo rechazan la expansión de ámbito sin aprobación explícita
• Las herramientas de alto riesgo requieren política de ejecución o aprobación humana
• El razonamiento y la ejecución usan credenciales separadas cuando sea posible

Descubrimiento y registro

• Las entradas del registro de agentes tienen propietarios e historial de versiones
• Tarjetas de Agente actualizadas según TTL; firmas verificadas donde se soporten
• Agentes de socios federados con listas de permitidos de habilidades explícitas

Auditoría y observabilidad

• Las capas de puerta de enlace, agente y MCP emiten eventos de auditoría correlacionados
• Cadenas de delegación registradas con IDs de tarea padre e hija
• Proveniencia de artefactos registrada para respuestas finales
• IDs de traza conectados a backends de observabilidad

Abuso y resiliencia

• Límites de tasa por usuario, agente e inquilino
• Políticas de tiempo de espera en tareas delegadas
• Listas de permitidos de salida en servidores de herramientas
• Secretos en un gestor, no en tarjetas, prompts o repositorios

Conclusión

La interoperabilidad de A2A y MCP es poderosa porque los agentes y herramientas pueden componerse a través de límites de equipos y proveedores, pero ese poder es inseguro sin diseño de identidad, autorización, límites de delegación y auditoría. Las salvaguardas protegen la conversación del modelo; la seguridad del protocolo protege las acciones que los agentes toman en nombre de los usuarios.

Trate las Tarjetas de Agente como anuncios, la delegación como un contrato firmado, las herramientas MCP como ejecución de código privilegiado y los registros de auditoría como la cadena de evidencia que necesitará cuando ocurra algo interesante a las 2 a. m.

Construya la puerta de enlace cuando la gobernanza necesite un solo punto de control. Divida las credenciales antes de dividir los agentes. Registre cada salto para que la respuesta “el modelo decidió” nunca sea el informe de incidente final.

Preguntas Frecuentes

¿Cuál es la diferencia entre las salvaguardas de LLM y la seguridad de agentes A2A MCP? Las salvaguardas restringen la entrada y salida del modelo. La seguridad del protocolo restringe quién puede invocar herramientas, delegar tareas y actuar en nombre de quién a través de MCP y A2A con identidad, autorización y trazas de auditoría.

¿Cómo debería funcionar la identidad del agente en un despliegue A2A? Separe las identidades humana, de servicio de agente y de tarea. Valide credenciales en cada solicitud, use tokens con ámbito y trate las Tarjetas de Agente como metadatos de descubrimiento en lugar de prueba de confianza.

¿Qué es el problema del delegado confundido en sistemas multi-agente? Ocurre cuando un agente o herramienta privilegiado realiza una acción sensible porque un llamante con menos privilegios se coló instrucciones a través de delegación o artefactos. Aplique el ámbito en cada salto.

¿Necesita una puerta de enlace A2A en producción? Los despliegues internos de un solo equipo pueden aplicar política por agente. Las redes multi-inquilino, multi-proveedor o orientadas a socios generalmente necesitan una puerta de enlace para autenticación centralizada, enrutamiento, límites de tasa y auditoría.

¿Qué debe contener un registro de auditoría A2A MCP? ID de usuario, ID de agente, ID de tarea, ID de tarea principal, llamadas a herramientas, decisiones de política, artefactos y marcas de tiempo correlacionadas con IDs de traza a través de las capas de puerta de enlace, agente y MCP.

Fuentes

• Protocolo A2A – Temas de seguridad listos para empresa: https://github.com/a2aproject/A2A/blob/main/docs/topics/enterprise-ready.md
• Protocolo A2A – Resumen de especificación: https://a2a-protocol.org/latest/specification/
• Protocolo A2A – Seguridad de transmisión y notificación push: https://a2a-protocol.org/latest/topics/streaming-and-async/