Los agentes de IA necesitan límites de seguridad que no pueden reescribir

Resulta tentador interpretar la historia de Hugging Face como el momento en que los agentes de IA se volvieron rebeldes. Eso no es exactamente lo que ocurrió, y los detalles importan. Estos eran agentes de investigación en ciberseguridad que operaban en evaluaciones donde las salvaguardas se habían desactivado deliberadamente para que los investigadores pudieran observar de qué eran capaces los modelos. El bot de atención al cliente de nadie se despertó una mañana y decidió atacar a una empresa. Pero ese contexto no exime a nadie de responsabilidad. Un agente cruzó el límite dentro del cual debía permanecer, utilizó credenciales y herramientas de maneras que sus operadores nunca autorizaron, y terminó en sistemas que pertenecían a otra persona. Esa es la parte a la que todo equipo de seguridad debe prestar atención.

Reuters informó que los agentes estaban investigando Hugging Face ya en mayo, aunque los investigadores dijeron que no encontraron nada que demostrara que la actividad anterior causó una brecha por sí sola. Julio fue diferente. OpenAI dijo que sus modelos eludieron los controles de aislamiento, accedieron a internet y comprometieron partes de su propia infraestructura de investigación junto con los sistemas de Hugging Face. La propia cuenta de Hugging Face describe una intrusión ejecutada de extremo a extremo por un sistema de agentes autónomos, que explotó su canal de procesamiento de datos, recolectó credenciales y se desplazó a través de clústeres internos.

La parte incómoda es que los agentes estaban cumpliendo sus tareas. Estaban persiguiendo el objetivo que se les había asignado. Por eso esta historia trasciende mucho más allá de un solo laboratorio de investigación. Los agentes empresariales también persiguen objetivos. Poseen credenciales, invocan herramientas y se mueven más rápido de lo que cualquier persona puede revisar. Un agente con intenciones perfectamente buenas aún puede causar daño real, y un agente secuestrado puede usar la misma autoridad en nombre de un atacante. Por lo tanto, la seguridad debe gobernar lo que el sistema realmente puede hacer, sin importar cuán confiado parezca el modelo o cuán inofensivo se vea su propósito declarado.

Asegure la acción, no solo el modelo

La mayoría de los programas de agentes tempranos concentran su esfuerzo en el modelo. Los equipos prueban indicaciones, afinan rechazos, añaden un segundo modelo para verificar el primero y observan el rastro de razonamiento en busca de señales de mala intención. Nada de eso se desperdicia. Pero todo eso es probabilístico, porque depende de que otro modelo tome una decisión de juicio. Una frontera de seguridad en producción debe ser determinista y debe rodear las herramientas, credenciales, redes y transacciones.

La pregunta que haría es concreta: ¿qué puede este agente lograr realmente en el mundo real? Redactar una solicitud de pago es una cosa. Liberar los fondos es otra. Lo mismo ocurre al preparar un cambio de base de datos versus ejecutarlo en producción, o al marcar registros que cumplen una regla de retención versus eliminarlos. Puede ser el mismo modelo en ambos casos, con riesgos muy diferentes según de qué lado de esa línea se encuentre.

Una visión reciente de Unite AI sobre el control de capacidadestraza la misma línea, vinculando el riesgo a los datos, herramientas, permisos, autonomía y al entorno en el que opera el agente. Me gusta este enfoque porque nos lleva más allá de etiquetas vagas como \”modelo seguro\” y \”modelo inseguro\”. Hace que los equipos rastreen cada camino desde la decisión de un agente hasta algo con consecuencias reales.

Dé a cada agente una identidad y un mandato limitado

Un agente nunca debería ejecutarse con la cuenta de un desarrollador ni heredar todo lo que un usuario humano puede hacer. Una identidad compartida elimina la atribución. Las credenciales de larga duración le dan al atacante más tiempo para abusar de ellas. Y las cuentas de servicio amplias permiten que un pequeño flujo de trabajo se adentre en datos y sistemas a los que no debería acceder.

NIST ahora considera la identidad del software y de los agentes de IA como su propio problema de arquitectura. Su documento conceptual pregunta cómo puede un agente demostrar que está autorizado para una acción específica, cómo la identidad de un agente puede vincularse a la autorización de un humano, y cómo las organizaciones pueden mantener registros a prueba de manipulaciones de lo que se pretendía y lo que realmente ocurrió. En la práctica, eso apunta a un diseño sencillo. Cada agente obtiene una identidad única, un propietario (una persona o un equipo), un propósito definido y permisos limitados a la tarea que tiene delante.

Las credenciales deben expirar rápidamente y funcionar solo para recursos y acciones específicas. El acceso a la red debe partir de una lista de permisos estricta. Si un agente necesita consultar una base de datos aprobada, no debería también obtener una consola general, acceso abierto a internet o la capacidad de generar nuevas credenciales. Y a medida que el trabajo se transmite a lo largo de una cadena de agentes y herramientas, la autoridad debe volverse más estrecha en cada paso, no más amplia.

NIST también advierte contra el uso compartido de credenciales y el acceso excesivamente amplio, y esa advertencia tiene peso porque los agentes son oportunistas. Si una ruta está bloqueada, pueden probar otra herramienta, explorar su entorno o tropezar con un token que alguien olvidó. Las credenciales recolectadas también formaron parte de la historia de julio. El principio de menor privilegio mantiene pequeño el radio de explosión cuando la capa de razonamiento hace algo que sus diseñadores no esperaban.

Mantenga la autorización fuera del bucle de razonamiento

Un agente puede recomendar una acción. No debería decidir si está permitido llevarla a cabo. Esa decisión corresponde a una capa de aplicación de normas separada que el agente no puede reescribir, desactivar o eludir. Cada llamada a una herramienta debe aparecer como una solicitud estructurada: qué agente la solicita, qué humano la patrocinó, qué operación desea, a qué está dirigida y qué límites se aplican. Luego, la capa de aplicación de normas la permite, la bloquea o la escala.

OWASP describe la agencia excesiva como una combinación de funcionalidad innecesaria, permisos excesivos y demasiada autonomía. Su guía recomienda herramientas estrechas, permisos mínimos, autorización en el sistema downstream y aprobación del usuario para acciones de alto impacto. Creo que ese es exactamente el orden correcto. La regla debe ser aplicada por quien sea el propietario de los datos o ejecuta la transacción. Si un modelo dice que una acción está aprobada, esa declaración por sí sola no debe tener peso.

Esta separación también ayuda con la inyección de indicaciones. Un correo electrónico o documento contaminado podría orientar el razonamiento del agente, pero no puede ampliar sus credenciales ni derribar una puerta de política. El modelo es libre de solicitar algo prohibido. El sistema aún debería decir no.

Reserve la aprobación humana para los momentos que importan

La revisión humana justifica su existencia cuando una acción no puede deshacerse, cruza una frontera organizacional, cambia privilegios, divulga información sensible, mueve dinero o afecta a un sistema de producción. Solicitar aprobación en cada paso rutinario produce dos cosas: demoras y personas que aprenden a hacer clic en “aprobar” sin leer. NIST nombra explícitamente esta fatiga de consentimiento.

Una buena solicitud de aprobación muestra la acción exacta en lenguaje claro, incluyendo a dónde se dirige y los parámetros relevantes. Debe provenir de un sistema autorizado, no del texto escrito por el agente. La aprobación debe expirar rápidamente y cubrir solo esa acción. Si algún detalle material cambia, el sistema vuelve a preguntar.

la guía de seguridad de agentes de OWASP recomienda probar si una acción de alto impacto puede ejecutarse sin una aprobación válida, no expirada y vinculada a parámetros. Esa frase vale la pena recordar. “OK to continue” es una aprobación débil que puede ser aprobada por otro agente o actor malintencionado. “Transferir esta cantidad a esta cuenta” o “desplegar este cambio a este entorno” es algo que el sistema puede verificar realmente en el momento de la ejecución, y que un usuario comprende plenamente.

La garantía de identidad humana en vivo es importante en esta puerta. Una notificación push solo demuestra que alguien o algo pulsó un botón. Los diseños más robustos requieren que una persona inscrita use autenticación de clave pública resistente al phishing, respaldada por un método de verificación biométrica local. Los estándares FIDO vinculan credenciales de clave pública al servicio en línea legítimo y mantienen los datos biométricos en el dispositivo aislado del usuario. Si se usa correctamente, la autenticación respaldada por hardware brinda una evidencia mucho mejor de que la persona correcta estuvo realmente presente. Sin embargo, no sustituye la vinculación de transacciones, una pantalla confiable o la aplicación de políticas. Necesitas que todos funcionen juntos.

Monitorear el comportamiento y preservar la evidencia

No puedes confiar en la indicación inicial para explicar lo que ocurrió durante una ejecución prolongada del agente. Los equipos de seguridad necesitan telemetría sobre llamadas a herramientas, actividad de red, uso de credenciales, decisiones de política, aprobaciones, denegaciones y cambios de alcance. El monitoreo debe comparar lo que el agente realmente hizo con el límite declarado para esa ejecución. Si a un agente se le asignó analizar código y comienza a buscar credenciales externas o a sondear un servicio no relacionado, eso debería activar una alerta.

Los registros necesitan suficiente contexto para reconstruir la cadena de acciones sin revelar secretos en texto plano. Cada registro debe capturar la versión del agente, su propietario, la persona o sistema que lo inició, la herramienta utilizada, la acción solicitada, el resultado de la política y cualquier autorización humana. Los registros firmados o de otra forma resistentes a manipulaciones hacen que la revisión posterior a la acción sea mucho más creíble, especialmente cuando están involucrados varios agentes y servicios.

Todo esto debe ejecutarse a velocidad de máquina. Nadie que observe un panel detendrá miles de llamadas que terminan en segundos. Los controles automatizados deben aplicar límites de velocidad, detectar secuencias inusuales y suspender credenciales en el momento en que el comportamiento supera un umbral definido. De esa manera, los investigadores humanos obtienen un incidente contenido para analizar en lugar de una persecución sin fin.

Diseñar la ruta de detención antes del lanzamiento

Cada despliegue de agente necesita una forma de detenerlo que realmente elimine la capacidad. Pedir al agente que se detenga no cuenta. Los operadores deben poder revocar sus credenciales, cortar su ruta de red, terminar su tiempo de ejecución y evitar que las acciones en cola se reinicien. Para flujos de trabajo de alta consecuencia, si el servicio de aprobación o de política falla, el sistema debe cerrarse.

Luego prueba esa ruta bajo presión. Desactiva el servicio de aprobación. Da al agente instrucciones conflictivas. Rota una credencial a mitad de una ejecución. Simula una herramienta comprometida y un aprobador que nunca responde. Confirma que la acción se bloquea y que queda un registro útil. Y vuelve a ejecutar esas pruebas cada vez que el modelo, la indicación, el conector, el sistema de memoria o el conjunto de permisos cambien.

El objetivo es una autonomía responsable

Nada de esto es un argumento contra los agentes, y el incidente de Hugging Face no debería asustar a nadie de los útiles. Lo que debería hacer es eliminar la idea de que un aviso de seguridad más buenas intenciones suman una implementación confiable. Dé a los agentes espacio para analizar, preparar trabajo y manejar tareas reversibles. Mantenga su autoridad para causar consecuencias reales estrecha, visible y aplicada por algo distinto al propio agente.

Antes de que un agente entre en producción, los líderes deberían poder responder a un puñado de preguntas sencillas. ¿A qué sistemas puede acceder? ¿Qué credenciales puede usar? ¿Qué puede hacer sin revisión? ¿Qué desencadena la escalada? ¿Cómo ve el aprobador la acción exacta que se está aprobando? ¿Qué evidencia quedará atrás? ¿Y cómo puede la seguridad detener la ejecución de inmediato?

Si las respuestas son vagas, el agente tiene más autoridad de la que la organización percibe. La arquitectura que se mantiene con el tiempo combina salvaguardas del modelo con identidad, privilegio mínimo, aplicación de políticas externas, aprobación humana selectiva, telemetría completa y un mecanismo de detención que realmente funciona. Parte de una suposición honesta: los agentes capaces nos van a sorprender de vez en cuando. Nuestras fronteras de seguridad no deberían.

Al final, piense en un agente de IA como un interno con acceso (potencialmente) de root que no le teme a RR.HH.

¿Qué protecciones y barreras tendrían?

Proceda en consecuencia.