Seguridad de agentes de IA (AI agent security)
La seguridad de agentes de IA es la práctica de proteger software que decide por sí mismo su siguiente paso y actúa a través de herramientas, lo que lo convierte en un actor autónomo dentro de tus sistemas y no en una funcionalidad. Cubre la identidad y las credenciales propias del agente, hasta dónde puede llegar, la integridad de su memoria y de sus herramientas, y un registro de todo lo que hizo.
Cómo funciona
Un agente es un bucle. Se le da un objetivo, decide qué hacer a continuación, llama a una herramienta, lee el resultado y repite hasta que cree que el objetivo está cumplido. Las herramientas son lo que lo convierten en agente y no en una interfaz de chat: leer y escribir ficheros, consultar bases de datos, llamar a APIs internas, enviar correo, ejecutar código, abrir pull requests.
Desde el punto de vista de la seguridad, ese bucle crea un nuevo actor dentro de tu parque. Tiene credenciales, ejecuta acciones, toma decisiones entre pasos que nadie revisa, y se ve influido por cualquier texto que lea por el camino. Se parece más a un colaborador externo con acceso a los sistemas que a una biblioteca.
Hay cinco cosas que hay que asegurar, y la mayoría de los despliegues que revisamos ha atendido una.
La identidad: el agente se autentica como algo. Si ese algo es una cuenta de servicio compartida con permisos amplios, el agente es un permiso amplio. Las credenciales: cuáles tiene, dónde se guardan, y si están acotadas por usuario y por tarea o se emitieron una vez y se reutilizan para todo. La superficie alcanzable: el conjunto concreto de herramientas y datos, que debería poder enumerarse en lugar de decirse «la API interna». La integridad de lo que consume: su memoria, el contexto que recupera y las herramientas que carga, porque las tres son entradas en las que un atacante puede influir. Y la observabilidad: un registro de qué leyó, qué decidió y qué ejecutó, que es lo que hace investigable un incidente.
Qué sale mal
La ruta de compromiso que más usamos son las credenciales del propio agente, y el motivo es estructural. Los agentes necesitan acceso amplio para ser útiles, así que reciben una identidad de servicio capaz de llegar a muchos sistemas. Después actúan en nombre de muchos usuarios distintos con esa única identidad. Cualquiera que consiga influir en el agente, por el canal que sea, obtiene la unión de todo lo que el agente alcanza, y el rastro de auditoría registra la cuenta de servicio y no a la persona.
La segunda ruta son la memoria y el contexto. Un agente que guarda lo que aprende guardará lo que se le dijo, incluidas instrucciones plantadas para una sesión posterior. Envenenar una memoria persistente vale más que una inyección aislada, porque sobrevive a la conversación y afecta a otros usuarios. Lo mismo vale para un corpus de recuperación en el que puede escribir cualquiera de la organización: un documento es un mecanismo de entrega, y la inyección indirecta de prompt es el payload.
La tercera es la cadena de suministro de herramientas. Los agentes cargan definiciones de herramientas desde servidores, y una definición de herramienta es texto que el modelo lee: su nombre, su descripción, la documentación de sus parámetros. Un servidor de herramientas hostil o comprometido puede poner instrucciones ahí, y el modelo las lee antes de que el usuario haya escrito nada. Cuando los conectores los añaden usuarios individuales desde directorios públicos, la organización tiene una dependencia que no ha revisado nunca, y el envenenamiento de herramientas es la consecuencia directa. MCP ha vuelto sencillo conectar herramientas, lo que ha vuelto bastante más fácil equivocarse en esto.
La cuarta es que nadie puede reconstruir lo que pasó. Una transcripción de chat no es un registro de auditoría. No enseña qué documentos se recuperaron, qué llamadas a herramientas se hicieron, con qué parámetros, bajo qué identidad, ni cuáles tuvieron éxito. Sin eso, investigar un incidente consiste en preguntarle al modelo qué hizo, y eso no es evidencia.
Asistente y agente
La distinción decide qué controles aplican, y la difuminan los fabricantes que llaman agente a cualquier funcionalidad.
| Asistente | Agente | |
|---|---|---|
| Qué hace | Responde, redacta, resume | Decide una secuencia de pasos y los ejecuta |
| Actúa sobre los sistemas | No, o con confirmación explícita cada vez | Sí, de forma autónoma entre puntos de control |
| Tiene credenciales | Rara vez | Siempre |
| Radio de daño de una instrucción mala | Un texto equivocado | Acciones ejecutadas, datos movidos, cambios hechos |
| Controles que importan | Tratamiento de la salida, datos en el contexto | Identidad, herramientas acotadas, puertas de aprobación, registro |
| Modelo de revisión | El usuario lee la respuesta | Alguien tiene que revisar un plan, o no lo revisa nadie |
La cuestión es que añadir una sola llamada a una herramienta mueve un sistema de la columna izquierda a la derecha, y los controles de la columna derecha no suelen añadirse a la vez. En esa distancia están los hallazgos.
Errores frecuentes
Darle al agente una identidad de servicio compartida. Destruye la rendición de cuentas y les concede a todos los usuarios la unión de los permisos del agente.
Conceder acceso amplio a las herramientas porque es más fácil. «Leer cualquier fichero» y «llamar a cualquier endpoint interno» son las dos concesiones que convierten cualquier inyección en un incidente.
Tomar las funciones de seguridad del proveedor del modelo como el control. Se ocupan del contenido, no del acceso. No tienen ninguna visión de tu modelo de permisos.
Dejar que los usuarios instalen conectores libremente. Cada uno es código y texto entrando en el bucle desde fuera de tu proceso de revisión.
Registrar la conversación y nada más. Investigar exige la recuperación, las llamadas a herramientas, los parámetros y la identidad usada.
Cómo reducirlo
Dale al agente una identidad por usuario y por tarea, con los permisos de ese usuario y ninguno más, y haz que las credenciales sean de vida corta. Si la plataforma admite actuar en nombre de un usuario, úsalo. Si no lo admite, esa limitación es un hallazgo que merece quedar escrito en lugar de esquivarse.
Enumera las herramientas y haz que cada una sea estrecha. «Crear un ticket en este proyecto» es una herramienta. «Llamar a esta API HTTP» es una capacidad, y es agencia excesiva esperando una instrucción. Pon una puerta de aprobación humana delante de todo lo irreversible, externo o financiero, y haz que la pantalla de aprobación enseñe la acción concreta y no un resumen escrito por el modelo.
Trata la memoria y los corpus de recuperación como almacenes de confianza que necesitan integridad: controla quién puede escribir en ellos, revisa qué se guarda de forma automática, y acota la memoria por usuario para que una entrada envenenada no pueda llegar a todo el mundo.
Revisa los conectores antes de ponerlos a disposición, fija sus versiones y vuelve a revisarlos cuando cambien, porque la descripción de una herramienta puede cambiar sin que el comportamiento de la herramienta parezca cambiar. Es la disciplina corriente de cadena de suministro aplicada a un tipo nuevo de dependencia.
Registra el bucle entero: prompts, documentos recuperados, llamadas a herramientas con sus parámetros, identidades, resultados y aprobaciones. Y después alerta sobre las formas que importan, que son un agente leyendo mucho más de lo que la tarea exige, llamando a una herramienta que nunca había llamado para este usuario, o haciendo peticiones salientes a un destino que no está en el conjunto esperado.
Dónde aparece esto en una auditoría
Probamos un agente como a un interno con herramientas, no como a un chatbot. Las preguntas son qué identidad tiene, hasta dónde llega esa identidad, qué le puede poner delante un atacante y qué puede enviar hacia fuera. Los hallazgos se escriben contra la capacidad concreta y el dato concreto alcanzado, enseñando la cadena desde el contenido plantado hasta la acción ejecutada.
La evidencia es la traza: dónde plantamos la instrucción, qué recuperó el agente, a qué herramienta llamó, con qué parámetros y bajo qué identidad. Cuando el cliente no dispone de esa traza, esa ausencia es en sí misma un hallazgo, porque significa que un incidente no sería investigable.
La severidad sale del alcance y de la reversibilidad. Un agente que puede leer los tickets de un proyecto es un riesgo distinto de uno que sostiene una credencial de servicio para todo el parque, y un agente capaz de actuar de forma irreversible sin una puerta humana se trata como crítico por bien escritos que estén los prompts.
Esta es la segunda mitad de nuestro trabajo sobre sistemas que actúan por su cuenta, junto a la prompt injection, y es la mitad que suele faltar en las revisiones internas.
Preguntas frecuentes
¿En qué se diferencia la seguridad de agentes de IA de la seguridad de aplicaciones? La mecánica es conocida: identidad, permisos, tratamiento de la entrada, cadena de suministro, registro. Lo nuevo es que el componente que decide qué hacer a continuación se ve influido por el texto que lee, así que la premisa habitual de que los caminos de código son fijos deja de cumplirse.
¿Cuál es hoy el riesgo mayor con los agentes? Una identidad con permisos de más. A los agentes se les dan credenciales amplias para que sean útiles, y entonces cualquiera que consiga influir en ellos hereda esa amplitud. Acotar la identidad por usuario y por tarea aborda más riesgo real que cualquier ingeniería de prompts.
¿Hay que preocuparse por los servidores MCP? Sí, como dependencias. Un servidor de herramientas aporta texto que el modelo lee y código que se ejecuta en tu contexto. Revísalos, fija versiones, restringe cuáles pueden añadir los usuarios y trata un cambio en la descripción de una herramienta como un cambio de dependencia.
¿Se puede resolver el problema a base de registrar? No, y tampoco se puede investigar sin registros. El registro es lo que hace reconstruible un incidente; los controles que reducen el incidente son la identidad acotada, las herramientas estrechas y las puertas de aprobación.