Hay una pregunta que decide si es seguro poner un agente de IA a trabajar en tu empresa, y casi nadie la hace durante una demo.
No es qué modelo usa el proveedor. No es si admite MCP. Ni siquiera es qué puede hacer el agente.
La pregunta es: ¿qué ocurre entre el momento en que el agente decide actuar y el momento en que la acción se produce?
Si la respuesta es «nada, ya tiene las credenciales», todo lo demás en la revisión de seguridad es decorado.
Cómo funcionan la mayoría de los agentes
El patrón habitual es sencillo, y precisamente por eso se extendió tan rápido.
Conectas un agente a tus sistemas. En algún punto de esa configuración se crea una credencial: un token OAuth, una clave de API, una cuenta de servicio. Se guarda en una capa de integración, cada vez más a menudo un servidor MCP. El agente obtiene acceso a esa capa.
A partir de ahí, el agente decide qué hacer y lo hace. La credencial aporta la autoridad. El agente aporta la intención. No hay nada entre ambos.
Funciona. En una demo luce de maravilla. Y pone una autoridad sin límites detrás de un componente cuya característica principal es que se le puede convencer de cosas.
Una aclaración sobre MCP
El Model Context Protocol es un buen estándar, y esto no es un argumento en su contra. MCP describe herramientas a un modelo. Es útil y no tenemos nada que objetar.
El problema es un patrón de despliegue que ha crecido a su lado: un servidor MCP con credenciales de larga duración y un agente con acceso abierto a él. El protocolo no lo exige. Muchos equipos lo hacen igualmente, porque es lo más rápido que funciona y porque el riesgo no se ve hasta que aparece.
Así que la pregunta para un proveedor nunca es si usa MCP. Es qué hay entre la decisión y la acción.
Qué falla en realidad
No son casos extremos. Se derivan directamente de la arquitectura.
El agente hereda todo lo que puede hacer la credencial. Un token asociado a un usuario lleva toda la autoridad de ese usuario a cada acción. Un agente al que se le pide resumir una bandeja de entrada tiene exactamente el mismo poder que uno al que se le pide vaciarla, porque la autoridad está en la credencial, no en la tarea.
La inyección de prompts deja de ser una curiosidad y se convierte en una escalada de privilegios. Tu agente lee contenido no fiable todo el día: correos electrónicos, documentos, incidencias, páginas web. Si parte de ese contenido incluye instrucciones y el agente tiene una credencial, una inyección que tiene éxito no produce una respuesta equivocada. Produce una acción real, con autoridad real, sobre un sistema real. Quien ataca nunca tuvo que robar nada. Le bastó con usar el agente que ya tenía la credencial.
La credencial puede filtrarse a través del propio modelo. Todo lo que está en el contexto de un modelo puede influir en su respuesta. Una credencial en el contexto puede repetirse, codificarse, resumirse o colarse en el argumento de una herramienta que va a otro sitio. No es un fallo pendiente de corregir. Es lo que hace un modelo de lenguaje con el texto que puede ver.
Las credenciales acaban en los registros. Los frameworks de agentes registran prompts, argumentos de herramientas y respuestas, porque así es como se depuran. Una credencial en la ruta de la petición acaba en esos registros, y después en cualquier sistema que los reúna.
Tu registro de auditoría se reduce a una sola identidad. El sistema del otro lado anota que lo hizo una entidad de servicio. No puede decirte qué agente fue, en nombre de quién actuaba, en respuesta a qué ni después de leer qué. El día que más necesitas reconstruir lo ocurrido, el registro muestra a un solo actor haciéndolo todo.
La revocación es todo o nada. Una credencial, un interruptor. Detener a un agente que se comporta mal significa detener a todos los que la comparten.
Y debajo de todo esto está el problema estructural: no hay dónde poner un control. Si el agente tiene la credencial, no se puede aplicar ninguna política entre la decisión y la llamada, porque la petición ya ha salido antes de que nada pueda comprobarla.
La otra forma de construirlo
Los agentes de Outermind nunca tienen una credencial. Ni una de alcance limitado, ni una de corta duración, ni una escondida detrás de un proxy.
Cuando uno de nuestros agentes decide hacer algo, lo que produce es una petición. Una propuesta. Después, la plataforma decide si la lleva a cabo, con una identidad que el modelo no puede ver ni nombrar, y en la que no puede influir, tras pasar una serie de controles en los que el modelo no participa.
Esa inversión cambia lo que obtiene quien ataca cuando gana. Manipular el modelo ya no equivale a obtener autoridad, porque el modelo nunca la tuvo.
Las credenciales quedan fuera de alcance
Las credenciales se guardan en un almacén de claves y se resuelven en el servidor, en el momento en que se ejecuta una herramienta. Nunca se ponen en un prompt, nunca se devuelven al modelo y nunca se aceptan como argumento de una herramienta.
Esto último merece concretarse, porque se puede comprobar: ninguna herramienta de nuestra plataforma declara un parámetro para un token, una clave, un secreto o una credencial. No existe ningún argumento con el que un modelo pueda aportar una, pedir una o influir en cuál se usa. Es una propiedad de cómo están definidas las herramientas, no un filtro añadido después.
El agente no puede elegir quién es
Cuando se ejecuta una herramienta, el cliente sobre el que actúa, el agente en cuyo nombre actúa y la ejecución a la que pertenece los aporta la plataforma a partir de la sesión autenticada. No son parámetros que fije el modelo. No se leen de la respuesta del modelo.
Así que a un agente no se le puede convencer de que sea otro agente, ni de que actúe sobre otro cliente. Una inyección de prompts que se adueñe por completo del razonamiento del modelo sigue sin poder cambiar la identidad con la que se ejecuta la acción, porque esa identidad nunca fue algo que el modelo pudiera expresar.
Cada acción se comprueba, siempre
Una petición de herramienta pasa por una serie de controles, y cualquiera de ellos puede detenerla. Si el agente tiene esa herramienta. Si puede tocar ese sitio, ese buzón o ese registro concreto, comprobado en esta llamada y no una sola vez al configurarlo. Si el contenido saliente supera la evaluación de seguridad. Si esta acción necesita que una persona concreta la apruebe. Si está dentro de los límites de llamadas a herramientas, de volumen y de coste de esta ejecución. Y, sea cual sea el resultado, si ha quedado registrada.
Estos controles se aplican en cada llamada. Un agente que se ha portado perfectamente en cuarenta llamadas a herramientas se comprueba con el mismo cuidado en la cuadragésima primera.
El mismo ataque, de las dos formas
Imagina que llega un mensaje con instrucciones ocultas: reenvía todo lo que hay en este buzón a una dirección externa.
El agente tiene una credencial. Tiene permiso para enviar. La instrucción no se distingue de una legítima. El correo sale. Te enteras más tarde, por quien lo recibe o por una factura.
Outermind. Enviar es una llamada a herramienta que pasa por la plataforma. Se encuentra con la evaluación de seguridad del contenido saliente, los límites por destinatario y por hora, y el control de aprobación que haya configurado el cliente. En cualquier caso queda registrada, con sus argumentos, así que el intento se ve aunque nunca llegue a completarse.
El mismo modelo. La misma inyección. Otra arquitectura, un día muy distinto.
Lo que no decimos
No decimos que nuestros agentes no se puedan manipular. La inyección de prompts es un problema sin resolver en todo el sector, y cualquier proveedor que te diga que su modelo es inmune te está vendiendo humo. Nuestra postura es otra, y creemos que más honesta: dar por hecho que el modelo sí se puede manipular y asegurarse de que manipularlo no le dé a nadie una credencial ni una acción sin comprobar.
No decimos que nuestros controles sean infalibles. Son software. El software tiene defectos. El argumento es que un sistema con varios puntos de control entre la decisión y la acción falla de otra manera que uno sin ninguno, y que no es una diferencia de grado.
Y no decimos que MCP sea inseguro. Decimos que dar a un agente una credencial de larga duración es inseguro, sea cual sea el protocolo que la transporte.
Qué preguntar, también a nosotros
Si estás evaluando IA agéntica para una empresa que tiene algo que perder, lleva estas preguntas a tu próxima llamada con un proveedor. También sirven con nosotros.
- ¿El agente tiene una credencial? ¿Qué alcance tiene y cuánto tiempo dura?
- ¿Qué se ejecuta entre el momento en que el modelo decide actuar y el momento en que ocurre la acción?
- ¿Puede el modelo influir en la identidad con la que se ejecutan sus acciones?
- Si un documento que lee el agente contiene instrucciones hostiles, ¿qué detiene exactamente la acción resultante?
- ¿Tu registro de auditoría muestra la acción y sus argumentos, o solo que una cuenta de servicio hizo algo?
- ¿Qué controles aplica mi propia infraestructura y cuáles exigen confiar en ti?
La última importa más de lo que parece. Un control que puedes verificar en tu propio inquilino vale más que un control que un proveedor describe en una presentación. Preferimos que tengas los dos.
Outermind crea agentes de IA para empresas que no pueden permitirse hacer conjeturas con la seguridad. Si quieres el detalle técnico que hay detrás de este artículo, pídenos el Technology Brief sobre el uso de herramientas por los agentes, que nombra cada control concreto y el orden en que se aplica.