Seguridad de los agentes de IA: 10 riesgos y cómo protegerse
Un agente de IA puede divulgar datos, ejecutar una acción no deseada o consumir más recursos de los previstos en el presupuesto. Su seguridad se basa en permisos limitados, ejecución aislada, aprobaciones para determinadas acciones y supervisión independiente del modelo. Estas medidas reducen las consecuencias de un error o de un ataque, aunque no garantizan que dejen de producirse.
Evaluar el riesgo a partir de los accesos reales
El peligro depende de las capacidades que se concedan al agente: leer documentos, modificar archivos, enviar mensajes, utilizar servicios o ejecutar código. Un objetivo aparentemente inofensivo puede implicar riesgos si las herramientas disponibles permiten acceder a gran parte de los sistemas de información.
El artículo Agente de IA o chatbot: ¿en qué se diferencian? explica por qué pasar de responder a actuar cambia las consecuencias de un error. Antes de elegir una medida de protección, haga un inventario de los datos accesibles, los destinos de red y las operaciones posibles.
| Ámbito | Datos accesibles | Acciones posibles | Protección prioritaria |
|---|---|---|---|
| Resumen de documentos | Carpeta seleccionada | Lectura y presentación de resultados | Limitar los documentos y sus destinatarios |
| Asistente de correo | Mensajes y contactos autorizados | Redacción de borradores y, en algunos casos, envío | Separar la redacción del envío |
| Agente de desarrollo | Código y entorno de trabajo | Modificación y ejecución | Aislar la ejecución y proteger los secretos |
| Automatización de procesos | Datos del servicio conectado | Creación o modificación de registros | Comprobar los permisos y los parámetros en el servicio |
Los diez riesgos que se presentan a continuación son una selección editorial. No están ordenados por frecuencia ni reproducen un marco oficial. Para revisar su configuración, el diagnóstico de seguridad de agentes de IA complementa este inventario.
Riesgos 1 y 2: instrucciones maliciosas y capacidades excesivas
1. La inyección de prompts desvía el objetivo
Una inyección de prompts introduce instrucciones maliciosas en el contenido que lee el modelo. El ataque puede proceder de un usuario, pero también de una página web, un correo electrónico o un documento consultado durante una tarea. OWASP describe este mecanismo y distingue, entre otras, las inyecciones directas de las indirectas.
Ejemplo hipotético: un agente encargado de resumir un archivo adjunto encuentra en él una petición para enviar documentos internos a una dirección externa. Si interpreta esa petición como una instrucción legítima, el contenido que debía analizar pasa a dirigir la tarea.
Protección: separe de forma explícita las instrucciones autorizadas del contenido que debe analizarse y limite las acciones que el agente puede realizar después de leerlo. Un filtro de texto puede ayudar a detectar algunos ataques, pero no debe ser la única barrera. Pruebe, en particular, cómo se comporta el agente cuando un documento le pide cambiar el destinatario o los permisos.
2. Los permisos excesivos agravan cualquier error
Un agente que resume documentos no necesita poder eliminarlos. Sin embargo, una conexión con acceso general a una cuenta puede darle esa capacidad. OWASP relaciona la autonomía excesiva con funciones, permisos o capacidades de decisión demasiado amplios.
Protección: aplique el principio de mínimo privilegio a cada herramienta: acceso de solo lectura cuando sea suficiente, carpetas concretas, una cuenta dedicada y operaciones autorizadas de forma explícita. Retire también los conectores que ya no sean necesarios.
Las restricciones deben aplicarse mediante el software y los servicios conectados. Pedir al modelo por escrito que nunca elimine archivos no resuelve el peligro si su cuenta sigue teniendo permiso para borrarlos.
Riesgos 3 y 4: filtración de datos y uso de permisos ajenos
3. La información confidencial sale del ámbito previsto
Una filtración no requiere descargar una base de datos completa. Puede bastar con incluir un fragmento de contrato en una consulta, enviar un archivo adjunto al destinatario equivocado o guardar un secreto en un registro.
Trace el recorrido de la información: fuente documental, modelo utilizado, herramientas intermedias, almacenamiento de conversaciones y registros. Distinga las transferencias necesarias para el funcionamiento de aquellas que podría desencadenar una acción del agente. Revise las condiciones del servicio antes de enviarle datos sensibles.
Protección: proporcione únicamente la información necesaria para la tarea. Guarde las credenciales técnicas en un gestor de secretos y, cuando la arquitectura lo permita, haga que el conector las utilice sin mostrárselas al modelo. Restrinja los destinos de red y oculte los datos sensibles en los registros.
Un asistente de correo permite ver los límites de estas medidas: retirar la herramienta de envío reduce una vía de filtración, pero un acceso general a la red puede dejar otras abiertas.
4. El agente actúa con los permisos de otra persona
En un servicio compartido, el agente puede utilizar una cuenta técnica con más permisos que la persona que solicita la tarea. Se convierte así en un intermediario capaz de obtener un documento o modificar un expediente al que esa persona no debería tener acceso.
La documentación de seguridad de MCP aborda, entre otras cuestiones, las confusiones de autorización y la validación de los tokens de acceso. El protocolo no sustituye los controles de identidad de las aplicaciones.
Protección: vincule cada operación con el usuario y la organización correspondientes. La aplicación de gestión debe comprobar sus permisos en el momento de ejecutar la acción, aunque la solicitud llegue a través de un agente reconocido. Utilice credenciales distintas para cada función y prevea cómo revocarlas.
Una prueba útil consiste en solicitar, desde una cuenta de prueba, un documento reservado a otra cuenta. El rechazo debe proceder del sistema de autorización, con independencia de lo que responda el modelo.
Riesgos 5 y 6: extensiones comprometidas y ejecución peligrosa
5. Un servidor MCP o una habilidad introduce código malicioso
Añadir un conector, una habilidad o una dependencia amplía la cadena de software de la que depende el sistema. Un nombre que inspira confianza, una descripción convincente o una gran popularidad no demuestran que el componente respete los límites que usted ha establecido.
El trabajo de OWASP sobre las amenazas de la IA agéntica incluye los ataques que comprometen la cadena de suministro. Esta amenaza también afecta a los recursos que el agente carga después de su instalación inicial.
Protección: compruebe la identidad de quien mantiene el componente, el repositorio de referencia, los permisos solicitados y las dependencias. Revise con especial atención los scripts que se ejecutan durante la instalación y los accesos a la red. En un entorno sensible, valide una revisión concreta y someta las actualizaciones a una nueva comprobación.
Instale primero el componente en un entorno sin datos confidenciales. Compruebe cómo se comporta antes de darle acceso a las cuentas reales. El artículo sobre servidores MCP y habilidades maliciosas explica esta revisión con más detalle.
6. El código generado se ejecuta fuera de un entorno controlado
Un agente con acceso a una terminal puede ejecutar programas, modificar archivos e instalar dependencias. Una orden sintácticamente correcta puede borrar datos o transmitir un secreto. Por tanto, revisar el código generado no basta para establecer un límite de seguridad.
Protección: ejecute las tareas en un entorno aislado o sandbox, con una cuenta sin privilegios de administración, una carpeta de trabajo dedicada y conexiones salientes controladas. Monte únicamente los directorios necesarios y evite exponer las credenciales de su sesión habitual.
Anthropic explica en su presentación técnica del sandboxing por qué el aislamiento debe abarcar tanto el sistema de archivos como la red. Compruebe qué bloquea realmente su entorno: un contenedor con acceso amplio al equipo anfitrión puede conservar capacidades peligrosas.
Riesgos 7 y 8: memoria contaminada y acciones mal validadas
7. Una instrucción maliciosa queda guardada en la memoria
Una instrucción encontrada durante una tarea puede almacenarse en notas, un perfil de usuario o una base documental. Si vuelve a utilizarse después, el problema persiste aunque el documento original ya no esté disponible.
El envenenamiento de la memoria figura entre las amenazas estudiadas en el marco de OWASP sobre IA agéntica mencionado anteriormente. Por eso hay que examinar qué se guarda en la memoria, qué se recupera de ella y para qué usuario.
Protección: separe las preferencias aprobadas de forma explícita, las observaciones de trabajo y el contenido externo. Conserve su procedencia y su fecha de registro. Permita consultar y eliminar entradas concretas.
Una sugerencia procedente de una página no debería convertirse automáticamente en una regla permanente. Como prueba, haga que el agente guarde un dato inofensivo pero incorrecto y compruebe después que puede localizarlo, corregirlo e impedir que vuelva a utilizarse. Las memorias compartidas también deben respetar la separación entre usuarios.
8. Una respuesta convincente desencadena una operación incorrecta
Un nombre de cliente mal interpretado, una ruta de archivo equivocada o un parámetro ausente pueden convertir una respuesta convincente en una acción perjudicial. OWASP describe los riesgos de validar de forma insuficiente las salidas cuando se transmiten a otros componentes.
Protección: exija parámetros estructurados y compruebe sus valores en la aplicación: destinatario autorizado, importe aceptable, archivo situado en la carpeta prevista y operación compatible con el estado actual. Para una base de datos, utilice consultas parametrizadas y permisos adecuados.
Antes de una acción sensible, muestre los parámetros que se utilizarán realmente: contenido que se enviará, destinatarios, archivos adjuntos, modificación propuesta y consecuencia prevista. Un resumen redactado por el modelo no sustituye esa vista previa.
La aprobación debe corresponder a la acción que se ejecutará. Si los parámetros cambian después, solicite una nueva aprobación. Para los borrados y las modificaciones importantes, prevea también un procedimiento de restauración cuyo funcionamiento pueda comprobarse.
Riesgos 9 y 10: gastos sin control e incidentes invisibles
9. Un bucle agota el presupuesto o satura el servicio
Un agente puede repetir un intento, volver a utilizar una herramienta que falla o delegar trabajo sin avanzar. Un atacante también puede aprovechar los recursos disponibles. OWASP documenta el consumo sin límites como un riesgo para la disponibilidad y los costes.
Protección: establezca límites por tarea y por usuario: duración, llamadas, gasto, tamaño de las entradas y tareas simultáneas. La aplicación que coordina al agente debe controlar estos límites.
Defina una condición de parada cuando no haya progreso o se repitan los errores. El presupuesto debe incluir los servicios de pago que se utilizan junto con el modelo, como la ejecución remota o las búsquedas de pago. Compruebe también si el umbral anunciado por un proveedor bloquea el gasto o solo envía una alerta.
10. El incidente pasa inadvertido y se propaga
Sin registros útiles, no podrá saber qué herramienta actuó, sobre qué datos ni con qué autorización. Una automatización posterior puede utilizar el resultado incorrecto y prolongar el problema.
Protección: registre la identidad de quien solicita la tarea, las herramientas utilizadas, las aprobaciones, los resultados y los errores. Limite el acceso a los registros y evite copiar en ellos documentos completos o secretos. Su propio contenido puede llegar a ser sensible.
Configure alertas para destinos poco habituales, fallos repetidos y cambios de permisos. La guía para supervisar un agente de IA en producción profundiza en la organización de estos controles.
Por último, designe a una persona capaz de detener el agente y revocar sus accesos. El botón de parada debe impedir nuevas acciones, incluidas las que ya estén en cola cuando el sistema lo permita. Pruebe este comportamiento antes de asignarle una tarea sensible.
Poner a prueba las protecciones antes del despliegue
Empiece con datos ficticios y cuentas de prueba. Describa las acciones permitidas, las prohibiciones y las situaciones que requieren aprobación humana. El resultado esperado debe ser observable: acceso denegado, operación bloqueada o tarea interrumpida.
Después, someta al agente a situaciones en las que algo falle. Preséntele un documento con una instrucción contradictoria, solicite un archivo fuera del ámbito autorizado y provoque el fallo de una herramienta. Compruebe que el agente no busque un acceso más amplio para sortear el obstáculo y que la aplicación bloquee efectivamente ese intento de superar los límites.
Pruebe también la recuperación. Una copia de seguridad solo ofrece protección operativa si la restauración funciona. En el caso de un mensaje enviado o de información divulgada, puede ser imposible volver atrás: la prevención y la limitación del alcance adquieren entonces mayor peso.
Documente los resultados y las limitaciones conocidas. Repita estas comprobaciones después de cambiar el modelo, un conector o los permisos, porque el comportamiento del sistema puede variar aunque el objetivo siga siendo el mismo. La guía para proteger un agente de IA permite convertir estos principios en una configuración detallada.
Antes de permitir el acceso a datos reales:
- Los accesos se ajustan a las necesidades de la tarea y utilizan cuentas dedicadas.
- Las acciones sensibles muestran los parámetros que se utilizarán antes de solicitar aprobación.
- La ejecución, los destinos de red y los gastos tienen límites aplicados mediante controles técnicos.
- Las memorias y los registros pueden consultarse sin exponer secretos.
- Se han comprobado la parada, la revocación de accesos y la restauración.
Puntos clave
- El riesgo depende de las herramientas, los datos y los permisos concedidos al agente.
- Una instrucción escrita para el modelo debe complementarse con restricciones aplicadas en los sistemas conectados.
- La aprobación humana resulta útil cuando presenta una acción concreta y comprensible.
- Las protecciones deben probarse y revisarse cuando cambie la configuración.
Preguntas frecuentes
¿Un agente de IA que se ejecuta en local es siempre seguro?
La ejecución local reduce algunas transferencias a proveedores, pero no limita automáticamente el acceso a los archivos ni a la red. Revise también los conectores, la telemetría y los servicios remotos que se utilizan durante una tarea.
¿Basta con un antivirus para proteger un agente de IA?
Un antivirus puede detectar determinados archivos maliciosos, pero una acción peligrosa puede utilizar una API autorizada sin instalar ningún programa. Por eso también es necesario controlar las identidades, los permisos y las operaciones permitidas.
¿Se puede dejar que un agente de IA trabaje sin supervisión?
Depende del alcance autorizado y de las consecuencias de un error. Una tarea acotada, reversible y con controles técnicos de supervisión puede admitir más autonomía que otra con acceso a cuentas de clientes o medios de pago.
¿Cómo evaluar la seguridad de un agente de IA antes de instalarlo?
Pregunte dónde se aplican los controles, qué accesos necesita el agente y cómo revocarlos. Una demostración en la que se bloquea una acción prohibida aporta más información que una simple declaración de seguridad.