Seguridad de agentes IA: un ciclo de vida, no un simple control

Durante años, la seguridad empresarial ha funcionado con una lógica bastante lineal: se establece una identidad, se autentica a quien pide acceso, se decide qué puede ver y se aplican esos permisos. Los agentes de IA rompen ese esquema. No se limitan a consultar sistemas: interpretan objetivos, eligen herramientas, crean subagentes, toman decisiones y ejecutan acciones, muchas veces con credenciales y permisos heredados de personas. El problema no es que al agente le falten credenciales, sino que esas credenciales pueden autorizar acciones que el humano nunca pretendió delegar. Y, a diferencia del software clásico, un agente puede cambiar su ruta de ejecución sobre la marcha para cumplir su objetivo.

Eso obliga a un cambio de enfoque: la seguridad ya no puede preguntarse solo quién actúa, sino qué intenta hacer el agente, con la autoridad de quién y bajo qué política. Y eso no se resuelve con un punto de control aislado. Hace falta un ciclo de vida continuo de seguridad para agentes.

El ejemplo que lo explica todo

Imagina un agente que intenta borrar una base de datos de producción usando las credenciales legítimas de un desarrollador. Los controles de red ven tráfico autorizado. El runtime ve un proceso aprobado. El proveedor de identidad confirma que las credenciales son válidas. Las tres capas funcionan según lo diseñado. La pregunta que falta es si ese agente concreto debería poder ejecutar esa acción concreta, aunque el humano cuyas credenciales heredó sí pudiera hacerlo legalmente.

La respuesta exige contexto de identidad y autorización en el punto de acción. En la práctica, una decisión de autorización debería considerar la identidad del agente, la persona o servicio que le delegó autoridad, la operación solicitada, el recurso objetivo y la política aplicable. Y debe aplicarse antes de que la operación se ejecute. El agent harness —la capa que conecta el modelo con herramientas, APIs, ficheros y sistemas externos— es un lugar clave para aplicar ese control, junto con otros puntos de confianza como los servicios de herramientas y las propias APIs de recursos. No se trata de sustituir las defensas existentes, sino de integrar la autorización en la ejecución del agente.

Cuatro disciplinas, un ciclo continuo

Una arquitectura práctica de seguridad para agentes se apoya en cuatro disciplinas interconectadas: observar, aplicar, construir y desplegar. No son fases secuenciales que cada organización deba superar en orden, sino un ciclo continuo en el que se puede entrar por el punto que mejor encaje con la infraestructura y madurez existentes. Una empresa con agentes ya en producción puede empezar observando su comportamiento. Un equipo que desarrolla un agente nuevo puede empezar incorporando autorización en su arquitectura desde el diseño. Y una organización que amplía un despliegue puede descubrir actividad nueva que obligue a revisar sus políticas.

Observar: saber qué hacen de verdad

Muchas empresas ya tienen algún inventario de aplicaciones y empiezan a extenderlo a agentes de IA. Es un punto de partida útil, pero saber que un agente existe no es lo mismo que entender qué hace. Los equipos de seguridad necesitan visibilidad sobre las acciones que los agentes intentan de verdad: qué herramientas y APIs invocan, qué comandos ejecutan, a qué sistemas y recursos sensibles acceden, qué credenciales y permisos delegados usan, qué subagentes crean y qué autoridad heredan, y qué acciones violarían una política propuesta. Los diagramas de arquitectura o los ficheros de configuración no responden a eso con fiabilidad. La evidencia importante está en la ejecución.

Por eso la observabilidad de agentes debe ir más allá de los logs y el monitoreo de aplicaciones convencionales. Hay que conectar las acciones observadas con el contexto de identidad, delegación y autorización. Además, la observación debería permitir evaluar políticas potenciales sin interrumpir de inmediato la actividad en producción. Ya ocurrió con los sistemas de prevención de intrusiones y los firewalls de aplicaciones web: activar reglas de bloqueo agresivas de golpe interrumpía aplicaciones legítimas. Primero se monitoriza, se establecen líneas base de comportamiento y luego se aplican políticas de forma progresiva. Con los agentes pasa lo mismo, aunque su comportamiento sea mucho más dinámico. No se puede gobernar con criterio lo que no se ha observado.

Aplicar: límites deterministas a un comportamiento probabilístico

Una vez entendido el comportamiento, toca definir y aplicar límites. Aquí aparece la distinción entre lo probabilístico —el modelo— y lo determinista —las reglas de autorización—. La seguridad de agentes es un problema de defensa en profundidad: la red controla cómo se comunican, las protecciones de endpoint y runtime limitan dónde y cómo se ejecuta el código, las protecciones de infraestructura y silicio aportan una base de ejecución confiable, y los guardarraíles del modelo ayudan a moldear el comportamiento. Todas esas capas se complementan, pero ninguna responde por sí sola a la pregunta de si este agente, con esta autoridad delegada, debería ejecutar esta operación sobre este recurso.

Qué significa para una pyme y qué recomendamos

Para una pyme, la tentación es pensar que todo esto es cosa de grandes corporaciones. No es así. Cualquier empresa que conecte un agente a su CRM, a su ERP, a su correo o a sus ficheros compartidos está creando un actor con credenciales heredadas y capacidad de ejecutar acciones. Y muchas veces ese agente se despliega con el token de un empleado con privilegios amplios porque es lo más rápido.

Nuestras recomendaciones concretas:

• Inventaría y observa antes de bloquear. Haz una lista real de agentes en uso, aunque sea informal, y registra qué herramientas y datos tocan. Sin esa foto, cualquier política será a ciegas.
• Aplica mínimo privilegio también a los agentes. No reutilices credenciales humanas con permisos amplios. Crea identidades propias para agentes, con permisos acotados a la operación que deben realizar.
• Define políticas por acción, no solo por identidad. Pregúntate qué operaciones concretas (borrar, enviar, modificar, exportar) puede ejecutar cada agente y sobre qué recursos.
• Empieza en modo observación. Evalúa políticas en sombra antes de bloquear, como se hizo con los WAF. Así evitas romper procesos legítimos.
• Revisa el ciclo con cada cambio. Un agente nuevo, una herramienta nueva o un permiso ampliado obligan a volver a observar y ajustar. El ciclo no termina.

Este enfoque encaja con lo que ya venimos defendiendo en otros frentes: la seguridad no es un producto que se instala, sino una disciplina que se mantiene. Lo vimos con el pentesting con IA, donde el arnés importa más que el modelo, y lo volvemos a ver aquí: el control determinista alrededor del agente pesa tanto o más que el propio modelo. También conviene tener presente que los agentes amplían la superficie de exposición de credenciales, un riesgo que ya tratamos al hablar de la filtración de secretos de clientes en Railway.

La conclusión es sencilla: un agente no se protege con una puerta, sino con un proceso. Observar, aplicar, construir y desplegar en bucle. Para una pyme, empezar por observar y acotar permisos es barato y reduce riesgos de inmediato. Lo caro es descubrir, cuando ya ha ocurrido, que el agente hizo exactamente lo que sus credenciales le permitían.

Fuente: The New Stack. Análisis y adaptación: ForgeNEX.