Un administrador de sistemas contó en Reddit un pedido de la dirección (la prueba 37). Sonaba simple: conectar un modelo de lenguaje a los datos internos. Lo hicieron. Al poco tiempo, el modelo empezó a mostrar documentos sensibles a gente que no debía verlos.
Pero el modelo no rompió nada. Los permisos ya estaban mal puestos y nadie los había corregido. El comentario más votado dijo que la mayoría de las organizaciones tiene un gobierno de datos flojo.
Poco más de un mes después, el mismo administrador volvió al foro (la prueba 48). Ahora la dirección quería agentes que dispararan flujos y mandaran correos. El consejo más votado fue pedir algo por escrito antes de darle acciones al agente. El negocio o legales tenían que aceptar el riesgo.
Conectar un modelo a los datos internos es un trabajo de integración y nada más.
Veredicto: No: el modelo hereda los permisos que ya estaban mal puestos. Un equipo conectó un asistente a los datos internos. El asistente mostró documentos sensibles a gente que no debía verlos. Pasó porque nadie había corregido esos permisos. Un borrador de NIST suma una pregunta abierta. ¿Puede el usuario ver la respuesta que combina todo lo que el agente juntó?
Criterio
Antes de conectar un modelo a datos internos, revisá quién puede ver qué y corregilo. Si el negocio quiere avanzar igual, pedí que acepte el riesgo por escrito.
Por qué confianza baja. El caso viene de Reddit, sin medición. Pero el comentario más votado dice que el gobierno de datos flojo es común. El documento de NIST es un borrador con preguntas, no con controles. Ninguna fuente defiende que alcance con integrar.
Ver el detalle de las 3 pruebasOcultar el detalle0 a favor, 1 en contra, 2 matizan
La dirección pidió conectar un modelo de lenguaje a los datos internos. El asistente empezó a mostrar documentos sensibles a gente que no debía verlos, porque nadie corrigió unos permisos que ya estaban mal puestos. El comentario más votado dice que la mayoría de las organizaciones tiene un gobierno de datos flojo en SharePoint, Teams y OneDrive. Otro propone un proyecto de preparación y gobierno de datos antes de activar el asistente.
Números
1.351 puntos y 198 comentariosTamaño del hilo según el archivo. El comentario citado tiene 500 puntos.
Limitación Experiencia de quienes operan TI, sin medición. Se leyó en el archivo público Arctic Shift porque reddit.com bloquea la lectura automática. La cita se comparó letra por letra con el original.
“the LLM tool has access to what you give it/your people access to”
Es el mismo autor del hilo sobre conectar un modelo a los datos internos. Ahora la dirección le pide agentes que disparen flujos y manden correos. El consejo más votado: pedir por escrito que el negocio o legales acepten el riesgo antes de darle acciones al agente. En cambio, otro describe un agente angosto que clasifica unos 5.000 faxes por día hacia la persona correcta, sin poder de hacer daño.
Números
unos 5.000 faxes por díaVolumen que clasifica un agente angosto, según un comentarista.
338 puntos y 129 comentariosTamaño del hilo según el archivo. El comentario citado tiene 376 puntos.
Limitación Experiencia de quienes operan TI, sin medición. Se leyó en el archivo público Arctic Shift porque reddit.com bloquea la lectura automática. La cita se comparó letra por letra con el original.
“get it in writing from legal that you're not liable”
Booth, H., Fisher, B., Galluzzo, R., Roberts, J. NIST, NCCoE
Es un borrador de NIST para un proyecto de demostración que aplica estándares de identidad a los agentes. Propone distinguir al agente de una persona, autenticarlo y autorizarlo con OAuth 2.0 y políticas. También propone ligar cada agente a la persona que delega en él y registrar sus acciones. Pregunta cómo saber qué tan sensibles son los datos que junta el agente y si el usuario puede ver la respuesta combinada. También pregunta cómo fijar el mínimo privilegio (dar solo los permisos necesarios) cuando las acciones del agente no son predecibles.
Números
6 grupos de preguntasGenerales, identificación, autenticación, autorización, auditoría e inyección de prompts. Comentarios del 5 de febrero al 2 de abril de 2026.
Limitación Es un borrador para consulta, con preguntas y no controles. Deja RAG fuera del alcance. Se leyó el PDF (11 páginas); la página del proyecto dio 403.
“How do we establish "least privilege" for an agent”
Cita verificada contra el original
Leída en la fuente. Revisada el 2 nov 2026.
Hoy ese salto no pide una integración a medida. MCP (Model Context Protocol) es el protocolo que conecta un agente con herramientas y datos. Un servidor MCP ofrece herramientas. Cada herramienta tiene un nombre y una descripción, y el agente las lee para decidir cuándo usarla.
A2A es el protocolo de agente a agente. Lo creó Google y hoy lo aloja la Linux Foundation. Alguien busca un servidor MCP para un sistema y lo instala. Esa misma tarde, el agente tiene herramientas nuevas.
La tesis que circula tiene dos partes. La primera: MCP y A2A ya son estándares maduros. La segunda va más lejos: si MCP es un estándar, conectar un servidor MCP es seguro. Y una vez aprobado el servidor, podés confiar en sus herramientas.
A2A llegó a su versión 1.0, la primera especificación estable, según un comunicado de la Linux Foundation (la prueba 78). Trae Agent Cards firmadas. Son fichas que describen a cada agente y que se pueden verificar. A2A ya está integrado en Azure AI Foundry, Copilot Studio y Amazon Bedrock AgentCore. Lo apoyan más de 150 organizaciones, contra más de 50 en abril de 2025.
más de 150 organizaciones
Organizaciones que apoyan el protocolo (eran más de 50 en abril de 2025). Prueba 78
MCP también ganó estabilidad. La revisión 2026-07-28 de la especificación (la prueba 121) fijó un plazo mínimo de 12 meses para deprecar funciones. Deprecar es avisar que una función se va a retirar. Si construís sobre una función, sabés que no desaparece de un mes para el otro.
Los defensores de MCP en Hacker News suman un argumento de seguridad (la prueba 136). Dicen que en integraciones empresariales MCP funciona como frontera:
Las credenciales quedan en el servidor.
La telemetría, los datos de uso, se mide del lado del servidor.
Una sola integración sirve a muchos clientes.
Otro hilo discutió un artículo que daba a MCP por muerto frente a la línea de comandos (la prueba 61). La respuesta fue parecida. En un agente compartido o de producción, herramientas acotadas son mejores que una shell, la terminal con acceso libre a comandos. Eso es mínimo privilegio: solo el acceso que la tarea necesita. Con una shell, aislar las credenciales es mucho más difícil.
Con MCP y A2A ya hay estándares maduros para conectar agentes en la empresa.
Veredicto: Maduros como protocolos, no como garantía. A2A lanzó su versión 1.0, la primera estable, con el apoyo de más de 150 organizaciones. MCP fijó un plazo mínimo de 12 meses antes de retirar funciones. Pero en un editor con agente, una página web hizo que el agente registrara un servidor MCP malicioso. Y entre agentes, una instrucción plantada como dato puede llegarle al siguiente como pedido confiable.
Criterio
Usá los estándares para no atarte a un proveedor. Diseñá la seguridad por encima de ellos: qué agente habla con cuál, con qué datos y con qué permisos. Anotá la versión de la especificación que usás y revisala antes de cada cambio.
Por qué confianza media. La adopción de A2A sale de un comunicado promocional que no nombra despliegues concretos. La especificación de MCP es primaria, pero cambia seguido. La falla del editor es un registro oficial. El paso entre agentes sale de un preprint, un artículo sin revisión de pares. NIST todavía arma sus estándares para agentes, sin entregables.
Ver el detalle de las 5 pruebasOcultar el detalle2 a favor, 2 en contra, 1 matiza
A2A, el protocolo de agente a agente que creó Google, lanzó su versión 1.0, la primera especificación estable. Hoy lo aloja la Linux Foundation y ya está integrado en Azure AI Foundry, Copilot Studio y Amazon Bedrock AgentCore. Trae Agent Cards firmadas (la ficha de cada agente) y soporte para varios clientes en una misma instalación. Se presenta como complemento de MCP: A2A conecta agentes entre sí y MCP conecta un agente con herramientas y datos.
Números
más de 150 organizacionesOrganizaciones que apoyan el protocolo (eran más de 50 en abril de 2025).
más de 22.000 estrellasEstrellas en GitHub. Hay SDK en 5 lenguajes.
Limitación Es un comunicado promocional. Muestra adopción del estándar, no valor de negocio, y no nombra despliegues concretos.
Revisión de la especificación de MCP, el protocolo que conecta agentes con herramientas y datos. MCP pasa a ser sin estado: la revisión elimina las sesiones de protocolo y el saludo inicial (initialize) y agrega server/discover. La autorización es opcional. Si se usa sobre HTTP, se basa en OAuth 2.1 y el servidor debe comprobar que el token se emitió para él. Según la especificación, las descripciones de herramientas no son confiables salvo que vengan de un servidor confiable. El host debe pedir consentimiento antes de usar una herramienta, y el protocolo no puede hacer cumplir esos principios.
Números
12 mesesPlazo mínimo de la nueva política de deprecación.
Limitación La seguridad depende de quien implementa el servidor y el cliente. Es la revisión vigente al 1 de noviembre de 2026 (la anterior es la 2025-11-25). Las especificaciones cambian: conviene revisar la versión antes de citarla.
Windsurf 1.9544.26 es un editor con agente que usa MCP, el protocolo que conecta al agente con herramientas. Un contenido HTML del atacante puede hacer que el agente cambie la configuración local de MCP y registre un servidor MCP malicioso. Ese servidor ejecuta comandos sin que el usuario haga nada más. La falla une la inyección de prompts (órdenes escondidas en el contenido) con MCP como vía para ejecutar código.
Números
8,0 sobre 10 (alta)Gravedad CVSS 3.1, sin interacción del usuario. La agregó CISA dentro del registro; MITRE, que lo asignó, no puso puntaje.
Limitación Registro oficial; el reporte original es de OX Security. El registro dice qué falla, no cuántas veces se explotó.
Peters-Gill, J., Semler, A., Bartsch, H., Shumailov, I., Schroeder de Witt, C. arXiv
Un coautor de CaMeL, una defensa contra instrucciones plantadas, muestra que sus garantías no se suman solas entre agentes. Una instrucción plantada en una base de datos es un dato, pero el orquestador la resume y otro agente la recibe como pedido confiable. En las mediciones, CaMeL en cada agente baja mucho el éxito de los ataques. Una versión que sigue el origen de los datos entre agentes cierra ese camino. El costo es utilidad, y los modelos más capaces pierden menos.
Números
12,9 %, 0,2 % y 0,0 %Tasa de ataques exitosos sin CaMeL, con CaMeL en cada agente y con procedencia entre agentes. Es el promedio de 5 modelos, con 949 casos por modelo y configuración.
21,6 y 13,4 puntosUtilidad que pierde CaMeL por agente en 112 tareas: en promedio y en los dos modelos más fuertes. La versión entre agentes resta otros 3,2 puntos en promedio.
Limitación Preprint. Un modelo rechazó 53,6 % de las tareas benignas aun sin CaMeL, lo que baja su utilidad de base.
NIST lanza una iniciativa de estándares para agentes con tres pilares. Son apoyar estándares hechos por la industria, fomentar protocolos abiertos para agentes e investigar la seguridad y la identidad de los agentes. Promete guías para los próximos meses, pero el comunicado no trae ninguna guía ni un plazo concreto.
Números
3 pilaresLíneas de trabajo de la iniciativa.
Limitación Comunicado de gobierno. Todo es voluntario y todavía sin entregables.
La propia especificación de MCP pone los primeros límites a la tesis:
La autorización es opcional.
Las descripciones de herramientas son no confiables, salvo que vengan de un servidor confiable.
El host, el programa donde corre el agente, tiene que pedir consentimiento antes de usar una herramienta.
El protocolo no puede hacer cumplir esos principios.
La seguridad queda en manos de quien implementa el servidor y el cliente.
Los registros oficiales muestran qué pasa cuando eso falla. Windsurf es un editor con agente. Ahí, contenido HTML del atacante podía hacer que el agente registrara un servidor MCP malicioso (la prueba 80). Ese servidor ejecuta comandos. En Flowise, un usuario autenticado podía agregar un servidor MCP local con cualquier comando. La gravedad era 10 sobre 10 (la prueba 84).
OX Security, que vende seguridad, describió una inyección de comandos en 17 productos (la prueba 82). Está ligada al transporte local de MCP. El kit oficial de MCP figura entre los que no se van a parchear. Sus responsables lo ven como comportamiento esperado.
¿Es cosa de laboratorio? Varios benchmarks, pruebas estándar para comparar modelos, dicen que no. MCP-SafetyBench usó servidores MCP reales (la prueba 34). Todos los modelos siguieron vulnerables, con ataques exitosos de 29,80 % a 48,16 %. En “When the Manual Lies” (la prueba 105), una descripción envenenada funcionó cerca de 100 % de las veces contra GPT-4o.
MCP Pitfall Lab midió servidores con errores comunes de desarrollo (la prueba 88). Los ataques tuvieron éxito 31,9 % de las veces en 2.579 corridas. Son preprints, estudios sin revisión de pares, leídos por el resumen y con modelos de 2025.
El mismo patrón aparece en las skills, paquetes de instrucciones y código para agentes. Snyk, que vende un escáner, confirmó carga maliciosa en 76 de 3.984 (la prueba 54).
MCP es un estándar, así que conectar un servidor MCP es seguro.
Veredicto: No. La propia especificación dice que el protocolo no puede hacer cumplir sus principios de seguridad. En un benchmark con servidores MCP reales, todos los modelos siguieron siendo vulnerables. Los ataques exitosos fueron de 29,80 % a 48,16 %. En Flowise, agregar un servidor MCP local permitía ejecutar código, con gravedad 10 sobre 10. El kit oficial de MCP tiene una inyección de comandos que no se va a parchear. Sus responsables la ven como comportamiento esperado.
Criterio
Tratá cada servidor MCP como código de terceros. Leé la descripción completa de cada herramienta y fijá la versión con un hash. No lo pongas en la misma sesión que los servidores con datos sensibles.
Por qué confianza alta. Coinciden la especificación oficial, un registro oficial de una falla y varios benchmarks independientes. Además, el kit oficial tiene una falla que no se va a parchear. Los benchmarks son preprints, sin revisión de pares, con modelos de 2025. La falla del kit la publica una empresa que vende seguridad. Otra empresa de seguridad publica una auditoría de skills, que son otra forma de sumar herramientas. Muestra lo mismo. Del lado a favor solo hay opiniones de Hacker News.
Ver el detalle de las 8 pruebasOcultar el detalle1 a favor, 6 en contra, 1 matiza
Hilo sobre si MCP, un protocolo que conecta agentes con herramientas, sirve o es OpenAPI reinventado. Para los defensores, MCP ya es lo normal en integraciones empresariales porque funciona como frontera de seguridad y de autenticación. Dan tres razones: telemetría (datos de uso) del lado del servidor, credenciales guardadas en el servidor y una sola integración para muchos clientes. Los críticos lo ven como una capa más sobre APIs que ya existían.
Números
687 puntos y 363 comentariosTamaño del hilo.
Limitación Opiniones técnicas, sin datos de adopción. Se leyó en news.ycombinator.com y en la API pública de Algolia. Las citas del hilo no se cotejaron palabra por palabra en la verificación de origen y por eso no se usan.
Benchmark (banco de pruebas estándar) con servidores MCP reales en cinco dominios: navegador, finanzas, mapas, repositorios y búsqueda web. Prueba 20 tipos de ataque del lado del servidor, del host y del usuario. Todos los modelos probados siguen siendo vulnerables, y los que mejor hacen la tarea resisten peor los ataques.
Números
de 29,80 % a 48,16 %Tasa de ataques exitosos en 13 modelos y 245 casos (GPT-5: 37,55 %; Claude 4.0 Sonnet: 31,43 %).
r = -0,572Correlación entre éxito en la tarea y defensa (p = 0,041, con solo 13 modelos).
Limitación Preprint. Hay una versión 2 (5 de marzo de 2026) que no dice qué cambió; se usan los números de la versión 1. Modelos de 2025. El éxito en la tarea es bajo (de 9 % a 21 %).
“models with higher task performance tend to be less resistant to attacks”
Liu, S., Tang, X., Yang, X., Lin, L., Zhou, B., Xiao, W., Liu, W. arXiv
Es un benchmark en un entorno aislado sobre envenenamiento de MCP (el protocolo que conecta herramientas a un agente). En este ataque, la descripción de la herramienta trae la trampa. Según los autores, modelos líderes como GPT-4o son muy vulnerables. También dicen que las defensas comunes por prompt casi no sirven y a veces empeoran el resultado.
Números
cerca de 100 %Éxito del ataque contra GPT-4o en seis escenarios de alto riesgo, según el resumen (32 casos, 6 categorías, 8 modelos).
Limitación Preprint; se leyó el resumen, que no da cifras de los otros modelos.
Mide ataques contra servidores de herramientas MCP con errores comunes de desarrollo. Proponen tratar a los servidores MCP como dependencias de la cadena de suministro y llevar un inventario de qué hace cada uno.
Números
31,9 % y 38,7 %Éxito de los ataques en total y con inyección multimodal, en 2.579 corridas con 4 modelos.
Limitación Preprint; se leyó el resumen, que no nombra los modelos. Hay una versión 2 (14 de julio de 2026) que no dice qué cambió.
En Flowise antes de la versión 3.1.0, un usuario autenticado podía agregar un servidor MCP local con cualquier comando y ejecutarlo. El usuario saltaba los filtros de comandos permitidos con un comando permitido y argumentos que ejecutan código. Filtrar comandos no alcanza.
Números
10 sobre 10 (crítica)Gravedad CVSS 3.1 según la CNA (GitHub).
Limitación Registro oficial. Pide un usuario autenticado.
Siman Tov Bustan, M., Naamnih, M., Zadok, N. OX Security
Describe una inyección de comandos (lograr que se ejecuten comandos ajenos) que se repite en el transporte local de MCP. Muchas aplicaciones pasan el comando y los argumentos de la configuración a un proceso sin validarlos. Lista productos afectados y familias de falla. El kit oficial de MCP figura entre los que no se van a parchear, porque los responsables lo tomaron como comportamiento esperado.
Números
17 productos y 14 CVEProductos afectados y CVE asignados por ellos, en 4 familias de falla.
Limitación Lo publica una empresa que vende seguridad; "sistémica" es su palabra. Discute si el diseño del transporte es responsable.
Beurer-Kellner, L., Kudrinskii, A., Milanta, M., Nielsen, K. B., Sarkar, H., Tal, L. Snyk
Es una auditoría de las skills publicadas en dos catálogos abiertos, con un escáner y revisión humana. Una skill es un paquete de instrucciones y código que se le suma a un agente. La skill hereda todos los permisos del agente: terminal, archivos y credenciales. Para publicar alcanza un archivo y una cuenta nueva, sin firma, sin revisión y sin aislamiento por defecto. El envenenamiento de herramientas deja de ser una demostración y pasa a medirse en un ecosistema real.
Números
76 de 3.984Skills con carga maliciosa confirmada por personas, sobre las escaneadas. 8 seguían publicadas al escribir.
534 (13,4 %) y 1.467 (36,82 %)Skills con al menos un problema crítico y con algún problema.
Limitación Lo publica la empresa que vende el escáner. El título habla de 1.467 cargas maliciosas, pero el cuerpo dice que 1.467 son skills con algún problema y 76 las maliciosas confirmadas: la base usa el cuerpo. Las skills no son exactamente servidores MCP.
“Agent Skills operate with the full permissions of the AI agent they extend”
Revisión de la especificación de MCP, el protocolo que conecta agentes con herramientas y datos. MCP pasa a ser sin estado: la revisión elimina las sesiones de protocolo y el saludo inicial (initialize) y agrega server/discover. La autorización es opcional. Si se usa sobre HTTP, se basa en OAuth 2.1 y el servidor debe comprobar que el token se emitió para él. Según la especificación, las descripciones de herramientas no son confiables salvo que vengan de un servidor confiable. El host debe pedir consentimiento antes de usar una herramienta, y el protocolo no puede hacer cumplir esos principios.
Números
12 mesesPlazo mínimo de la nueva política de deprecación.
Limitación La seguridad depende de quien implementa el servidor y el cliente. Es la revisión vigente al 1 de noviembre de 2026 (la anterior es la 2025-11-25). Las especificaciones cambian: conviene revisar la versión antes de citarla.
Leída en la fuente. Revisada el 1 nov 2026.
Queda la creencia de que alcanza con aprobar un servidor una vez. El registro MAL-2026-4069 documenta un servidor MCP legítimo publicado en npm, el registro público de paquetes de JavaScript (la prueba 103). Con una versión nueva, pasó a ser malicioso. Fue parte de una campaña de 631 versiones de 314 paquetes en 22 minutos. Cada versión robaba credenciales de la nube, de GitHub y de npm al instalarse. Lo que aprobaste el lunes puede no ser lo que corre el jueves.
Una herramienta puede hacer daño sin que nadie la llame. En MCP-ITP (la prueba 41), la descripción de una herramienta envenenada alcanzó para cambiar la conducta del agente. El agente usó otra herramienta legítima, con más permisos. El ataque tuvo éxito hasta 84,2 % de las veces. Un detector vio esas descripciones como mucho 0,3 % de las veces.
OWASP, una fundación de seguridad de software, pone la cadena de suministro entre sus diez riesgos para agentes (la prueba 33). La cadena de suministro es todo el código de terceros que usás. MCP Pitfall Lab propone tratar los servidores como dependencias, con un inventario de qué hace cada uno.
Si aprobé un servidor MCP una vez, ya puedo confiar en sus herramientas.
Veredicto: No. Un servidor MCP legítimo publicado en npm pasó a ser malicioso con una versión nueva. Fue parte de una campaña de 631 versiones de 314 paquetes en 22 minutos. Además, la descripción de una herramienta puede hacer que el agente use otra para hacer el daño. Esa otra es legítima y tiene más permisos. La especificación dice que las descripciones no son confiables, salvo que vengan de un servidor confiable.
Criterio
Llevá un inventario de servidores MCP, cada uno con dueño, y tratalos como dependencias. Habilitá las herramientas una por una y fijá la versión. Pedí aprobación de nuevo si cambia la descripción o el paquete.
Por qué confianza media. El paquete malicioso figura en un registro público y la especificación es primaria. El ataque entre herramientas sale de un preprint, sin revisión de pares, leído por el resumen. No hay datos de su frecuencia en el mundo real. OWASP pone la cadena de suministro entre los diez riesgos de los agentes, pero no la mide. Del lado a favor solo hay opiniones en Hacker News.
Ver el detalle de las 6 pruebasOcultar el detalle1 a favor, 3 en contra, 2 matizan
Hilo sobre si MCP, un protocolo que conecta agentes con herramientas, sirve o es OpenAPI reinventado. Para los defensores, MCP ya es lo normal en integraciones empresariales porque funciona como frontera de seguridad y de autenticación. Dan tres razones: telemetría (datos de uso) del lado del servidor, credenciales guardadas en el servidor y una sola integración para muchos clientes. Los críticos lo ven como una capa más sobre APIs que ya existían.
Números
687 puntos y 363 comentariosTamaño del hilo.
Limitación Opiniones técnicas, sin datos de adopción. Se leyó en news.ycombinator.com y en la API pública de Algolia. Las citas del hilo no se cotejaron palabra por palabra en la verificación de origen y por eso no se usan.
Es un registro de código malicioso en un servidor MCP (programa que le da herramientas a un agente) publicado en npm. Es parte de una campaña: tomaron una cuenta de npm y publicaron cientos de versiones maliciosas en minutos. Cada versión corre un script al instalarse y roba credenciales de la nube, de GitHub y de npm, entre otras. Un paquete MCP legítimo pasó a ser malicioso con una versión nueva.
Números
631 versiones de 314 paquetes en 22 minutosTamaño de la campaña.
Limitación Registro público de la base OSV, leído con su API. Describe el paquete, no cuántas instalaciones hubo.
El agente nunca llama a la herramienta envenenada. Su descripción alcanza para que el agente use otra herramienta legítima, con más permisos, para hacer el daño. Los autores generan esas descripciones de forma automática. Las optimizan para que el ataque funcione y para que un detector no lo vea.
Números
hasta 84,2 %Éxito del ataque sobre el conjunto de MCPTox, con 12 agentes.
hasta 0,3 %Tasa de detección de herramientas maliciosas.
Revisión de la especificación de MCP, el protocolo que conecta agentes con herramientas y datos. MCP pasa a ser sin estado: la revisión elimina las sesiones de protocolo y el saludo inicial (initialize) y agrega server/discover. La autorización es opcional. Si se usa sobre HTTP, se basa en OAuth 2.1 y el servidor debe comprobar que el token se emitió para él. Según la especificación, las descripciones de herramientas no son confiables salvo que vengan de un servidor confiable. El host debe pedir consentimiento antes de usar una herramienta, y el protocolo no puede hacer cumplir esos principios.
Números
12 mesesPlazo mínimo de la nueva política de deprecación.
Limitación La seguridad depende de quien implementa el servidor y el cliente. Es la revisión vigente al 1 de noviembre de 2026 (la anterior es la 2025-11-25). Las especificaciones cambian: conviene revisar la versión antes de citarla.
Es la primera lista de consenso de OWASP hecha para agentes. Los diez riesgos van desde el secuestro del objetivo del agente (ASI01) hasta los agentes rebeldes (ASI10). Entre ellos están el mal uso de herramientas (ASI02) y el abuso de identidad y privilegios (ASI03). También están la cadena de suministro agéntica (ASI04) y las fallas en cascada (ASI08). Suma el principio de mínima agencia: no dar autonomía que no hace falta. Como mitigaciones pide perfiles de mínimo privilegio por herramienta, aprobación humana para acciones destructivas y controles fuera del modelo. También pide topes de costo, tasa o tokens con corte automático.
Números
10 riesgos (ASI01 a ASI10)Tamaño de la lista. ASI02 y ASI03 extienden la agencia excesiva (LLM06) de la lista de 2025 a flujos de varios pasos.
Limitación Es un marco voluntario de consenso: no obliga a nadie y no mide nada. En la lista de agentes, el consumo sin límites ya no es un ítem propio: aparece como escenario y mitigación dentro de ASI02. Se leyó el PDF completo (57 páginas).
“deploying agentic behavior where it is not needed expands the attack surface”
Mide ataques contra servidores de herramientas MCP con errores comunes de desarrollo. Proponen tratar a los servidores MCP como dependencias de la cadena de suministro y llevar un inventario de qué hace cada uno.
Números
31,9 % y 38,7 %Éxito de los ataques en total y con inyección multimodal, en 2.579 corridas con 4 modelos.
Limitación Preprint; se leyó el resumen, que no nombra los modelos. Hay una versión 2 (14 de julio de 2026) que no dice qué cambió.
Leída en la fuente. Revisada el 2 nov 2026.
Entre agentes, el problema cambia de forma. CaMeL es un diseño que separa lo que pide el usuario de los datos que lee el agente. Un preprint con un coautor de CaMeL mostró que una instrucción plantada en una base de datos viaja como dato (la prueba 139). El orquestador, el agente que reparte el trabajo, la resume dentro del pedido a otro agente. Ahí la instrucción pasa a ser un pedido confiable.
Un estándar de agente a agente no corta ese camino. Lo corta un diseño que conserva de dónde vino cada dato.
MCP y A2A son maduros como protocolos.Tienen versiones estables, una política para retirar funciones y adopción en plataformas grandes. Usarlos te ahorra integraciones a medida. También te deja cambiar de proveedor sin rehacer todo.
No son una garantía de seguridad, y la propia especificación lo dice. Un estándar decide cómo se habla. No decide qué datos combina el agente, qué servidor es confiable ni si un paquete cambió. Tratá un servidor MCP como una librería que bajás de internet: código de terceros que corre con tus permisos.
NIST, el instituto de estándares de Estados Unidos, lanzó una iniciativa de estándares para agentes con 3 pilares (la prueba 59). Pero el comunicado no trae ninguna guía ni plazo.
Los defensores de MCP tienen razón en la seguridad. Una herramienta angosta, con las credenciales del lado del servidor, es más fácil de controlar que una shell. En el rendimiento, la cuenta es otra.
Anthropic, que vende el modelo, mostró que 58 herramientas de 5 servidores ocupan unos 55.000 tokens antes de empezar (la prueba 23). Un token es una unidad de texto que el modelo procesa y que se cobra. Con búsqueda de herramientas a demanda, Opus 4.5 subió su precisión en esas evaluaciones de MCP de 79,5 % a 88,1 %.
En otro post, Anthropic propone darle al agente los servidores como código en un sandbox, un entorno aislado (la prueba 15). En su ejemplo, el consumo bajó de 150.000 a 2.000 tokens. Son ejemplos propios del proveedor. Igual indican que rendir más depende de cómo cargás las herramientas, no solo de cuántas son.
La evidencia tiene límites. La adopción de A2A sale de un comunicado promocional. Los benchmarks son preprints, y varias fallas las publican empresas que venden seguridad. Ninguna fuente dice con qué frecuencia pasan estos ataques en producción. Todas coinciden en el mecanismo.
Las herramientas acotadas son más seguras y rinden más que darle al agente una shell o la API entera.
Veredicto: Más seguras sí, pero rendir más depende de cómo se cargan. En un agente compartido o de producción, las herramientas acotadas permiten aplicar mínimo privilegio y aislar credenciales. Mínimo privilegio es dar solo el permiso que la tarea pide. Pero un proveedor de modelos propone darle al agente las herramientas como código en un sandbox, un entorno aislado. En un ejemplo, el consumo bajó de 150.000 a 2.000 tokens. Y acotada no quiere decir confiable.
Criterio
En producción, dale al agente herramientas angostas, con las credenciales del lado del servidor. Cargalas cuando hacen falta en vez de todas al principio. Si le das código, que corra en un sandbox con límites y monitoreo.
Por qué confianza baja. La parte de seguridad se apoya en opiniones de un hilo de Hacker News, sin datos. La de rendimiento son ejemplos propios de un proveedor de modelos. Un preprint leído por el resumen agrega un riesgo: la descripción de una herramienta puede hacer que el agente use mal otra. Un preprint es un artículo sin revisión de pares.
Ver el detalle de las 4 pruebasOcultar el detalle1 a favor, 1 en contra, 2 matizan
Hilo sobre un artículo que da por muerto a MCP (protocolo que conecta agentes con herramientas) frente a la línea de comandos. Para los defensores, en un agente compartido o de producción, herramientas acotadas son mejores que una shell. Es mínimo privilegio: dar solo el acceso necesario. Con una shell es mucho más difícil aislar las credenciales. Para la mayoría de las personas, que no son técnicas, MCP ofrece barandas de seguridad y una autenticación simple y pareja.
Números
447 puntos y 284 comentariosTamaño del hilo.
Limitación Opiniones técnicas, sin datos de adopción. Se leyó en news.ycombinator.com y en la API pública de Algolia. Las citas del hilo no se cotejaron en la verificación de origen y por eso no se usan.
Cargar todas las definiciones de herramientas al principio y pasar cada resultado intermedio por el modelo gasta muchos tokens. El post propone presentar los servidores MCP, que conectan al agente con herramientas, como una API de código. El agente carga solo lo que usa, filtra los datos en el entorno de ejecución y le devuelve al modelo solo lo necesario. Avisa que ejecutar código del agente exige sandbox, límites y monitoreo.
Números
de 150.000 a 2.000 tokensAhorro en un ejemplo del post (98,7 %).
5 filas en vez de 10.000Lo que ve el modelo de una planilla cuando el filtro corre en el código.
Limitación Lo publica el proveedor del modelo; los números son ejemplos propios. El costo en tokens de muchas herramientas es real. Pero la salida que propone se parece más a darle código al agente que a pocas herramientas acotadas.
“Note that code execution introduces its own complexity.”
Anthropic suma tres funciones: buscar herramientas a demanda, llamarlas desde código y sumar ejemplos de uso a la definición. El código corre en un sandbox, un entorno aislado. Muestra que muchas definiciones de herramientas gastan contexto y bajan la precisión. Propone cargar las herramientas cuando hacen falta, no tener pocas.
Números
unos 55.000 tokensLo que ocupan 58 herramientas de 5 servidores MCP antes de empezar.
unos 8.700 contra 77.000 tokensContexto usado con búsqueda de herramientas y sin ella (85 % menos).
de 79,5 % a 88,1 %Precisión de Opus 4.5 en evaluaciones de MCP sin y con búsqueda de herramientas (Opus 4: de 49 % a 74 %).
Limitación Anuncio de producto del proveedor; las evaluaciones son internas.
El agente nunca llama a la herramienta envenenada. Su descripción alcanza para que el agente use otra herramienta legítima, con más permisos, para hacer el daño. Los autores generan esas descripciones de forma automática. Las optimizan para que el ataque funcione y para que un detector no lo vea.
Números
hasta 84,2 %Éxito del ataque sobre el conjunto de MCPTox, con 12 agentes.
hasta 0,3 %Tasa de detección de herramientas maliciosas.
Usá los estándares para no atarte a un proveedor, y diseñá la seguridad por encima de ellos. Ahora:
Antes de conectar un modelo a datos internos, revisá quién puede ver qué y corregilo. Si el negocio quiere avanzar igual, pedí que acepte el riesgo por escrito.
Armá un inventario de servidores MCP. Anotá para cada uno un dueño, la versión fijada con un hash y la fecha de la última revisión. Un hash es una huella que cambia si cambia el paquete.
Leé la descripción completa de cada herramienta y habilitalas una por una. Pedí aprobación de nuevo si cambia la descripción o el paquete.
No pongas un servidor de terceros en la misma sesión que los servidores con datos sensibles. Es la regla de dos del capítulo 5 aplicada a las conexiones.
En producción, dale al agente herramientas angostas, con las credenciales del lado del servidor. Cargalas cuando hacen falta. Si le das código, hacé que corra en un sandbox con límites.
Anotá la versión de la especificación que usás. Con A2A, anotá qué agente habla con cuál, con qué datos y con qué permisos.