Conectaste tu agente a una docena de herramientas MCP y lo dejaste encargarse del backlog del lunes. Slack, GitHub, una API de pagos — el zoológico doméstico completo. La vida se siente automatizada. Entonces el agente reintenta una llamada de pago fallida, y tu cliente termina con un cobro doble.

Nada en MCP le dijo al agente que ese endpoint no era seguro para reintentar. Ni una etiqueta, ni una bandera. Solo una función cruda y un modelo haciendo lo que los modelos hacen — ser "útiles".

El tema es este. La especificación de MCP agregó exactamente los campos de seguridad que necesitarías. Cuatro anotaciones — readOnlyHint, destructiveHint, idempotentHint, openWorldHint. Cuatro booleanos que podrían haber prevenido el escenario del cobro doble por completo. El equipo de MCP los publicó el 16 de marzo de 2026. Y la especificación llamó a cada uno de ellos un "Hint" (pista).

No un contrato. No una restricción. Una pista. Como un Post-it pegado en un arma cargada: "quizás no apuntes esto a la gente".

Seis semanas después, la industria emitió su veredicto. Microsoft lanzó su Agent Governance Toolkit el 2 de abril — políticas basadas en YAML, construidas desde cero, cero referencias a las anotaciones de MCP. Anthropic lanzó políticas de permisos para Managed Agents el 21 de abril — allowlists personalizadas y scoping, ignorando los campos de anotaciones por completo. Google siguió un día después con Agent Gateway el 22 de abril — mismo patrón, mismo motor de políticas desde cero. Tres plataformas grandes en veinte días. Ninguna usó los metadatos de seguridad que ya existían en el protocolo del que todas dependen.

Este no es el mismo problema de los diálogos de permisos teatrales a nivel de plataforma — eso ya lo cubrimos. Y no se trata de output de herramientas sin validar — ese es otro agujero. Esto es sobre la capa del protocolo — el único lugar donde los metadatos de seguridad deberían ser canónicos — socavando activamente su propia credibilidad con una elección de vocabulario.

Justin Spahr-Summers, co-creador de MCP, dijo en voz alta lo que todos pensaban durante la revisión de la especificación en marzo de 2026 en GitHub: "La información en sí, si pudiera ser confiable, sería muy útil, pero me pregunto cómo un cliente hace uso de esta bandera sabiendo que no es confiable." El diseñador de los metadatos de seguridad cuestionó públicamente si alguien podía confiar en ellos. Eso no es una señal de alerta. Eso es la fábrica de señales de alerta.

Metadatos de seguridad auto-declarados sin verificación no son una función de seguridad. Son un buzón de sugerencias. destructiveHint: false de un servidor MCP no confiable es exactamente tan confiable como preguntarle a la herramienta "oye, ¿eres peligrosa?" y creerle la respuesta. Más de 17,000 servidores MCP están distribuidos en registros públicos. La cantidad que tiene alguna verificación independiente de sus anotaciones declaradas: cero.

Todo sistema serio resolvió esto hace décadas. Unix no sugiere permisos de archivos — el kernel los impone. OAuth no sugiere scopes — el servidor de autorización los valida. Docker no sugiere privilegios de contenedor — el runtime los aplica. En todo modelo de seguridad funcional, la entidad que hace la declaración de seguridad no es la misma entidad que está siendo restringida. Eso no es paranoia. Es lo primero que aprendes antes de que te dejen acercarte a producción.

Las anotaciones de MCP violan este principio por diseño. El servidor de la herramienta declara sus propias propiedades de seguridad, el cliente las lee, y nada en el medio verifica la declaración. El Blog de MCP lo reconoció directamente: "Un servidor puede declarar readOnlyHint: true y borrar archivos de todas formas." La propia documentación de la especificación admite que las etiquetas de seguridad pueden mentir y no hay mecanismo para detectarlo.

La palabra "hint" hizo el resto del daño. Cuando etiquetas metadatos de seguridad como una pista, le dices a cada integrador: esto es opcional, no confiable, y no es tu problema. Escucharon. Tres plataformas, tres sistemas de gobernanza desde cero, cero adopción de las anotaciones existentes a nivel de protocolo — todo dentro de abril de 2026. No porque los metadatos sean inútiles, sino porque la especificación los pre-etiquetó como decorativos.

Y acá viene la parte que es peor que no tener nada. Sin anotaciones, sabes que estás volando a ciegas. Anotaciones "hint" significan que quizás tienes datos de seguridad — quizás precisos, quizás fabricados — y tienes que decidir si confiar en ellos sin herramientas de verificación. La falsa confianza es más peligrosa que la ignorancia honesta. Al menos la ignorancia te hace ser cuidadoso.

Así que estás escribiendo políticas YAML a mano. Configurando allowlists de herramientas manualmente. Construyendo las mismas barreras que las anotaciones se suponía que debían proveer, excepto que desde cero, porque la propia capa de seguridad del protocolo te dijo preventivamente que no dependieras de ella. El modelo de seguridad más laborioso posible — no porque no existan mejores metadatos, sino porque alguien decidió llamarlos "hint".

La solución ni siquiera es técnica. Los cuatro campos están correctamente diseñados. El modelo de datos funciona. Lo que está roto es una palabra y la filosofía detrás de ella. Cambiar "hint" por "declaration". Agregar un endpoint de verificación — que los clientes puedan testear las propiedades declaradas contra el comportamiento observado. Hacer que la mentira sea detectable. La mejora de seguridad más barata en toda la pila de agentes está ahí en la especificación, correctamente estructurada, y completamente neutralizada por una decisión de naming que le dijo a 17,000 servidores y tres plataformas de gobernanza que no la tomaran en serio.

Alguien construyó un extintor de incendios, lo etiquetó como "puede o no contener agua", y ahora se pregunta por qué el edificio se está quemando.