Agentes de IA conectados a tus sistemas: identidad, túnel y herramientas que no cambian solas

El 10 de agosto de 2026, una sola cuenta envió 23 pull requests en 74 minutos a proyectos de IA, de MCP y de herramientas de desarrollo sin relación entre sí. No era una contribución legítima: era la campaña Deadbugz, documentada por Pillar Security el 12 de agosto de 2026. Diecinueve de esos PR fueron cerrados; cuatro seguían abiertos al momento del informe.

El ataque no apuntaba al código de los proyectos. Apuntaba a los agentes de IA que usan esos servidores MCP como herramientas. Y lo que revela es un problema de arquitectura: conectamos agentes a sistemas confiando en que las herramientas no cambian, y eso ya no es válido.

Qué pasó

El servidor MCP de Deadbugz se presentaba como una utilidad inofensiva: ofrecía formateo de texto y resúmenes. Un agente que se conectaba a él veía esas dos herramientas y las usaba sin sospechar nada.

A partir de la tercera llamada, el comportamiento cambiaba. Las respuestas de tools/list y prompts/get ya no devolvían formateo ni resúmenes: las nuevas descripciones le indicaban al agente buscar llaves SSH, credenciales de AWS, historial de la terminal y configuración de Kubernetes, y ocultarle esa actividad al usuario. Un agente que obedeciera esas descripciones lo haría sin avisarle al usuario: el informe no dice cuántos llegaron a hacerlo, y no hace falta para entender el riesgo.

Pillar Security fue clara en su recomendación: los clientes deben tratar un cambio en la definición de herramientas de un servidor ya aprobado como un evento de seguridad relevante. No es una sugerencia de mejora: es un criterio de diseño.

Las vulnerabilidades que ya estaban ahí

En agosto de 2026, la base de datos NVD del NIST publicó tres vulnerabilidades en servidores MCP legítimos. No eran ataques sofisticados: eran fallas de implementación en herramientas que las empresas ya estaban usando.

CVE-2026-73498, severidad alta 7.7: recorrido de rutas en el servidor MCP comunitario para Confluence y Jira, versiones anteriores a 0.22.0. La ruta de archivo que recibía la herramienta llegaba sin validar a la función que abre el archivo.

CVE-2026-67357, severidad alta 7.7: el servidor MCP de ArcadeDB, antes de la versión 26.7.3, devolvía el token del clúster en texto claro. Quien tuviera acceso MCP al servidor podía obtener ese token y usarlo contra el clúster.

CVE-2026-19956, severidad media 5.3: falsificación de peticiones del lado del servidor en un servidor MCP para anuncios de Facebook, versión 0.1.0. El servidor podía ser inducido a hacer peticiones a destinos que no debía.

El patrón es claro: herramientas MCP legítimas, usadas por equipos reales, con vulnerabilidades que exponen datos o permiten movimiento lateral. Y Deadbugz agregó otra capa: una herramienta puede cambiar su definición después de aprobada, y el cliente solo se entera si alguien construyó la detección.

Por qué el problema es la confianza en herramientas mutables

MCP es el protocolo con el que los agentes de IA se conectan a herramientas y fuentes de datos. El agente pregunta "¿qué herramientas tienes?" y el servidor responde con una lista de nombres, descripciones y parámetros. El agente decide cuál usar y la invoca.

El problema está en el paso uno. Si el servidor cambia lo que devuelve en tools/list, el agente ve herramientas distintas, y actúa sobre lo que ve. Verificar que la definición sea la misma que se aprobó es trabajo del cliente, no del modelo.

Deadbugz explotó exactamente eso: tras tres llamadas normales, las respuestas siguientes traían definiciones con instrucciones maliciosas.

A esto se suman las vulnerabilidades de implementación. Un servidor MCP que devuelve tokens en texto claro o permite recorrido de rutas no necesita cambiar definiciones para ser peligroso: con las herramientas que ya expone, un atacante puede extraer datos o moverse lateralmente.

La recomendación de Pillar Security —tratar un cambio en la definición de herramientas como evento de seguridad— implica que el cliente del agente debe registrar qué herramientas vio la primera vez y alertar si la lista cambia. Pero eso es un control del lado del consumidor, no del protocolo. Y la mayoría de las implementaciones actuales no lo hacen.

Impacto para empresas en Panamá y LATAM

Una empresa regulada del sector financiero en Panamá no puede darse el lujo de que un agente de IA ejecute instrucciones no verificadas contra sus sistemas internos. La Ley 81 de 2019 exige medidas de seguridad proporcionales al riesgo sobre los datos personales. Un agente que accede a Jira, Confluence, bases de datos o repositorios de código está tocando datos personales, credenciales y configuraciones. El riesgo no es teórico.

Si el agente usa un servidor MCP vulnerable como los reportados en agosto de 2026, el operador del servidor puede extraer tokens, leer archivos del sistema o forzar peticiones desde la red interna. Si el agente se conecta a un servidor que cambia sus definiciones en caliente, como Deadbugz, el operador puede redirigir al agente a buscar credenciales y exfiltrarlas.

En ambos casos, la empresa regulada es responsable. Frente a la Ley 81, la pregunta que importa es si la empresa implementó medidas de seguridad proporcionales al riesgo, no de quién era el servidor. Conectar un agente a sistemas con datos personales sin verificar la integridad de las herramientas que usa no es una medida proporcionada.

Las empresas reguladas ya protegen secretos, auditan accesos y verifican identidades para las personas. Extender esos mismos criterios a los agentes de IA es la forma más directa de sostener, frente a un auditor, que las medidas siguen siendo proporcionales al riesgo.

Qué puede hacer su empresa hoy

1. Exija que cada petición de un agente a un sistema interno llegue con un token firmado que identifique a la persona que autorizó la acción. Sin identidad verificada, el conector debe rechazar la petición con error 401. Esto convierte al agente en un delegado auditado, no en un actor anónimo.

2. Implemente conectores que solo abran conexiones hacia afuera, detrás de un túnel con proveedor de identidad, sin puertos expuestos. Si el servidor donde viven los conectores no tiene puertos abiertos, un atacante no puede escanearlo ni conectarse directamente. El acceso entra por el túnel, autenticado, y el conector solo inicia conexiones salientes hacia los sistemas que necesita.

3. Guarde los secretos en una bóveda del servidor, léalos solo en el momento de usarlos y asegúrese de que ninguna herramienta los devuelva al modelo ni al chat. Si el modelo nunca ve una contraseña, un token o una llave SSH, no puede filtrarlos —ni por error ni por un ataque de cambio de definiciones como Deadbugz.

4. Haga que el modelo escriba referencias a datos sensibles y que el conector las resuelva en el servidor contra la fuente autorizada. El dato real nunca pasa por el chat ni por el modelo. Si el agente necesita consultar un número de cuenta, escribe una referencia como cuenta:123 y el conector lo resuelve del lado del servidor. El modelo solo ve la referencia.

5. Registre cada llamada del agente con herramienta invocada, persona que autorizó, timestamp y resultado, y trate cualquier cambio en la definición de herramientas de un servidor MCP ya aprobado como un evento de seguridad. Si un servidor que ayer ofrecía formateo de texto hoy ofrece búsqueda de credenciales, eso debe disparar una alerta y bloquear las nuevas herramientas hasta revisión humana.

Estas cinco acciones no dependen de un producto específico. Dependen de una arquitectura: identidad en cada petición, túnel sin puertos abiertos, bóveda de secretos, resolución de datos sensibles en el servidor y herramientas inmutables o verificadas. Cualquier empresa regulada puede implementarlas con componentes estándar del mercado; es el enfoque con el que trabajamos la adopción de IA.

Mi perspectiva

Lidero un equipo de ciberseguridad en Panamá y trabajo con empresas reguladas del sector financiero. Lo que vi en Deadbugz y en las vulnerabilidades de agosto de 2026 no me sorprendió: me confirmó que la arquitectura de conexión de agentes a sistemas internos es el problema central, no el modelo.

En las implementaciones que hacemos en Soluciones Etech, el servidor donde viven los conectores solo abre conexiones hacia afuera. El acceso entra por un túnel detrás de un proveedor de identidad, sin puertos abiertos. Cada petición llega con un token firmado que identifica a la persona; el conector la rechaza si falta. Los secretos viven en una bóveda del servidor, se leen en el momento de usarlos y ninguna herramienta los devuelve al modelo ni al chat. Para un cliente regulado, construimos un conector de pruebas automatizadas donde el modelo escribe una referencia al dato sensible y el conector la resuelve en el servidor contra la fuente autorizada: el dato real nunca pasa por el chat.

Esto no es teoría. Es la diferencia entre un agente que puede ser redirigido por un servidor MCP malicioso y un agente que, aunque el servidor cambie sus definiciones, no tiene secretos que entregar ni puertos abiertos que exponer.

La recomendación de Pillar Security —tratar el cambio de definiciones como evento de seguridad— es correcta, pero insuficiente si el agente ya tiene acceso irrestricto a secretos y sistemas. El control tiene que estar en la capa de conexión, no solo en la capa de protocolo.

Las empresas reguladas en Panamá están adoptando agentes de IA para tareas específicas. La pregunta no es si van a usarlos: es si la arquitectura de conexión va a estar a la altura de la regulación que ya cumplen en el resto de su operación. La Ley 81 no distingue entre un humano y un agente: exige medidas proporcionales al riesgo. Y el riesgo de un agente mal conectado es alto.

Preguntas frecuentes

¿Qué es MCP y por qué es relevante para la seguridad de los agentes?

MCP (Model Context Protocol) es el protocolo con el que los agentes de IA se conectan a herramientas y fuentes de datos. Es relevante porque define qué herramientas ve el agente y qué puede hacer con ellas: si un servidor MCP cambia sus definiciones sin control, el agente puede recibir instrucciones maliciosas sin que el usuario lo note.

¿Cómo evito que un agente de IA exponga datos sensibles de mi empresa?

Con tres controles: los secretos viven en una bóveda del servidor y se leen solo al usarlos, ninguna herramienta los devuelve al modelo ni al chat, y el modelo escribe referencias que el conector resuelve en el servidor contra la fuente autorizada. El dato real nunca pasa por el chat ni por el modelo.

¿Qué exige la Ley 81 de Panamá sobre el uso de agentes de IA con datos personales?

La Ley 81 de 2019 exige medidas de seguridad proporcionales al riesgo sobre los datos personales. La ley no enumera controles para agentes; para un agente con acceso a datos personales, esa proporcionalidad se sostiene con controles como identidad verificada en cada petición, auditoría de cada llamada y secretos fuera del alcance del modelo.

¿Su empresa ya usa IA? Hacemos un diagnóstico de gobernanza de IA de 45 minutos, sin costo, para empresas reguladas: qué modelo toca qué dato, dónde falta un control y qué evidencia pediría un auditor hoy. Agendar el diagnóstico