La Tarjeta de tu Agente A2A necesita una URL pública: Probando notificaciones push de A2A en localhost

El protocolo Agent2Agent (A2A) creció rápidamente. Google lo anunció en abril de 2025, la Linux Foundation se hizo cargo en junio de 2025, y la especificación estable v1.0 se publicó el 12 de marzo de 2026. En agosto de 2026 se convirtió en un proyecto alojado de la Agentic AI Foundation (AAIF). Dos de sus bloques de construcción son importantes para el desarrollo local. Las notificaciones push son simples webhooks: el servidor del agente envía un POST HTTP a una URL que registró el cliente. La tarjeta del agente es un documento JSON servido desde una ruta bien conocida.

Ambos topan con la misma barrera en un portátil. Los pares remotos no pueden alcanzar localhost, y un servidor de agente bien construido podría negarse a hacer POST a ello. Esta guía explica por qué, cómo probar las notificaciones push de A2A desde tu máquina a través de un túnel público y cómo registrar webhooks sin abrir un agujero SSRF.

Se trata de callbacks de agente a agente y del registro seguro de webhooks. Deliberadamente omite el descubrimiento OAuth y los flujos de servidor de autorización.

Dónde está A2A en noviembre de 2026

• v1.0 se lanzó el 12 de marzo de 2026. El blog propio del proyecto y la guía de Turing Post lo sitúan en esa fecha, y Turing Post señala un parche v1.0.1 en mayo. La versión 1.0 fue la primera especificación estable y lista para producción. Su definición protobuf, a2a.proto, es la fuente normativa y las formas JSON, gRPC y REST se generan a partir de ella.
• La gobernanza se movió en dos pasos. Google donó A2A a la Linux Foundation en junio de 2025. El 17 de agosto de 2026 se anunció como un proyecto alojado de la AAIF, la entidad de la Linux Foundation que se creó en diciembre de 2025 alrededor de MCP, goose y AGENTS.md. El anuncio del proyecto A2A se fecha 27 de agosto de 2026 y describe A2A como un proyecto de la Etapa de Crecimiento de la AAIF. La cobertura de prensa sobre el movimiento abarcó del 17 al 20 de agosto. No hubo cambio de control. Google ya había donado la especificación, y cada proyecto AAIF mantiene sus propios mantenedores y calendario de lanzamientos.
• El ecosistema es amplio. La Linux Foundation informó más de 150 organizaciones de apoyo al cumplir un año desde el inicio del proyecto, en abril de 2026. Existen SDK oficiales para Python, Go, JavaScript, Java, .NET y Rust. El SDK de JavaScript (@a2a-js/sdk) alcanzó la disponibilidad general 1.0.0 el 22 de julio de 2026, con compatibilidad opt-in v0.3 para migraciones escalonadas.
• v1.0 define tres enlaces de protocolo estándar: JSON-RPC 2.0 sobre HTTP(S), gRPC y HTTP+JSON/REST.

La idea práctica es que la especificación es lo suficientemente estable como para invertir en herramientas y trabajo de seguridad. Pero muchos agentes desplegados todavía presentan formas de tarjeta previas a 1.0, así que verifica la versión de cada par antes de probarla.

Dos URLs públicas, no una

El título dice “tu tarjeta de agente necesita una URL pública.” Eso es verdad, pero solo la mitad de una prueba local de A2A la necesita, y mezclar las dos mitades provoca la mayor parte de la confusión.

1. La URL de la tarjeta del agente (la dirección del servidor). Los servidores A2A publican su tarjeta en https://{server_domain}/.well-known/agent-card.json. La ruta well-known sigue RFC 8615. Los servidores antiguos previos a la 1.0 solían usar /.well-known/agent.json, y herramientas como a2aops retroceden a esa ruta heredada cuando verifican una tarjeta.

La tarjeta enumera los endpoints que los clientes deben llamar en supportedInterfaces. Es un arreglo ordenado en el que la primera entrada es la interfaz preferida. Cada entrada lleva un url, un protocolBinding (JSONRPC, GRPC o HTTP+JSON) y un protocolVersion, con un tenant opcional. La especificación indica que una URL de interfaz debe ser una URL HTTPS absoluta en producción.

Si tu servidor funciona en local y un cliente remoto necesita alcanzarlo, como un orquestador alojado, el agente de un compañero o una demostración en la nube, la tarjeta y sus URLs de interfaz deben ser resolubles públicamente.

2. La URL del webhook (la dirección del cliente). Las notificaciones push fluyen en sentido contrario. El cliente registra un webhook y el servidor realiza un POST a él. Si estás desarrollando el cliente localmente y probando contra un agente remoto, tu webhook necesita la dirección pública.

Si ejecutas dos agentes locales que se comunican desde redes distintas, necesitas ambas: dos nombres de host públicos estables.

Cómo funcionan las notificaciones push de A2A

Las notificaciones push existen para tareas de larga duración (minutos, horas o días) y para clientes que no pueden mantener una conexión de streaming abierta, como apps móviles o funciones sin servidor. El agente anuncia soporte con capabilities.pushNotifications: true en su tarjeta. Si el flag es falso o está ausente, las operaciones de configuración de push deben devolver PushNotificationNotSupportedError.

1. Registrar una configuración. El cliente envía un TaskPushNotificationConfig ya sea en línea en la petición SendMessage (bajo configuration, con el ID de tarea en blanco) o por separado a través de la operación de creación en una tarea existente. La especificación v1.0 define crear, obtener, listar y eliminar. En JSON-RPC son CreateTaskPushNotificationConfig, GetTaskPushNotificationConfig, ListTaskPushNotificationConfigs y DeleteTaskPushNotificationConfig. En REST residen en /tasks/{id}/pushNotificationConfigs.
2. Qué transporta la configuración. Contiene una url de webhook, un token opcional para validación del cliente y detalles opcionales de authentication (scheme y credentials) que indican al servidor cómo autenticar contra tu webhook. También lleva un id opcional y el taskId.
3. El servidor envía POST ante cambios de estado. El cuerpo es un StreamResponse, la misma estructura usada en streaming. Contiene exactamente uno de task, message, statusUpdate o artifactUpdate.
4. Tu receptor lo verifica. El ejemplo práctico de la especificación muestra que el servidor envía un encabezado Authorization construido a partir de la configuración de authentication, además de X-A2A-Notification-Token que lleva el token que proporcionaste.

La especificación no se pone de acuerdo en cada detalle, así que construye el receptor de forma defensiva:

• El texto normativo no nombra un encabezado de token. El ejemplo práctico usa X-A2A-Notification-Token. Otras implementaciones difieren: la crate Rust a2a-protocol-server envía tanto X-A2A-Notification-Token como un A2A-Notification-Token sin prefijo, así que acepta cualquiera.
• Los ejemplos de la especificación muestran Content-Type del webhook como application/a2a+json en un lugar y application/json en otro. Parsea el cuerpo JSON sin insistir en un único tipo de medio.

Una registración se parece a esto. Es simplificada, así que confirma la distribución exacta de campos frente a a2a.proto para tu versión de SDK:

{
  "jsonrpc": "2.0",
  "id": "1",
  "method": "CreateTaskPushNotificationConfig",
  "params": {
    "taskId": "task-123",
    "url": "https://a2a-client-dev.example.com/webhooks/a2a",
    "token": "per-task-secret-value",
    "authentication": { "scheme": "Bearer", "credentials": "webhook-credential" }
  }
}

Envía la cabecera A2A-Version: 1.0 con cada solicitud. La especificación exige que los clientes la envíen para que un agente que actualice más tarde no cambie el comportamiento de forma silenciosa.

Un fragmento mínimo de tarjeta estilo v1.0 muestra dónde vive la dirección pública. Una tarjeta completa también requiere defaultInputModes, defaultOutputModes y skills:

{
  "name": "Flight Booking Agent",
  "description": "Handles flight reservations.",
  "version": "1.0.0",
  "supportedInterfaces": [
    {
      "url": "https://a2a-agent-dev.example.com/a2a",
      "protocolBinding": "JSONRPC",
      "protocolVersion": "1.0"
    }
  ],
  "capabilities": { "streaming": true, "pushNotifications": true }
}

Qué pide la especificación a quienes envían y reciben

• Los servidores deben intentar la entrega al menos una vez y pueden reintentarlo con retroceso exponencial. Deben usar un timeout de webhook de aproximadamente 10 a 30 segundos y pueden parar tras fallos repetidos.
• Los receptores deben responder con un estado 2xx para reconocer la entrega, deben procesar las notificaciones de forma idempotente porque pueden ocurrir duplicados, y deben verificar que el task ID coincide con una tarea que esperan.
• La guía asíncrona de A2A dice que tras verificar la autenticidad de una notificación, un cliente normalmente llama a GetTask con el ID de la notificación para obtener el estado completo y actual. Trata la carga útil como un disparador y vuelve a consultar la tarea antes de actuar en algo importante.

Por qué localhost rompe las notificaciones push de A2A

Tres fallos separados se esconden tras “funciona en mi máquina.”

La tarjeta anuncia una dirección a la que nadie más puede acceder. Muchos frameworks generan la tarjeta a partir de la dirección de enlace, por lo que la tarjeta dice http://localhost:8000/a2a. Un cliente remoto recupera la tarjeta (si es que puede alcanzarla), y luego sigue supportedInterfaces[0].url hacia su propia interfaz loopback. La solución es establecer explícitamente la URL base pública del servidor para que la tarjeta refleje el nombre de host del túnel.

El agente no puede alcanzar tu webhook. Si tu webhook es http://localhost:9000/hook, el agente remoto lo resuelve como él mismo, y no llega nada.

Un servidor bien construido podría negarse a intentarlo. La especificación dice que los servidores no deben hacer POST ciegamente a cualquier URL proporcionada por el cliente, ya que eso abre ataques SSRF y de amplificación DDoS. Las implementaciones reales responden de maneras distintas:

• La crate Rust a2a-protocol-server (0.15.0) valida las URLs de webhook al crear la configuración y de nuevo al delivery. Rechaza destinos de loopback, privados y de enlace local, así como localhost, .local y .internal. Su escape hatch allow_private_urls() está documentado como prueba y como desactivación de la protección SSRF.
• Una PR contra el SDK oficial de Python (#1164) describe el problema de forma clara. El remitente usó push_info.url tal como se proveyó, sin comprobaciones. El PR añade validación en el momento del despacho del esquema, resolución DNS y destinos solo públicos, con una opción allow_private_push_urls para operadores cuyos webhooks viven en redes privadas. Un PR superpuesto (#1169) cubre lo mismo, y no pude confirmar si alguno se ha fusionado. Verifica la versión de SDK que estás usando.

Así que si localhost funciona como webhook depende del SDK y de la versión de tu servidor. Donde funciona, es porque la protección está ausente. Deshabilitar la protección para que 127.0.0.1 pase las pruebas implica una ruta de código que nunca ejecutarás en producción. Un túnel público le da a tu webhook una dirección HTTPS real, global y enrutable que pasa la misma validación que un endpoint de producción.

El trasfondo de seguridad: SSRF en webhooks

El webhook es, por definición, entrada influenciada por el atacante. Quien registre una configuración de push decide a dónde envía tu servidor las solicitudes HTTP. La guía de seguridad de A2A de Tyk (junio de 2026) llama a la URL del webhook su propia superficie de ataque, con SSRF si los destinos salientes no están en la lista permitida y suplantación si el receptor no autentica las notificaciones.

La documentación de A2A enumera mitigaciones para los servidores: listas blancas de dominios confiables, verificación de propiedad como desafío-respuesta y controles de red como firewalls de salida. Para los receptores dice que el endpoint debe verificar que las notificaciones realmente provienen del servidor legítimo, usando firmas, tokens o el token registrado. También dice que las notificaciones deben traer una marca de tiempo para rechazar las obsoletas, y recomienda IDs únicos para eventos críticos para evitar repeticiones. También describe un flujo opcional JWT más JWKS para verificación asimétrica.

El advisory de Apache Camel muestra cómo un validador puede fallar:

• CVE-2026-71569 (Apache Camel, publicado 29 de octubre de 2026). El componente camel-a2a clasificó hosts en dos lugares que no coincidían. Un host escrito como literal IP se comparó con prefijos de cadena que incluían el rango unique-local fc00::/7. Un host dado como nombre se resolvió y se verificó con predicados JDK (isLoopbackAddress, isSiteLocalAddress, etc.), y esas comprobaciones no cubren fc00::/7. Un nombre que resolvió a fc00::/7 pasó una guardia que rechazó el literal idéntico.
  • El despachador también envió cualquier encabezado Authorization configurado a esa dirección. El atacante suministra el esquema y las credenciales, por lo que esto no es una fuga de secretos.
  • Afecta 4.21.0 hasta 4.22.2. Las correcciones llegan en 4.22.2 y 4.23.0, y la línea 4.21.x llega al fin de vida sin corrección. El componente fue introducido en 4.21.0 y figura como Vista previa.
  • Está calificado como Medio (CVSS 3.1 puntuación 4.8). La solicitud es ciega, ya que la respuesta no se devuelve al llamante. La explotación también necesita que el nombre se resuelva a fc00::/7, un servicio HTTPS que escuche ahí y un apretón TLS exitoso para ese nombre.
  • La validación previa de cadenas también era incorrecta en la dirección opuesta. Coincidía la cadena de host en crudo sin confirmar primero que era un literal IP, por lo que nombres legítimos que comienzan con fc o fd, como fcm.googleapis.com, fueron rechazados.
• El SDK oficial de Python. PR #1164 señala dos riesgos residuales. El rebinding DNS entre la validación y el POST sigue siendo posible, porque la búsqueda y la conexión resuelven el nombre por separado. Un revisor también señaló que los redireccionamientos no se vuelven a validar, por lo que el cliente http debe mantener follow_redirects=False, que es el valor por defecto de httpx.

Una checklist de registro de webhook SSRF seguro

Si construyes u operas un servidor A2A, valida en capas:

1. Solo HTTPS. Rechaza otros esquemas y URLs que lleven credenciales embebidas. Algunos guardas SDK también permiten http. Asegúrate de restringirlo a HTTPS en producción.
2. Restringe puertos. Permite 443 a menos de que tengas una razón documentada.
3. Resolver, luego clasificar cada dirección. Una mala resolución falla toda la URL. Resolver también detecta decimales, hex y octales en el host como 2130706433, que una coincidencia de cadenas podría pasar por alto. Desenrolla IPv4-mapped IPv6, NAT64 y 6to4 antes de clasificarlos, y asegúrate de cubrir fc00::/7 y 100.64.0.0/10 como direcciones locales únicas.
4. Validar en registro y en entrega. Las configuraciones pueden llegar por varios caminos (inline en una solicitud de envío o mediante la operación dedicada), y DNS puede cambiar entre los dos momentos.
5. Cerrar la ventana de rebinding. Donde tu cliente HTTP lo permita, conéctate a la dirección que validaste manteniendo el hostname original para TLS y el encabezado Host. La crate Rust toma una ruta diferente para targets https://. No fija la IP, y argumenta que un rebind a una dirección privada rompe el handshake TLS porque el atacante no puede presentar un certificado válido para tu hostname. Elige un enfoque a propósito.
6. Nunca sigas redirecciones en la entrega de push.
7. Verificar la propiedad con un desafío antes de enviar eventos reales.
8. No adjuntar credenciales a destinos no validados. Añade un proxy de salida o una política de red como defensa en profundidad.
9. Rechazar inyección de encabezados. Rechaza caracteres CR o LF en los valores de token y authentication antes de ponerlos en encabezados.

Un punto de partida en Python para los pasos 1 a 3 sigue. Lo ejecuté con Python 3.13. Rechaza destino de loopback, privado, enlace local, CGNAT y destinos locale-únicos, hosts codificados como enteros, localhost, IPv4-mapped e IPv4-compatible IPv6, NAT64 y direcciones 6to4 que envuelven IPv4 privado, puertos erróneos y credenciales embebidas. Acepta hosts públicos. Las reglas is_global de Python han cambiado entre versiones, así que vuelve a probar con tu propia versión:

import ipaddress
import socket
from urllib.parse import urlsplit

ALLOWED_PORTS = {443}
NAT64 = ipaddress.ip_network("64:ff9b::/96")


def unwrap(ip):
    """Return the IPv4 hidden inside an IPv6 address, if there is one."""
    if isinstance(ip, ipaddress.IPv6Address):
        if ip.ipv4_mapped:                      # ::ffff:a.b.c.d
            return ip.ipv4_mapped
        if ip in NAT64:                         # 64:ff9b::/96
            return ipaddress.IPv4Address(int(ip)  & 0xFFFFFFFF)
        if ip.sixtofour:                        # 2002::/16
            return ip.sixtofour
        if int(ip)  32 == 0 and int(ip)  1:  # deprecated ::a.b.c.d
            return ipaddress.IPv4Address(int(ip)  0xFFFFFFFF)
    return ip


def check_webhook_url(url: str) -> list[str]:
    parts = urlsplit(url)
    if parts.scheme != "https" or not parts.hostname:
        raise ValueError("webhook must be an https URL with a host")
    if parts.username or parts.password:
        raise ValueError("credentials in the URL are not allowed")
    try:
        port = parts.port or 443
    except ValueError:
        raise ValueError("invalid port")
    if port not in ALLOWED_PORTS:
        raise ValueError("port not allowed")

    public_ips = []
    for *_, sockaddr in socket.getaddrinfo(parts.hostname, port, type=socket.SOCK_STREAM):
        ip = ipaddress.ip_address(sockaddr[0].split("%")[0])
        # is_global rejects private, loopback, link-local, unique-local and CGNAT.
        if not unwrap(ip).is_global:
            raise ValueError(f"{ip} is not a public address")
        public_ips.append(str(ip))
    return public_ips  # connect to one of these, not to a fresh DNS lookup

En el lado receptor, compara el token en tiempo constante, acepta cualquiera de las dos variantes de cabecera, responde rápido y obtiene el estado por separado. Probé este handler de FastAPI. Devuelve 401 por token ausente o erróneo y 200 para cualquiera de los nombres de encabezado:

import hmac
import os

from fastapi import FastAPI, Header, HTTPException, Request

app = FastAPI()
EXPECTED = os.environ["A2A_WEBHOOK_TOKEN"]


@app.post("/webhooks/a2a")
async def a2a_webhook(
    request: Request,
    x_a2a_notification_token: str = Header(default=""),
    a2a_notification_token: str = Header(default=""),
):
    token = x_a2a_notification_token or a2a_notification_token
    if not hmac.compare_digest(token.encode(), EXPECTED.encode()):
        raise HTTPException(status_code=401)
    event = await request.json()  # accepts application/json or application/a2a+json
    # queue event; re-fetch the task with GetTask before acting on it
    return {"received": True}

Si tu servidor también envía un encabezado Authorization desde authentication, verifica también eso. El token por sí solo demuestra solo que el emisor conocía un secreto por tarea.

Probando notificaciones push de A2A en localhost con un túnel

Un túnel le da a tu puerto local un hostname HTTPS público, para que puedas ejecutar el flujo real. Cualquier herramienta de túnel sirve. Las propiedades que importan son HTTPS, un hostname estable, y soporte para solicitudes POST simples y no interactivas.

Paso 1: reserva un hostname estable. URLs aleatorias por sesión rompen las pruebas de A2A. Los clientes almacenan en caché las tarjetas, y la especificación indica que los servidores deben enviar cabeceras Cache-Control y ETag, y que los clientes deben respetarlas. Las configuraciones de push registradas contienen tu URL de webhook. Cuando el hostname cambia, apuntan a nada.

Una túnel desechable sirve para una primera prueba rápida. cloudflared tunnel --url http://localhost:8000 genera una URL aleatoria trycloudflare.com sin cuenta. Cloudflare documenta varios límites para estos Quick Tunnels:

• No hay garantía de disponibilidad.
• Cada túnel admite hasta 200 solicitudes en curso, y las solicitudes extra devuelven un 429.
• El hostname cambia cada vez.
• Los Server-Sent Events no están soportados. Las operaciones de streaming de A2A (SendStreamingMessage, SubscribeToTask) usan SSE, por lo que un Quick Tunnel puede transportar webhooks de push y llamadas de tipo petición-respuesta, pero no pruebas de streaming.
• Quick Tunnels no funcionan si existe un config.yaml en ~/.cloudflared.
• Quick Tunnels ahora tienen un flag opcional --allowed-mail que protege la URL con un PIN de un solo uso por correo. Cloudflare dice que necesita una sesión de navegador interactiva y no admite clientes no interactivos. Un agente que haga POST a tu webhook no puede completar eso, así que déjalo desactivado para callbacks de A2A.

Para cualquier prueba iterativa, usa un túnel con nombre o el subdominio reservado por otro proveedor.

Paso 2: Haz que la tarjeta indique la dirección pública. Configura la URL base pública de tu agente a partir de una variable de entorno y reconstruye la tarjeta desde esa base. Luego verifica desde fuera de tu red:

curl -s https://a2a-agent-dev.example.com/.well-known/agent-card.json | jq '.supportedInterfaces'

Deberías ver el hostname del túnel, no localhost. Si un par está usando una tarjeta anterior a 1.0, a2aops compat <base-url> imprime una lista de migración de v0.x a v1.0. Es una herramienta beta de terceros, así que trata su salida como una guía.

Paso 3: Tunnel del receptor de webhook. Ejecuta el receptor anterior en su propio puerto con su propio hostname público, o uno enrutado por ruta.

Paso 4: Registra y dispara. Crea la configuración de push para una tarea de larga duración, luego inicia la tarea. Observa el inspector de solicitudes del túnel (muchas herramientas lo ofrecen) para ver los encabezados y el cuerpo exactos que envía el servidor.

Paso 5: Realiza las pruebas negativas. Importan tanto como el camino feliz:

• Registra https://127.0.0.1/hook y https://localhost/hook. Un servidor endurecido debe rechazar ambas.
• Registra un hostname que controles que resuelva a una dirección privada, y un host de bucle decimal como https://2130706433/hook. Ambos deben ser rechazados.
• Envía una solicitud con un token incorrecto o ausente. Tu receptor debe devolver 401.
• Repite una notificación capturada anterior.
• Tu receptor debe rechazarla como obsoleta o duplicada.
• Devuelve un 5xx desde el receptor una vez y confirma que el servidor reintenta. Después devuelve un 401 y verifica si se detiene. El comportamiento de reintentos varía, y la crate Rust reintenta solo 408, 429 y respuestas 5xx.

Errores comunes

• Desalineación entre la tarjeta y el túnel. Reinicias el túnel, el hostname cambia, y la tarjeta (y cada configuración de push almacenada) aún anuncia la vieja dirección.
• Tarjetas previas a 1.0. Un par puede servir /.well-known/agent.json o un esquema más antiguo. La v1.0 introdujo cambios importantes, incluyendo una estructura Part unificada, nombres de métodos y nuevos campos de interfaz de tarjeta.
• Túnel público, agente público. Un túnel expone tu servidor de desarrollo a Internet. No pongas secretos en la tarjeta, no pongas datos de producción detrás de un agente de desarrollo y cierra el túnel cuando termines.
• Manejadores de webhook lentos. Confirman rápido y procesan de forma asíncrona. la crate Rust por defecto establece un timeout de 10 segundos y la especificación recomienda 10 a 30 segundos. Un manejador lento invita a reintentos y entregas duplicadas.
• Tokens compartidos. Usa un token único y de un solo uso por configuración de push.

FAQ

¿La tarjeta de A2A tiene que estar en una URL pública?
Sí, para el descubrimiento por clientes remotos. Se sirve en /.well-known/agent-card.json en el dominio del agente, y las URLs de interfaz deben ser alcanzables por quien te llame. Las tarjetas también pueden obtenerse de un registro o configurarse directamente.

¿Por qué mi servidor A2A rechaza el webhook de localhost?
Casi con seguridad es por la protección SSRF. Los servidores endurecidos bloquean por defecto destinos privados, loopback y de enlace local. Usa un túnel HTTPS público en lugar de desactivar la protección.

¿Qué cabecera transporta el token de notificación push de A2A?
El ejemplo práctico de la especificación usa X-A2A-Notification-Token, obtenido del token que proporcionaste en el registro. El texto normativo no nombra una cabecera, y algunas implementaciones también envían A2A-Notification-Token, así que acepta ambas.

¿Puedo probar el streaming de A2A a través de un Cloudflare Quick Tunnel?
No. Cloudflare dice que los Quick Tunnels no soportan Server-Sent Events, que es lo que usa el streaming de A2A. Los webhooks de push funcionan bien sobre uno.

¿Es A2A lo bastante estable para construir sobre él?
La v1.0 es la especificación estable actual, gobernada por la Linux Foundation y alojada por la AAIF desde agosto de 2026. Los SDKs e integraciones siguen madurando, así que prueba el soporte de versiones, capacidades opcionales y autenticación de extremo a extremo con cada par.

Conclusiones clave

• Una prueba local de A2A puede necesitar dos direcciones públicas: la URL de interfaz de la tarjeta para el servidor y la URL de webhook para el cliente.
• Si un webhook en localhost funciona o no, depende del SDK de tu servidor. Los servidores endurecidos rechazan intencionadamente objetivos privados y un túnel prueba el camino real donde desactivar la protección no funciona.
• Registrar un webhook es una superficie SSRF. Resuelve y clasifica cada dirección con un único clasificador, valida en el registro y en la entrega, decide cómo cerrarás la ventana de rebinding y rechaza redirecciones.
• Usa un hostname estable del túnel, autentica cada notificación, trata la carga útil como un disparador para llamar a GetTask y realiza las pruebas negativas.

Fuentes

• A2A Protocol Specification v1.0.0
• Streaming and Asynchronous Operations (A2A docs)
• A New Chapter for A2A: Joining the Agentic AI Foundation (A2A blog, Aug 27, 2026)
• A2A Protocol Surpasses 150 Organizations (Linux Foundation, Apr 9, 2026)
• A2A Joins AAIF: The 2026 Agent Protocol Consolidation (NerdLevelTech)
• Agent2Agent (A2A) Protocol: v1.0 Guide for 2026 (Turing Post)
• A2A security: The developer’s complete guide (Tyk)
• CVE-2026-71569, Apache Camel A2A webhook SSRF y el Apache Camel advisory
• a2a-python PR #1164, validate push-notification URLs before dispatch
• a2a-protocol-server push sender (docs.rs)
• a2a-js v1.0.0 release
• a2aops on PyPI
• Cloudflare Quick Tunnels documentation