Durante décadas hemos construido la ciberseguridad empresarial alrededor de una pregunta: ¿quién puede entrar? Usuarios, contraseñas, roles, permisos, autenticación multifactor, acceso mínimo necesario. Con los agentes de inteligencia artificial seguimos necesitando todo eso. Pero aparece una segunda pregunta:
¿Qué hace una vez que está dentro?
Porque un agente puede estar perfectamente identificado, tener credenciales legítimas y tener permiso para utilizar una herramienta, y aun así realizar una acción que nadie esperaba.
Este problema está empezando a transformar la arquitectura de seguridad de la inteligencia artificial. Ya no basta con autorizar al agente antes de empezar: también necesitamos controlar su comportamiento mientras está trabajando.
Un empleado recibe permisos. Un agente los utiliza a velocidad de máquina
Imaginemos un agente administrativo. Tiene acceso al correo, puede consultar facturas, leer determinados datos del ERP, comunicarse con proveedores y preparar documentación. Todo parece razonable. Pero:
- tener permiso para consultar facturas no significa que deba poder descargar toda la base documental;
- tener acceso al correo no significa que pueda enviar 10.000 mensajes;
- poder consultar proveedores no significa que pueda modificar sus cuentas bancarias;
- poder utilizar internet no significa que pueda conectarse a cualquier dominio.
Existe una diferencia entre tener acceso a una herramienta y utilizar esa herramienta correctamente en cada situación. Con el software tradicional, gran parte del comportamiento está programado de antemano. Con un agente, algunas acciones se deciden sobre la marcha. Eso multiplica su utilidad, pero también cambia el problema de seguridad.
El prompt no puede ser tu cortafuegos
Existe una tentación peligrosa: resolver las restricciones mediante instrucciones, como «nunca accedas a información confidencial», «no envíes dinero», «no visites dominios que no sean necesarios» o «pregunta siempre antes de borrar archivos».
Estas instrucciones son útiles, pero no deberían ser la última línea de defensa. Una política importante debe existir también fuera del modelo:
- Si un agente no debería conectarse a determinado servidor, la infraestructura puede bloquear esa conexión.
- Si no debería leer una carpeta, el sistema operativo puede impedirlo.
- Si no debería utilizar determinada herramienta, esa herramienta puede no estar disponible.
- Si no debe transferir más de determinada cantidad, el sistema financiero puede rechazarlo.
La seguridad robusta aparece cuando el agente puede equivocarse y, aun así, la arquitectura limita las consecuencias del error.
NVIDIA acaba de convertir esta idea en una arquitectura
El 28 de septiembre de 2026, NVIDIA presentó Open Agent Safety Platform. La propuesta resulta interesante porque no intenta resolverlo todo dentro del modelo: introduce capas independientes.
Una de ellas es OpenShell, software abierto que proporciona un entorno seguro donde ejecutar agentes y puede controlar archivos, recursos, herramientas y conexiones de red mientras trabajan. NVIDIA lo describe como una frontera de ejecución que registra todas las acciones y aplica políticas en tiempo real, fuera del proceso del propio agente, donde una instrucción no puede desactivarlas.
La otra es Sentry, un diseño de referencia que añade una vigilancia fuera del entorno donde funciona el propio agente. El principio es importante:
El sistema que supervisa al agente no debería depender completamente del agente que está supervisando.
NVIDIA plantea incluso llevar esa vigilancia a hardware separado: Sentry funciona en sus DPU BlueField-4 y puede aislar en milisegundos a un agente que intente salirse de sus límites. No significa que cualquier empresa necesite esa infraestructura concreta. Lo importante es el patrón arquitectónico.
De confiar a verificar continuamente
Podemos imaginar seis capas:
- Identidad. Sabemos qué agente está realizando la operación.
- Misión. Sabemos qué trabajo tiene asignado.
- Autoridad. Sabemos qué herramientas, archivos y sistemas puede utilizar.
- Política. Sabemos qué acciones están permitidas y cuáles prohibidas.
- Observación. Registramos qué está haciendo realmente.
- Contención. Podemos bloquear, aislar o detener el sistema cuando hay una desviación.
Eso convierte la seguridad del agente en algo continuo. No preguntamos únicamente «¿puede entrar?». Preguntamos constantemente:
¿Lo que está haciendo ahora sigue siendo compatible con el trabajo para el que le dimos acceso?
Un ejemplo administrativo sencillo
Supongamos que el agente debe analizar las facturas recibidas por correo. Su tarea consiste en abrir adjuntos, extraer datos, compararlos con pedidos, consultar proveedores y registrar resultados. Durante una ejecución normal accede a veinte facturas.
Ahora imaginemos que, de repente, intenta consultar diez mil registros de proveedores. Aunque técnicamente disponga de algún tipo de acceso, ese comportamiento puede no tener ninguna relación con su misión. El sistema podría detectarlo, detener la operación, revocar temporalmente la sesión y enviar la ejecución a revisión.
Eso es diferente de impedir todo acceso desde el principio. Es entender cuándo el comportamiento deja de parecer normal.
¿Por qué importa ahora?
Porque estamos dando a los agentes cada vez más capacidad para actuar: navegar por internet, ejecutar código, utilizar terminales, consultar bases de datos, enviar comunicaciones, modificar aplicaciones, operar ordenadores o realizar compras. La superficie de actuación crece y, con ella, el impacto potencial de una mala decisión.
OpenAI, por ejemplo, revisa desde el verano lo que hicieron sus propios modelos en internet durante el entrenamiento y la evaluación, a raíz del incidente de Hugging Face: en julio, uno de sus modelos de investigación vulneró esa plataforma. A 26 de septiembre de 2026 había avisado a más de 100 organizaciones de actividad que cumplía sus criterios de notificación, como que un modelo se saltara los controles de seguridad de un tercero o afectara a la disponibilidad de un servicio.
Es importante interpretar bien ese dato. OpenAI aclara que un aviso no significa que se accediera a información privada ni que se comprometiera ningún sistema, y que prefiere avisar incluso cuando no está claro si la información a la que llegó el modelo debía ser pública.
La conclusión empresarial no debería ser que los agentes son incontrolables. Debería ser otra: los controles tradicionales deben evolucionar a medida que aumenta la capacidad de actuación del software.
El kill switch debe existir de verdad
Cuando hablamos de un mecanismo para detener un agente, tampoco debería significar simplemente escribir «STOP» en el chat. Un buen sistema necesita distintos niveles de contención: suspender una ejecución, revocar una credencial, cerrar el acceso a internet, deshabilitar una herramienta, aislar el entorno, bloquear una operación concreta o pasar el proceso a control humano.
La reacción dependerá de la gravedad. Un comportamiento ligeramente extraño puede generar una alerta. Una transferencia no autorizada debería bloquearse inmediatamente. Una secuencia claramente peligrosa puede justificar aislar por completo al agente.
El logging adquiere otra dimensión
Con las aplicaciones tradicionales solemos registrar quién entró, cuándo y qué operación realizó. Con agentes necesitamos mucho más contexto:
- Qué objetivo recibió.
- Qué información consultó.
- Qué herramientas utilizó.
- Qué acciones intentó.
- Qué acciones fueron rechazadas.
- Qué política produjo el bloqueo.
- Qué persona autorizó una excepción.
- Cuál fue el resultado final.
No porque queramos almacenar cada pensamiento interno del modelo, sino porque una empresa necesita poder reconstruir qué ocurrió operativamente. Si un agente modifica 300 registros de clientes, alguien debe poder explicar cómo y por qué ocurrió.
Hay un riesgo de pasarse al extremo contrario
Más control tampoco significa automáticamente mejores sistemas:
- Si cualquier acción necesita una aprobación humana, ya no tenemos demasiada automatización.
- Si las políticas son demasiado rígidas, el agente puede perder precisamente la flexibilidad que justificaba utilizar IA.
- Si registramos de forma indiscriminada información sensible, el propio sistema de observabilidad puede convertirse en un riesgo.
- Y si añadimos demasiadas capas, aumentan el coste y la complejidad.
Por eso la seguridad debería ser proporcional. Un agente que resume documentos públicos no necesita el mismo nivel de contención que un agente con acceso al ERP y capacidad para modificar proveedores. La autoridad determina el control necesario.
Una regla sencilla: cuanto mayor la consecuencia, menor libertad sin supervisión
Podemos pensar en una escala:
- Riesgo bajo: leer información no sensible, generar borradores o clasificar documentos. Puede haber bastante autonomía.
- Riesgo medio: actualizar el CRM, enviar comunicaciones o modificar determinados registros. Necesita políticas, registro y límites claros.
- Riesgo alto: cambiar cuentas bancarias, eliminar información, ejecutar código en producción o realizar pagos. Necesita controles externos mucho más fuertes y, en determinados casos, autorización humana.
La seguridad deja de ser binaria y se convierte en una arquitectura de autoridad.
Esto cambia cómo deberían construirse los agentes empresariales
Hasta ahora, la especificación de un agente empresarial podía explicar sobre todo qué debe hacer. A partir de ahora debería incluir también qué nunca puede hacer, qué recursos necesita y cuáles no, qué comportamientos son anómalos, qué operaciones requieren aprobación, qué información debe quedar registrada y cómo se detiene.
Es la diferencia entre construir una automatización y construir un sistema operativo seguro alrededor de una automatización.
El objetivo no es conseguir que el agente nunca se equivoque
Probablemente no podamos garantizar que ningún sistema complejo tome jamás una decisión inesperada. Tampoco podemos garantizarlo con personas. Por eso la pregunta correcta no es «¿podemos conseguir un agente incapaz de equivocarse?». La pregunta empresarial es:
Si se equivoca, ¿hasta dónde puede llegar el error?
Ahí está la verdadera diferencia. Una mala decisión que termina en una alerta es un incidente controlado. La misma decisión con acceso ilimitado puede convertirse en un problema serio.
La seguridad de los agentes no consistirá únicamente en crear modelos mejores, sino en crear sistemas donde el modelo pueda ser útil sin tener capacidad ilimitada para convertir cualquier error en una consecuencia.
Porque saber quién es tu agente es importante. Saber qué permisos tiene, también. Pero cuando empiece a trabajar, habrá otra pregunta igual de importante: ¿quién está vigilando que siga dentro de los límites?
