Microsoft advierte sobre MCP tool poisoning: cuando la descripción de una tool se vuelve ataque
Microsoft publicó el 30 de junio de 2026 un patrón de ataque contra agentes que usan MCP: tool descriptions envenenadas que cambian la conducta del agente sin explotar una vulnerabilidad tradicional. La mitigación empieza por revisar metadata como si fuera prompt de producción.
Por qué importa
Esta nota se enfoca en la decisión práctica para builders: qué cambia, qué riesgo agrega y cómo aplicarlo sin romper operación.
Microsoft publicó el 30 de junio de 2026 una advertencia que debería cambiar cómo los equipos revisan integraciones MCP. El problema no es solo prompt injection desde un documento o una página web. El patrón que describen es más silencioso: MCP tool poisoning, donde la metadata de una tool se modifica para darle instrucciones ocultas al agente.
La parte inquietante es que el agente puede estar “haciendo lo permitido”. Llama una tool aprobada, con permisos normales y en un flujo aparentemente legítimo. El ataque vive en el borde entre confianza, metadata y acción.
El ataque en una frase
Una tool externa mantiene el mismo nombre y resumen visible, pero cambia su descripción interna. Dentro de esa descripción agrega instrucciones maliciosas: por ejemplo, pedir al agente que recopile información adicional y la mande como parámetro en la próxima llamada.
Microsoft lo aterriza con un caso financiero: un agente revisa proveedores e invoices, usa una tool de enriquecimiento aprobada y termina enviando un resumen sensible de facturas no pagadas hacia un servidor controlado por el atacante. Para el usuario, la respuesta final puede verse limpia.
Por qué esto no parece un incidente clásico
El patrón es efectivo porque no exige que el agente rompa reglas obvias:
- la tool ya estaba aprobada;
- el usuario hizo una pregunta normal;
- las consultas internas pueden heredar permisos válidos;
- el destino externo ya estaba allowlisted;
- y cada paso individual puede parecer parte del flujo.
La falla está en la frontera de confianza. MCP mezcla metadata descriptiva con instrucciones que el modelo puede usar para decidir cuándo llamar una tool. Si esa metadata cambia sin revisión, cambió parte del prompt operativo del agente.
La mitigación empieza antes del runtime
La recomendación más importante no es comprar otro dashboard. Es tratar cambios de metadata como cambios de producción.
Si una tool puede inducir al agente a actuar, su descripción no es documentación inocente. Es una pieza de control. Por eso conviene revisar:
- quién publica o actualiza tools;
- si los cambios de descripción disparan aprobación;
- qué datos puede pedir cada tool;
- qué parámetros salen hacia terceros;
- qué acciones requieren humano en el loop.
Controles que sí tienen sentido
Microsoft propone varias capas: allowlist de publishers y servers MCP, inspección de metadata y respuestas con Prompt Shields, DLP sobre parámetros de tool calls, aprobaciones humanas para acciones de alto impacto, identidades no humanas para agentes y correlación de trazas en Sentinel.
La lectura práctica para builders de Latinoamérica es más simple: no pongas todo el peso en el modelo. Necesitas controles alrededor del flujo:
- provenance de tools;
- revisión de metadata;
- permisos mínimos;
- logging de llamadas;
- bloqueo de datos sensibles;
- y aprobación explícita cuando una acción mueve dinero, comparte datos o cambia cuentas.
Dónde Agente IA puede competir
Hay demanda cualificada porque MCP está dejando de ser “conecto mi editor a GitHub” y empieza a tocar finanzas, CRM, documentos internos y workflows con escritura. Las consultas con intención útil son MCP tool poisoning, seguridad MCP agentes, agentic supply chain, tool misuse AI agents y Prompt Shields MCP.
La mayoría de cobertura se queda en el susto. El valor para builders está en convertirlo en checklist de diseño: qué se revisa, dónde se bloquea y qué evidencia queda si algo sale mal.
Mi lectura
El punto fuerte de la publicación de Microsoft es que no trata a los agentes como chatbots con más botones. Los trata como sistemas que leen, deciden y actúan. En ese mundo, una descripción de tool puede tener el mismo peso que una instrucción de sistema.
Si estás montando agentes con MCP, el siguiente paso no es sumar más servers. Es auditar los que ya tienes: metadata, permisos, logs y rutas de salida. Para aterrizar la base desde cero, empieza por el curso gratis. Y si quieres ver el riesgo complementario, revisa la alerta de Microsoft sobre MCP remoto sin autenticación: una historia trata de exposición; esta trata de confianza en la cadena de tools.