Mecanismos de seguridad A2A: el sistema de control de acceso para la confianza entre agentes

Cuando dos IAs se “llaman” entre sí, ¿qué es lo más temible? No es que no dejen de hablar, sino que un extraño se haga pasar por conocido para tocar la puerta.

Principios de diseño de seguridad: primero cerrar la puerta, luego abrirla

Imagina que te mudas a una casa nueva: lo primero no es colgar las cortinas, sino cambiar la cerradura. Los diseñadores del protocolo A2A pensaron igual: seguro por defecto, y cada flexibilización requiere una acción explícita. Este mecanismo funciona como un sistema completo de control de acceso: cerradura (token), tarjeta de acceso (clave por par), mirilla (identificación) y cámaras de vigilancia (registros de auditoría). En la plataforma de mensajería Hermes, la función A2A se ofrece como plugin, pero los valores de seguridad por defecto no se negocian: sin token configurado, solo escucha en 127.0.0.1 — como si la puerta estuviera cerrada con llave y la llave solo estuviera en tus manos.

Las cuatro líneas de defensa en detalle

Primera línea: enlace local + token (la cerradura)

Por defecto, A2A solo escucha en la máquina local; el exterior ni siquiera puede tocar la puerta. Para ofrecer servicios hacia afuera, deben cumplirse dos condiciones a la vez: configurar A2A_HOST para exponer la dirección y configurar un bearer token. Es como si no solo abrieras la ventana, sino que además pusieras un cactus con espinas en el alféizar — ambas cosas son imprescindibles.

Segunda línea: clave independiente por par (la tarjeta de acceso)

Cada par tiene su propio token exclusivo, configurado mediante A2A_PEER_TOKENS="alice:tok1,bob:tok2". No es una llave maestra que abre todas las puertas, sino una tarjeta de acceso individual para cada visitante. La identidad autenticada impulsa la limitación de tasa, las listas de confianza y la auditoría — quién pasó la tarjeta, cuántas veces y cuándo, todo queda registrado.

Tercera línea: filtrado de inyección + desinfección (el arco de seguridad)

El texto entrante se filtra y se marca como “entrada de par no confiable”; los pares remotos no pueden invocar comandos de barra del operador. Es como el control de seguridad del aeropuerto: los líquidos del equipaje deben sacarse y revisarse por separado. En las respuestas salientes, las cadenas con forma de credencial (API keys, JWT, tokens) se borran automáticamente — como si las cartas que envías tuvieran tachado automáticamente el número de identificación del destinatario.

Cuarta línea: registros de auditoría + prevención de bucles (las cámaras de vigilancia)

Cada intercambio se añade a ~/.hermes/a2a_audit.jsonl, como si tuvieras una cámara de vigilancia 24 horas en la puerta. El límite de rondas anti-bucle es como el interfono del vecino: si dos IAs no dejan de hablar, el sistema corta automáticamente.

Historias reales de ataques: 3 problemas descubiertos y corregidos por la comunidad

Historia uno: bypass de SSRF (#78298) — engañar a la cerradura con un “código numérico secreto”

Un atacante descubrió que la verificación de seguridad de las URLs de callback usaba coincidencia de prefijos de cadena para el nombre de host, por ejemplo, comprobaba si empezaba con 127.. Pero las direcciones IP tienen una forma de “ortografía entera” — 2130706433 es otra forma de escribir 127.0.0.1. Es como escribir el número de la casa en código Morse: el portero no lo reconoce y deja pasar. Solución: primero resolver el host del callback a una IP estándar y luego evaluar — como si el portero tradujera cualquier formato de dirección al número de casa estándar antes de comparar.

Historia dos: colapso de identidad tras proxy inverso (#80534/#80779) — todos se convierten en la misma persona

Cuando se despliega detrás de nginx o K8s, el plugin A2A deduce la identidad del llamante a partir de la dirección del socket. Pero el proxy se interpone, y todos los pares aparecen con la misma IP — la del proxy. Es como la garita del conserje en un edificio: todos los visitantes quedan registrados como “firmado por el conserje”. La limitación de tasa comparte un solo cubo (uno ocupado perjudica a todos), la lista blanca de confianza solo puede contener la dirección del proxy, y la auditoría no ve al llamante real. Solución: deducir la identidad real desde X-Forwarded-For, pero solo confiar en ella cuando se está “detrás de un proxy confiable”.

Historia tres: punto ciego de auditoría (#81003/#81042) — los golpes rechazados en la puerta no quedan registrados

Los registros de auditoría solo guardaban el tráfico aceptado. Las solicitudes con 401 (token inválido) y 403 (no confiable) no generaban registros. Es como si la cámara de vigilancia solo grabara a quienes entran sin problemas, pero no capturara al ladrón forzando la cerradura. Ataques de relleno de credenciales, sondeos con tokens revocados, intentos de movimiento lateral — estos comportamientos son precisamente los que la auditoría más necesita capturar. Solución: todos los rechazos de autenticación también se añaden al registro de auditoría de solo anexión, con campo decision + código de estado HTTP + IP del llamante.

Qué significa para los usuarios

La lógica central de este mecanismo es: la seguridad no es una solución posterior, sino un estado por defecto. Como usuario de Hermes, no necesitas ser experto en seguridad para obtener protección básica — las cuatro líneas de defensa actúan automáticamente. Más importante aún, la comunidad refuerza continuamente el sistema ante ataques reales: desde el bypass de SSRF hasta el colapso de identidad tras proxy inverso, y el punto ciego de auditoría, cada problema corresponde a un escenario real. El protocolo A2A es como un castillo que se fortifica constantemente: cada ladrillo ha pasado la prueba del combate real. La próxima vez que tus dos agentes se “llamen” entre sí, no solo habrá cerradura, tarjeta de acceso, arco de seguridad y cámaras de vigilancia entre ellos, sino también un grupo de guardias vigilando los registros.