Los agentes de IA no solo automatizan tareas: también introducen nuevas identidades, permisos y dependencias dentro de la infraestructura.

ComputerWeekly analizaba recientemente cómo la adopción de agentes de IA está creciendo más rápido que la capacidad de muchas organizaciones para asegurar este nuevo modelo operativo. El debate ya no se limita al uso de IA generativa como herramienta de apoyo, sino a sistemas capaces de actuar sobre aplicaciones, repositorios, APIs, tickets, plataformas cloud o flujos internos.

Fuente: ComputerWeekly – AI agents are here. Are we ready for the security implications?

Cuando un agente deja de responder y empieza a actuar

Un asistente responde a una petición. Un agente puede ejecutar acciones.

Esa diferencia cambia el riesgo. Cuando un sistema de IA puede conectarse a servicios internos, consultar información, modificar datos, lanzar procesos o interactuar con herramientas de operación, deja de ser una capa de productividad y pasa a formar parte de la infraestructura.

A partir de ese momento, las preguntas relevantes ya no son solo funcionales:

  • Qué sistemas puede consultar.
  • Qué permisos tiene.
  • Qué credenciales utiliza.
  • Qué acciones puede ejecutar sin validación humana.
  • Cómo se audita lo que hace.
  • Cómo se revoca su acceso si algo se comporta de forma inesperada.

El riesgo no está solo en que un agente de IA responda mal, sino en que tenga permisos para actuar sobre sistemas reales sin suficiente control, trazabilidad o capacidad de contención.

Nuevas identidades dentro del entorno operativo

En infraestructuras cloud y DevOps ya existe una gestión compleja de identidades: usuarios, servicios, cuentas técnicas, tokens, runners, integraciones, pipelines y automatizaciones. Los agentes de IA añaden una nueva capa a ese modelo.

No son usuarios humanos, pero pueden actuar en nombre de personas o sistemas. No son scripts tradicionales, porque su comportamiento puede variar en función del contexto. Y no siempre encajan bien en los modelos clásicos de permisos, auditoría y segregación de funciones.

En entornos reales, esto puede derivar en problemas muy concretos:

  • Agentes con permisos más amplios de lo necesario.
  • Acceso a repositorios o secretos sin control suficiente.
  • Acciones automatizadas difíciles de reconstruir.
  • Dependencias entre agentes y servicios no documentadas.
  • Uso de herramientas externas sin evaluación de riesgo.

La cuestión no es si los agentes de IA son útiles. Lo son. La cuestión es si se están incorporando al entorno operativo con los mismos criterios de seguridad, control y observabilidad que aplicaríamos a cualquier otro componente crítico.

Automatización sin trazabilidad: un nuevo punto ciego

La automatización siempre ha necesitado control. Con los agentes de IA, esa necesidad aumenta porque el comportamiento puede ser menos determinista que en una automatización tradicional.

Un pipeline, una tarea programada o un script suelen tener rutas conocidas. Un agente puede adaptar su comportamiento según la instrucción recibida, las herramientas disponibles, los datos accesibles y el contexto operativo.

Eso puede aportar valor, pero también dificulta la supervisión si no se han definido límites claros.

Por eso, antes de integrar agentes en procesos de soporte, desarrollo, operaciones o seguridad, conviene aterrizar varios aspectos:

  • Registro completo de acciones.
  • Separación entre lectura y ejecución.
  • Límites de acceso por entorno.
  • Validación humana en acciones sensibles.
  • Revisión periódica de permisos.
  • Capacidad de bloqueo o revocación rápida.

No se trata de frenar la adopción de IA, sino de evitar que la automatización avance más rápido que la capacidad de operarla con seguridad.

De herramienta experimental a componente de infraestructura

Muchas organizaciones empiezan usando agentes de IA en tareas de bajo riesgo: generación de documentación, análisis de información, soporte al desarrollo o clasificación de incidencias.

El salto real aparece cuando esos agentes acceden a sistemas productivos, plataformas cloud, credenciales, herramientas de ticketing, repositorios o pipelines de despliegue. En ese punto dejan de ser una prueba y se convierten en un componente más de la arquitectura operativa.

Desde la perspectiva de infraestructura, esto implica tratarlos como cualquier otro elemento con capacidad de impacto:

  • Inventariarlos.
  • Limitar sus permisos.
  • Monitorizar su actividad.
  • Auditar sus cambios.
  • Segmentar sus accesos.
  • Preparar escenarios de contención.

En TeraLevel vemos este tipo de transición con frecuencia en tecnologías emergentes: primero se adoptan por utilidad, después se integran en procesos críticos y, finalmente, aparece la necesidad de gobernarlas como parte real de la operación.

Conclusión

Los agentes de IA pueden mejorar productividad, acelerar análisis y reducir tareas repetitivas. Pero cuando se conectan a sistemas reales, también introducen nuevas superficies de riesgo.

La seguridad de estos agentes no depende solo del modelo, sino de la infraestructura en la que operan: permisos, credenciales, integraciones, trazabilidad, monitorización y capacidad de contención.

La clave no está en evitar los agentes de IA, sino en incorporarlos con una arquitectura de control adecuada desde el principio.