Seguridad en herramientas MCP: cuando la IA es el atacante
En un sistema MCP el atacante no es un usuario en un formulario de login: es el asistente de IA, actuando sobre instrucciones inyectadas.
Cuando conectás un asistente de IA para ejecutar herramientas, el modelo de amenaza se invierte. El atacante no es un usuario en un formulario de login — es el asistente mismo, actuando sobre instrucciones inyectadas.
La configuración
Una plataforma de operaciones interna exponía un conjunto de herramientas que la IA podía llamar: leer notificaciones, listar sitios, obtener tokens de compartir. Cuatro de ellas se entregaron sin control de acceso. Eso es un gap crítico por sí mismo, pero el fallo más interesante es estructural.
Cuando la herramienta es el atacante
La inyección de prompts convierte al asistente en el vector de ataque. Un tercero puede envenenar el contexto y hacer que el asistente llame a una herramienta sensible en su nombre. La corrección debe asumir que la herramienta de confianza está comprometida.
Aplicamos una doble capa: un gate de rol en las herramientas sensibles, plus scope por organización para que cada llamada solo toque datos que el llamador posee. Una herramienta no tenía clave de organización, así que se volvió solo-admin en vez de con scope.
La lección que me sorprendió
Una lista estática de "herramientas sensibles" produjo falsos positivos. Una herramienta ya se scpeaba al ID del llamador, así que el gate global bloqueó llamadas inofensivas. El mecanismo real es scope por handler, no una lista constante.
Defensa en profundidad: llamadores sin privilegios se auto-scpean a sus propios datos; herramientas sensibles requieren un rol; todo lo demás hereda límites de organización. Ver el caso de estudio V5 Hub.