Dar a un agente de inteligencia artificial acceso al correo, los documentos o una herramienta de la empresa cambia la naturaleza del problema. Ya no estamos evaluando únicamente si responde bien: también debemos pensar en lo que puede hacer con esa información. Un error puede dejar de ser una frase absurda en un chat y convertirse en un correo enviado, un archivo compartido o un dato que sale de donde no debería.
Estamos pasando de pedir a la IA que nos cuente cosas a permitir que actúe. Por eso, además de preguntar si es suficientemente inteligente, necesitamos entender qué le estamos dejando hacer, quién ha autorizado esas acciones y qué límites se mantienen cuando algo no está claro.
Leer un documento no debería significar obedecerlo
Imagina que una persona de tu equipo abre un documento de un proveedor y encuentra una frase que le pide enviar la lista de clientes a una dirección. Lo razonable sería comprobar quién lo solicita, por qué lo necesita y si tiene permiso. El documento puede aportar información para el trabajo, pero no se convierte en una autoridad por el simple hecho de que alguien lo haya abierto.
En una IA, esa separación puede fallar: un texto que debía analizar se interpreta como una instrucción que debe cumplir. A este problema se le llama inyección de instrucciones, o prompt injection. No requiere necesariamente una pantalla llena de código ni una orden extravagante; puede aparecer como una petición normal dentro del material que el sistema está leyendo.
El riesgo puede crecer cuando intervienen varias piezas. Si un agente transmite la petición a otro y este da por supuesto que viene autorizada, una instrucción externa empieza a circular como si fuera una decisión interna. Es un problema bastante humano: confiar en una solicitud porque la transmite alguien de dentro, sin comprobar de dónde salió.
Las conexiones también necesitan límites
El 5 de octubre, Ars Technica publicó una investigación sobre fallos en sistemas conectados mediante MCP, las siglas de Model Context Protocol. Este estándar permite conectar aplicaciones de IA con herramientas y datos. Lo importante, más que memorizar el nombre, es comprender qué ocurre cuando la información y las peticiones pasan de un componente a otro.
Una pieza puede recibir información, otra decidir qué hacer y otra disponer de acceso a un servicio. Si cada una da por válida la petición anterior sin comprobar su origen y alcance, una instrucción externa puede terminar utilizando permisos internos. El investigador Syed Anas Mohiuddin describe ese movimiento entre fronteras de confianza y documenta también errores en servidores que aceptaban peticiones hacia destinos que deberían haber restringido.
Estos casos no demuestran que todos los agentes estén comprometidos ni que MCP obligue a confiar en cualquier petición. Son fallos de sistemas e implementaciones que deben diseñarse y revisarse, y la propia documentación de seguridad de MCP incluye medidas contra varios de esos riesgos. La conclusión útil no es desechar la tecnología, sino dejar de tratar los permisos como un detalle secundario de la instalación.
Más inteligencia no sustituye a una autorización
Podemos utilizar otro modelo para revisar solicitudes sospechosas y detectar señales de riesgo. Esa ayuda, sin embargo, no debería fabricar un permiso que nadie ha dado. Que una IA considere una acción segura no significa que esté autorizada a enviar datos, publicar contenido o cambiar una cuenta.
Los límites deben existir también en las capacidades del sistema: qué cuentas puede utilizar, qué información puede consultar y qué acciones necesitan una aprobación. Consultar un archivo y compartirlo son dos capacidades distintas. Del mismo modo, un agente que resume facturas no necesita poder modificar todas las cuentas para cumplir su tarea.
Mi criterio para empezar sería separar lectura y acción, dar acceso solo a lo necesario y reservar la revisión humana para lo que cuesta deshacer: enviar, publicar, borrar, pagar o revelar información sensible. Esa revisión tiene que mostrar la acción concreta y sus destinatarios o efectos, en lugar de pedir un «sí» a ciegas. También conviene dejar un rastro que permita responder qué ocurrió, sin acumular registros que nadie sabe interpretar.
Saber parar forma parte de hacer bien el trabajo
La promesa de un agente que nunca se detiene puede resultar atractiva, pero merece desconfianza. Cuando no está claro si puede continuar, detenerse para comprobar el permiso es parte de un comportamiento útil. Lo contrario puede funcionar en una demostración y causar problemas cuando hay clientes, dinero o información privada de por medio.
La confianza no consiste en entregar todas las llaves, sino en entender los límites dentro de los que trabaja el sistema. Antes de ampliar su autonomía, conviene poder explicar qué puede leer, qué puede cambiar, quién decidió esos permisos y en qué situaciones debería negarse a seguir. Si esas preguntas no tienen una respuesta clara, más inteligencia no resuelve lo que falta.
Deja una respuesta