Seguridad de agentes de IA: 7 controles para contenerlos
OpenAI refuerza la contención de sus agentes. Traducimos el modelo a siete controles prácticos: aislamiento, permisos, red, credenciales, registros, parada y red-teaming.
Un agente de inteligencia artificial no solo responde preguntas: puede abrir archivos, ejecutar código, consultar servicios y actuar con credenciales. Por eso su seguridad no puede depender de una instrucción del tipo “no hagas nada peligroso”. El 23 de octubre de 2026, OpenAI explicó cómo ha reforzado la contención de sus entornos de entrenamiento mediante aislamiento por capas, control de red, monitorización y pruebas adversarias a gran escala. Es un caso extremo, pero deja una lección útil para cualquier empresa: la capacidad del agente y su autoridad deben tratarse como dos cosas distintas.
Esta guía convierte esa arquitectura en siete controles prácticos para desplegar agentes de IA con menor riesgo. No hace falta operar un laboratorio de modelos frontera para aplicar privilegio mínimo, separar credenciales, limitar la salida a internet, registrar acciones y disponer de un mecanismo de parada.
Qué ha cambiado y por qué importa
El informe “Securing our frontier model training environment” describe una política de entrenamiento sin acceso directo a internet, un “mundo offline” de contenido cacheado, contenedores dentro de microVM, controles de red y nube, monitorización y campañas continuas de red-teaming. OpenAI relata que sus agentes de prueba encontraron vulnerabilidades, configuraciones débiles, rutas indirectas hacia internet y canales laterales de comunicación entre tareas aisladas.
La situación de una pyme es menos exigente que la de un laboratorio de modelos frontera, pero el patrón se repite. Un agente conectado al correo, CRM, almacenamiento, repositorios o facturación acumula capacidad para leer, transformar y enviar información. Un error de configuración, una inyección indirecta en un documento o una herramienta comprometida pueden convertir una tarea legítima en una acción no autorizada.
Qué puede salir mal en un agente empresarial
Antes de elegir controles hay que describir el recorrido completo: qué recibe el agente, qué decide, qué herramientas invoca, con qué identidad actúa y dónde guarda resultados. Los fallos más frecuentes no requieren un modelo “malicioso”; basta con una instrucción ambigua, datos contaminados o permisos demasiado amplios.
| Riesgo | Ejemplo empresarial | Control prioritario |
|---|---|---|
| Inyección indirecta | Un PDF o una web contiene órdenes ocultas para extraer datos. | Separar contenido no fiable, validar salidas y limitar herramientas. |
| Exceso de privilegios | El agente puede editar todo el CRM para completar una sola ficha. | Identidad propia y permisos por tarea. |
| Fuga por red | Un proceso envía información a un dominio no autorizado. | Lista de destinos permitidos y proxy de salida. |
| Exposición de secretos | Una clave aparece en el prompt, registro o archivo temporal. | Inyección de credenciales fuera del contexto y rotación. |
| Acción irreversible | El agente borra, publica o paga sin revisión humana. | Aprobación previa, límites y modo borrador. |
| Falta de trazabilidad | No se sabe qué usuario inició una acción ni qué herramienta la ejecutó. | Registro inmutable con identidad, intención y resultado. |
NIST subraya en su análisis sobre identidad y autorización de agentes que compartir credenciales rompe la rendición de cuentas. La recomendación práctica es asignar una identidad distinguible a cada agente o flujo, vinculada a la persona o servicio que lo inicia y revocable sin afectar a toda la organización.
Los siete controles esenciales
1. Definir una frontera de seguridad verificable
Documenta qué recursos están dentro de la tarea: carpetas, bases de datos, dominios, APIs y acciones. Todo lo demás queda fuera. La frontera debe existir en políticas técnicas —permisos, red, sistema de archivos y herramientas—, no solo en instrucciones de lenguaje natural. Empieza con un agente que prepara borradores; concede publicación o escritura únicamente cuando el caso esté medido.
2. Ejecutar en un entorno aislado y desechable
Usa contenedores o máquinas virtuales con una imagen mínima, sistema de archivos temporal y sin acceso al host. Reinicia el entorno entre tareas sensibles y evita montar carpetas completas “por comodidad”. Para procesos que ejecutan código o navegan, el aislamiento debe impedir que una vulnerabilidad en una herramienta exponga el servidor que la hospeda.
3. Aplicar privilegio mínimo por herramienta y por acción
No basta con dar al agente la cuenta del empleado que lo usa. Crea permisos específicos: leer una carpeta pero no descargarla completa; crear un borrador pero no publicarlo; consultar clientes pero no exportar la base; abrir una incidencia pero no cerrarla. Para operaciones de alto impacto, exige aprobación humana vinculada a la acción concreta, no una autorización genérica al iniciar la sesión.
4. Controlar la salida de red
La conexión a internet debe pasar por un proxy o pasarela que solo permita destinos, métodos y volúmenes previstos. Resolver DNS no equivale a autorizar cualquier dominio. También hay que vigilar rutas indirectas: webhooks, servicios de métricas, gestores de paquetes y herramientas que descargan recursos por cuenta del agente. Registra cada conexión con la identidad del flujo que la solicitó.
5. Mantener las credenciales fuera del modelo
Una clave copiada en el prompt puede acabar en registros, memoria o resultados. Es preferible que una capa externa reciba la solicitud validada, añada una credencial de corta duración y ejecute la operación. Limita el alcance del token, evita reutilizar secretos humanos y revócalo al terminar. Si un agente necesita cinco credenciales permanentes para una tarea ocasional, el diseño debe revisarse.
6. Registrar, detectar y detener
Guarda quién inició el trabajo, objetivo declarado, entradas, llamadas de herramientas, decisiones de aprobación, conexiones, cambios y resultado. Los registros críticos deben quedar fuera del alcance de escritura del propio agente. Define umbrales que pausen el flujo: demasiados errores, acceso a un dominio nuevo, lectura masiva, intento de usar una herramienta no autorizada o cambio inesperado de identidad.
7. Red-teaming continuo y pruebas de recuperación
Prueba de forma controlada si el agente obedece instrucciones incrustadas en documentos, intenta ampliar permisos, filtra secretos simulados o continúa después de un bloqueo. Verifica también la respuesta operativa: revocación de tokens, parada de tareas, conservación de evidencias y restauración del estado. El Agent Control Standard de OWASP propone agentes observables, trazables y controlables mediante puntos de aplicación de políticas en tiempo de ejecución.
Arquitectura mínima recomendada
Una implantación pequeña puede separar responsabilidades sin construir una plataforma compleja. La clave es que el modelo no tenga acceso directo a todos los recursos y que la política se evalúe en cada salto.
- Entrada: clasifica la solicitud y marca el contenido externo como no fiable.
- Orquestador: asigna identidad, tarea, presupuesto, herramientas y tiempo máximo.
- Entorno aislado: ejecuta navegación o código sin acceso al host ni a carpetas no autorizadas.
- Pasarela de herramientas: valida esquema, acción, destino y volumen antes de usar una API.
- Gestor de secretos: entrega tokens efímeros al conector, nunca al contexto del modelo.
- Proxy de salida: aplica listas de dominios, límites y registro de conexiones.
- Monitor externo: observa eventos, bloquea anomalías y conserva trazas fuera del alcance del agente.
- Aprobación humana: interviene antes de publicar, borrar, pagar, enviar o modificar datos sensibles.
Para complementar este diseño, nuestra guía sobre secuestros de dominio y Certificate Transparency explica cómo vigilar cambios de DNS y certificados. Si el agente participa en desarrollo, conviene revisar también cómo evaluar una IA para código y ciberseguridad sin confundir capacidad con autorización.
Plan de implantación en cuatro fases
No conectes primero todas las herramientas para “ver qué hace”. Empieza con un caso reversible y amplía después de reunir evidencia.
- Inventario y modo lectura. Describe datos, herramientas, propietarios y consecuencias. Ejecuta solo consultas con datos de prueba o una copia anonimizada.
- Borradores y aprobación. Permite crear propuestas, tickets o cambios, pero exige revisión antes de aplicarlos.
- Automatización acotada. Autoriza acciones reversibles con límites de frecuencia, volumen, horario y destino.
- Operación medida. Revisa alertas, falsos positivos, incidentes, permisos y dependencias; repite pruebas tras cada cambio de modelo, herramienta o conector.
Vídeo: qué ocurre cuando falla el aislamiento
El vídeo “Hugging Face breach: OpenAI’s model breaks containment”, publicado por IBM Technology, analiza el incidente que motivó parte del refuerzo posterior. Aporta contexto sobre por qué un sandbox aislado en apariencia puede seguir teniendo rutas indirectas hacia servicios, credenciales o internet. El informe actual de OpenAI es la fuente principal para los controles y cambios descritos en este artículo.
Podcast: una introducción práctica a la seguridad de agentes
El episodio “What is AI agent security?” de Techsplainers by IBM dura seis minutos y resume los riesgos de inyección, acceso no autorizado y escalada de privilegios, junto con controles como aislamiento, autenticación, monitorización y circuit breakers. Es una introducción concisa antes de revisar una arquitectura concreta.
Escuchar “What is AI agent security?” en Apple Podcasts.
Preguntas frecuentes
¿Un prompt de sistema puede impedir acciones peligrosas?
Ayuda a orientar el comportamiento, pero no sustituye controles de permisos, red, aislamiento y aprobación. Una frontera de seguridad debe seguir funcionando aunque el agente interprete mal la instrucción o procese contenido malicioso.
¿Todos los agentes necesitan una máquina virtual?
No siempre. Un asistente que solo resume texto sin herramientas tiene menos superficie que uno que ejecuta código o navega. Cuanto mayor sea la capacidad de actuar, más fuerte debe ser el aislamiento. Contenedores, microVM o servicios gestionados se eligen según el riesgo y los datos.
¿Debe un agente usar la cuenta del empleado?
No es lo ideal. Una identidad específica permite aplicar privilegio mínimo, atribuir acciones, revocar acceso y distinguir la actividad automática de la humana. La delegación debe conservar quién autorizó cada tarea.
¿Cómo se evita que una web o un documento dé órdenes al agente?
El contenido externo debe tratarse como datos no fiables, no como instrucciones. Separa canales, valida las llamadas a herramientas, limita permisos y pide aprobación antes de acciones sensibles. No existe un filtro único infalible.
¿Qué acciones deberían requerir siempre revisión humana?
Publicar, borrar, pagar, enviar comunicaciones externas, cambiar permisos, exportar datos, desplegar código y modificar sistemas críticos son buenos candidatos. El umbral depende del impacto y de la reversibilidad.
¿Cuándo hay que repetir el red-teaming?
Después de cambiar el modelo, prompt, herramientas, permisos, conectores, red o datos; también de forma periódica. Una prueba antigua no demuestra que una arquitectura modificada siga siendo segura.
Conclusión: capacidad no significa autoridad
La seguridad de un agente de IA se decide en la arquitectura que lo rodea. El modelo puede ser muy capaz y, al mismo tiempo, disponer de una autoridad pequeña, temporal, observable y revocable. Esa separación reduce el impacto de errores, inyecciones, herramientas comprometidas y comportamientos inesperados.
La lista corta es clara: frontera explícita, entorno aislado, privilegio mínimo, salida de red controlada, credenciales externas, registros inmutables, parada efectiva y red-teaming repetible. Empieza en modo lectura, pasa por borradores y solo automatiza acciones reversibles después de medir. Si una tarea no puede detenerse, auditarse o atribuirse, todavía no está preparada para delegarse a un agente.