MCP y A2A son protocolos, no gobernanza
El mes pasado conectaste un servidor MCP. Puede que tres. Tus agentes ahora pueden llegar a tu sistema de seguimiento de incidencias, tu base de datos, tu pipeline de despliegue — y en algún rincón de tu mente está la pregunta que todavía no has podido responder con evidencia: ¿demuestra algo de esto que tu código fuente y tus datos de negocio permanecen privados, y que lo que llama a tus herramientas es lo que tú aprobaste? Esta publicación trata sobre por qué los propios protocolos nunca responderán esa pregunta por ti — porque en 2026 los investigadores midieron lo que los protocolos realmente garantizan, y la respuesta es: entrega de mensajes, no gobernanza.
La cintura estrecha, otra vez
El Model Context Protocol estandariza cómo una aplicación impulsada por un modelo llega a las herramientas y al contexto (especificación). El protocolo Agent2Agent, un proyecto de la Linux Foundation aportado por Google, estandariza cómo se comunican entre sí agentes independientes (a2a-protocol.org). Ambos son genuinamente útiles — de la misma manera en que IP fue genuinamente útil. Internet escaló porque su contrato intermedio se mantuvo pequeño, y el ecosistema de agentes está redescubriendo esa forma. El libro blanco de Koinessa llama a esto la cintura estrecha, y la publicación complementaria sobre las lecciones de cincuenta años de sistemas explica por qué el patrón sigue repitiéndose.
Pero internet estandarizó la entrega de paquetes sin resolver la identidad, el fraude ni la confianza. Los protocolos de agentes están repitiendo ese patrón casi exactamente.
Empecemos por lo que las especificaciones realmente se comprometen a cumplir. El marco de autorización HTTP de MCP, en la revisión del 2026-07-28, se basa en OAuth 2.1 — y es opcional a nivel de protocolo (especificación de autorización). Un despliegue MCP conforme puede exponer herramientas sin ninguna capa de autorización y seguir siendo conforme. Las Agent Cards de A2A 1.0 pueden llevar JSON Web Signatures; cuando un cliente verifica una firma contra una clave de confianza, se establece la integridad de la tarjeta y el origen del proveedor (sección 8.4 de la especificación). Nótense las palabras que sostienen todo el peso: puede, cuando se verifica, contra una clave de confianza. La firma es opcional, el campo de firmas no es obligatorio, y nada en la especificación constituye un sistema universal de identidad de agentes. Una tarjeta firmada te dice que la tarjeta no fue manipulada y que provino de quien tenga esa clave. No te dice si deberías confiar en esa clave, qué puede hacer el agente en tu nombre, ni cómo revocar ese permiso.
Qué aspecto tienen en realidad 7,973 servidores activos
Esa brecha entre «el protocolo admite autenticación» y «los despliegues la aplican» no es hipotética. El primer estudio de medición sobre la seguridad de la autenticación en el ecosistema MCP remoto identificó 7,973 servidores MCP remotos activos y encontró que el 40.55% expone herramientas sin ninguna autenticación (arXiv:2605.22333).
El hallazgo más interesante es lo que ocurrió en la mitad autenticada. OAuth es el mecanismo de autorización dominante para los servidores MCP remotos, pero los despliegues de MCP difieren de OAuth tradicional en tres aspectos: entornos de cliente abiertos, registro dinámico de clientes y autorización delegada. Los autores construyeron una taxonomía de cuatro categorías de fallos y nueve tipos concretos de fallos a partir de esas diferencias, y luego aplicaron un marco de detección semiautomatizado — inspección pasiva de tráfico más sondeo activo — a los 119 servidores reales analizables con OAuth habilitado. Cada uno de ellos presentó al menos un fallo: 325 fallos en total, y los fallos de registro dinámico de clientes afectaron al 96.6% de los servidores analizados. Muchos de los fallos permiten la filtración de información sensible o la toma de control de cuentas, y la divulgación responsable produjo nueve identificadores CVE.
Dos matices importan, y el libro blanco los expone con claridad. Esto es una instantánea de arXiv v1 de mayo de 2026 de los servidores que los investigadores pudieron encontrar y analizar — no establece una propiedad universal de todos los despliegues de MCP. Y «con OAuth habilitado» significa que estos eran los servidores que intentaron hacer la autorización correctamente. El protocolo les dio un marco opcional; las implementaciones del ecosistema fueron, en esta instantánea, uniformemente defectuosas.
Los ataques a nivel de protocolo
El segundo estudio va más allá de la higiene del despliegue. «Breaking the Protocol» es el primer análisis de seguridad riguroso de la propia especificación de MCP, y limita sus hallazgos a MCP v1.0 (arXiv:2601.17549). Identifica tres vulnerabilidades a nivel de protocolo:
- Ninguna atestación de capacidades. Un servidor puede reclamar permisos arbitrarios. El protocolo transporta la afirmación; nada la comprueba.
- Muestreo bidireccional sin autenticación de origen. Los mensajes iniciados por el servidor pueden llevar inyección de prompts de vuelta al cliente — el servidor no es solo una herramienta, es una fuente de texto que el modelo puede confundir con autoridad.
- Propagación implícita de confianza en configuraciones multiservidor. Conectas varios servidores y cada uno hereda la confianza que solo pretendías otorgar a uno.
Los autores construyeron MCPBench, un arnés que conecta los benchmarks de seguridad de agentes ya existentes con infraestructura compatible con MCP, y ejecutaron 847 escenarios de ataque en cinco implementaciones de servidores MCP. Las decisiones arquitectónicas de MCP amplificaron las tasas de éxito de los ataques en un 23–41% en comparación con integraciones equivalentes que no usan MCP. Su extensión propuesta, MCPSec — atestación de capacidades más autenticación de mensajes, retrocompatible — redujo el éxito de los ataques del 52.8% al 12.4%, con una latencia adicional mediana de 8.3ms por mensaje. Esa propuesta existe precisamente porque el protocolo base no incluye esos mecanismos.
La justicia exige la otra mitad de la frase: el análisis de ataques limita esos riesgos a MCP v1.0, y los borradores actuales de la especificación incluyen mitigaciones de seguridad y orientación de buenas prácticas (buenas prácticas de seguridad de MCP, borrador). La orientación no es aplicación obligatoria. El resumen del libro blanco es el que vale la pena retener: el contenido no confiable de servidores y herramientas todavía requiere validación, aislamiento y autorización del lado del cliente — algo que el protocolo te deja a ti.
Los protocolos transportan mensajes; la gobernanza es una capa aparte
El hilo conductor en ambos estudios y ambas especificaciones: MCP y A2A son capas de conectividad. Definen cómo una solicitud llega a una herramienta, cómo un agente se describe a sí mismo, cómo fluyen los mensajes. Lo que sigue sin estandarizarse por completo es todo lo que está por encima de eso — el libro blanco lo enumera como autoridad delegada a través de cadenas de agentes: atenuación de capacidades, autoridad sobre elementos de trabajo, herencia de políticas, revocación, procedencia de la evidencia, protección contra repetición, reputación y responsabilidad de extremo a extremo desde el principal hasta el agente, la herramienta y el resultado.
Esta es la misma lección de los protocolos de internet de 1974, reformulada para agentes. Nadie espera que TCP decida quién puede entrar en tu edificio. Esperar que el marco OAuth opcional de MCP o la firma de tarjetas opcional de A2A decidan qué agente puede tocar qué repositorio es el mismo error de categoría — y es exactamente el error detrás de la pregunta sobre privacidad planteada al principio de esta publicación. Tu código fuente y tus datos de negocio permanecen privados solo si una capa por encima del protocolo aplica la membresía, la delegación y la revocación como propiedades estructurales, no como convenciones que cada proveedor implementa de manera diferente — o, según el estudio de medición, implementa con al menos un fallo cada una.
Cómo lo aplica Koinessa
Koinessa trata los protocolos de agentes como plomería y construye la capa de gobernanza por encima de ellos, sobre infraestructura controlada por el cliente. Aquí importan tres piezas.
Todo lo externo entra por una única superficie con puerta. Koinessa expone 366 herramientas registradas detrás de un único contrato de búsqueda, y cada arnés — Claude, Kimi, Grok y el Devin CLI en un sandbox controlado — llega a ese contrato a través de la misma superficie MCP local (en vivo). Los bloques de invocación de herramientas son datos: transporte, comando, argumentos, endpoint. Nada se infiere de un nombre, y nada llega a la capa de herramientas sin cruzar el límite.
La autoridad y la procedencia son campos estructurales, no prosa. Como cualquier cosa que llegue al contexto de un modelo puede llevar texto que el modelo confunda con una instrucción — el mecanismo exacto detrás del hallazgo de inyección del lado del servidor de Breaking the Protocol — cada fuente de paquete de contexto en Koinessa lleva una clase de autoridad tipada: operador, verificado, evidencia, agente, inferido, desconocido (en vivo). EGD-002 reforzó este límite con una clase externa-no-confiable y el rechazo en tiempo de compilación de paquetes cuyo contenido no confiable aterrizaría en una sección con autoridad (en vivo, cerrado el 2026-08-15). Un resultado de herramienta envenenado no puede blanquearse a sí mismo como política, porque la distinción la verifica el compilador, no la adivina el modelo.
Los proveedores nuevos se admiten deshabilitados, y se ganan la habilitación después. La capa unificada de proveedores contiene seis descriptores de proveedor — todos deshabilitados, detrás de un indicador de habilitación fail-closed (No habilitado). La incorporación del sexto descriptor es el ejemplo de trabajo: antes de cualquier habilitación, Koinessa hizo commit de una salvaguarda de denegación total y la probó con un canario incorporado al repositorio cuya única llamada a herramienta fue rechazada. La condición previa de gobernanza de datos se verificó en lugar de asumirse — los términos del proveedor establecen que los datos del cliente pueden usarse para el entrenamiento del modelo, con una opción de exclusión de nivel de pago que habilita retención cero de datos con sus proveedores de modelos, y el operador pasó al nivel de pago y confirmó la exclusión antes de la primera prueba gobernada (reportado por el operador, 2026-08-23). Eso es lo que se ve en la práctica «prueba de que mis datos permanecen privados»: no una insignia de protocolo, sino una secuencia de puertas con recibos. La publicación más amplia sobre la arquitectura de Koinessa cubre los planos circundantes, y la publicación sobre autonomía por niveles de riesgo cubre por qué la habilitación sigue siendo una decisión del operador.
La gobernanza de red de agentes por encima de MCP/A2A — membresía, delegación, revocación, repetición — está en la hoja de ruta pública con una etiqueta de estado honesta: el sustrato local está En vivo (EGD-002 completado al 100%, 12/12 y aprobado en revisión), mientras que la membresía entre redes tiene estado Planeado. El informe de limitaciones y estado mantiene esa distinción visible en lugar de aspiracional.
La conclusión
Los estudios de 2026 le dieron al ecosistema de agentes sus primeras cifras duras: el 40.55% de los 7,973 servidores MCP activos analizados expone herramientas sin autenticación, y los 119 servidores con OAuth habilitado analizables en esa instantánea de mayo de 2026 presentaron al menos un fallo cada uno — mientras que un análisis a nivel de protocolo de MCP v1.0 mostró que la propia arquitectura, no solo sus implementaciones, amplifica los ataques de inyección. Ni el marco OAuth opcional de MCP ni la firma de tarjetas JWS opcional de A2A responden la pregunta que abrió esta publicación. Los protocolos transportan mensajes; la gobernanza — membresía, delegación, revocación, protección contra repetición, procedencia — es lo que hace segura a una red de agentes, y la gobernanza es una capa que construyes o adoptas por encima del protocolo, sobre infraestructura que tú controlas, con verificación fail-closed en cada límite. El argumento completo, con cada cita y sus matices, está en el libro blanco de Koinessa.