La adopcion de agentes de IA esta cambiando la conversacion de seguridad. Un chatbot responde. Un agente observa contexto, decide pasos, llama herramientas, consulta APIs, lee documentos y puede ejecutar acciones sobre sistemas reales. Esa diferencia convierte a la IA en una nueva superficie operacional.
El Model Context Protocol, conocido como MCP, acelera esta transicion porque estandariza la forma en que asistentes y agentes se conectan con herramientas y fuentes de datos. Esa estandarizacion es poderosa: reduce friccion, evita integraciones a medida y permite componer ecosistemas de agentes. Pero tambien introduce una pregunta incomoda: que pasa cuando el modelo ya no solo lee informacion, sino que puede actuar sobre ella?
La hipotesis
La hipotesis de esta investigacion es simple: las organizaciones no deberian evaluar agentes de IA como si fueran interfaces conversacionales. Deben evaluarlos como software con permisos, identidad, dependencias, conectores, logs, controles de acceso y riesgo de cadena de suministro.
El prompt sigue importando, pero ya no alcanza. Cuando hay herramientas conectadas, el riesgo se desplaza hacia metadatos, permisos, procedencia de datos, tool calls, resultados no confiables y decisiones automatizadas que pueden parecer legitimas.
Tool poisoning: cuando la herramienta miente antes de ejecutarse
Una investigacion de marzo de 2026 sobre MCP aplica threat modeling con STRIDE y DREAD a componentes como host, cliente, LLM, servidores MCP, data stores externos y servidores de autorizacion. Su hallazgo mas relevante es que el tool poisoning aparece como una vulnerabilidad prevalente e impactante del lado cliente.
El problema es elegante y peligroso: una herramienta puede describirse a si misma con metadatos que contienen instrucciones maliciosas o ambiguas. El agente lee esos metadatos para decidir como usar la herramienta. Si no existe validacion suficiente, una descripcion envenenada puede influir en el razonamiento del modelo antes de que el usuario vea el riesgo.
En seguridad tradicional, esto se parece a confiar demasiado en un paquete, plugin o dependencia. En agentes de IA, la dependencia no solo se instala: tambien conversa con el modelo.
Prompt injection indirecta: el dato se disfraza de instruccion
La prompt injection indirecta aparece cuando el agente procesa contenido externo que contiene instrucciones hostiles: una pagina web, un ticket, un correo, un documento compartido o una respuesta de una API. El usuario no escribe el ataque. El agente lo encuentra mientras trabaja.
Esto rompe una intuicion comun: no basta con entrenar al usuario para que no escriba prompts peligrosos. El agente puede traer el peligro desde fuera. Si ese contenido se mezcla en el mismo contexto que las instrucciones del sistema, el modelo puede confundir datos no confiables con ordenes.
MCP como oportunidad y como riesgo
MCP no es "el problema". El problema es desplegar ecosistemas de herramientas sin una arquitectura de seguridad proporcional. MCP puede ordenar integraciones, pero tambien puede facilitar que una mala herramienta, un servidor mal configurado o un cliente poco transparente amplifique el riesgo.
Por eso la respuesta no deberia ser bloquear toda adopcion. La respuesta deberia ser madurar controles: identidad de agentes, autorizacion granular, permisos minimos, auditoria, validacion de metadatos, procedencia de herramientas, aislamiento de contexto y aprobacion humana para acciones sensibles.
La propuesta SMCP
El paper SMCP: Secure Model Context Protocol propone una extension de seguridad a nivel de protocolo. Sus piezas centrales son identidad unificada, autenticacion mutua, propagacion continua de contexto de seguridad, politicas finas y logging integral. Esa direccion es correcta porque mueve la seguridad desde recomendaciones sueltas hacia una capa sistemica.
En una empresa, esto se traduce en preguntas concretas: que identidad tiene el agente, bajo que usuario actua, que herramientas puede descubrir, que acciones puede ejecutar, que datos puede leer, que permisos hereda y que queda registrado para auditoria.
Matriz de evaluacion para agentes conectados
- Identidad: cada agente debe tener identidad propia, no operar como usuario generico.
- Permisos: aplicar minimo privilegio por herramienta, accion y contexto.
- Procedencia: validar de donde vienen herramientas, prompts, documentos y resultados.
- Separacion: no mezclar instrucciones confiables con contenido externo no confiable.
- Auditoria: registrar decisiones, tool calls, parametros, respuestas y aprobaciones.
- Transparencia: mostrar al usuario que herramienta se va a usar y con que parametros.
- Sandboxing: ejecutar acciones riesgosas en entornos limitados o reversibles.
- Supervision: pedir confirmacion humana para pagos, borrados, envios, cambios de permisos o acciones legales.
Lectura para empresas chilenas y latinoamericanas
El riesgo regional no es que falte entusiasmo por la IA. El riesgo es conectar agentes a sistemas reales con la misma liviandad con que se prueba un chatbot. Muchas organizaciones todavia tienen cuentas compartidas, permisos amplios, baja observabilidad, APIs internas sin buena segmentacion y documentacion dispersa. Un agente encima de esa base puede aumentar productividad, pero tambien amplificar errores.
La adopcion responsable no significa frenar innovacion. Significa decidir donde un agente puede leer, donde puede sugerir, donde puede ejecutar y donde debe pedir autorizacion. Esa diferencia entre asistir y actuar es la nueva frontera de la gobernanza de IA.
Conclusion
La seguridad de agentes no se resuelve con prompts mas duros. Se resuelve con arquitectura. MCP y los agentes conectados obligan a traer al mundo de la IA conceptos clasicos de seguridad: identidad, permisos, aislamiento, logging, monitoreo y defensa en profundidad.
El agente puede razonar, pero la organizacion debe decidir que puede tocar.
Comentarios
Deja tu comentario
No hay comentarios aprobados todavía. ¡Sé el primero en comentar!