Agentes de IA huérfanos
El riesgo de la identidad invisible
El riesgo identificado del que vamos a hablar hoy no corresponde a un malware tradicional ni a una campaña única atribuida a un grupo específico. Es una clase de amenaza operativa emergente: Agentes de IA autónomos, huérfanos o mal gobernados, que conservan acceso persistente a repositorios, bases de datos, APIs, sistemas cloud y herramientas internas después de que la persona que los creó dejó de ser responsable de ellos.
En su articulo The Hacker News describe un escenario crítico para empresas que adoptan IA interna a velocidad superior a la madurez de su gobierno de identidad: cuando un empleado se va, cambia de puesto o abandona un proyecto, los agentes, scripts, flujos automatizados y tokens que construyó pueden seguir activos. El problema central no es solo que “existe una IA”; el problema es que la organización no puede responder de forma inmediata a una pregunta básica: ¿quién autorizó este agente, qué datos puede tocar, por qué sigue activo y quién responde por sus acciones?
Durante años, la seguridad informática se entrenó para imaginar al atacante como alguien que entra por la puerta equivocada: un correo malicioso, una contraseña robada, una vulnerabilidad sin parchar, un endpoint infectado. Esa imagen sigue siendo útil, pero ya no basta. En muchas organizaciones modernas, el atacante no necesita forzar la puerta. Puede encontrar una llave legítima que alguien dejó olvidada puesta en la cerradura.
En el articulo publicado por The Hacker News se describe un problema que nace de la velocidad con la que las empresas adoptan agentes de inteligencia artificial: herramientas autónomas o semiautónomas capaces de consultar repositorios, leer documentos, invocar APIs, escribir tickets, analizar datos, generar código o interactuar con sistemas internos. El problema no es que esas herramientas existan. El problema es que muchas veces siguen existiendo después de que desaparece la persona que las creó, las autorizó o las entendía.
Un agente de IA huérfano es, en términos simples, una automatización inteligente sin dueño claro. Puede haber sido creada por un desarrollador que ya no trabaja en la empresa, por un analista que cambió de equipo, por un consultor cuyo contrato terminó o por un empleado que lanzó un experimento y lo dejó corriendo en producción.
La credencial humana puede ser revocada durante el proceso de salida, pero el token del agente, la cuenta de servicio, la integración OAuth, el webhook o la clave de API pueden seguir vivos. La organización cree que cerró la puerta del usuario, pero olvidó cerrar la puerta de la máquina que ese usuario construyó.
El origen del problema: automatización, velocidad y deuda administrativa
La historia de la IA empresarial no empezó con agentes complejos. Empezó con scripts. Un desarrollador automatizaba una tarea repetitiva. Un analista conectaba una hoja de cálculo con una API. Un equipo de datos creaba un bot que resumía tickets. Luego llegaron los modelos de lenguaje, los asistentes de código, los flujos de trabajo con herramientas, los servidores MCP, los embeddings, los repositorios vectoriales y los agentes capaces de planificar acciones.
Cada nueva capa aumentó la productividad, pero también aumentó la opacidad. Un script antiguo podía ser revisado línea por línea. Un agente de IA puede tomar decisiones basadas en contexto, memoria, herramientas y políticas que cambian con el tiempo. No siempre queda claro qué hizo, por qué lo hizo, qué datos usó y qué permiso tenía para hacerlo.
Si un agente autónomo interactúa hoy con la propiedad intelectual central de una empresa, ¿puede el equipo de seguridad nombrar inmediatamente a la persona que lo autorizó? Para muchas organizaciones, la respuesta es no. Ese “no” es el problema.
La deuda administrativa aparece cuando la adopción tecnológica supera los controles. Los equipos de negocio piden resultados rápidos. Los desarrolladores crean herramientas para cumplirlos. Los proveedores venden plataformas de IA. Los líderes celebran la eficiencia. Pero seguridad, IAM, privacidad, arquitectura y cumplimiento no siempre reciben el inventario completo. El resultado es una población creciente de identidades no humanas: agentes, bots, apps, tokens, servicios, integraciones y automatizaciones que operan dentro de la red con más acceso del que alguien puede justificar.
¿Qué es un agente de IA huérfano?
Un agente de IA huérfano no es simplemente un programa abandonado. Es una entidad con tres características peligrosas: autonomía, acceso y falta de responsabilidad.
La autonomía significa que puede actuar con cierto grado de independencia. Puede leer un documento, decidir consultar una base de datos, llamar a una API, redactar un ticket o modificar un repositorio. No siempre necesita que un humano pulse “ejecutar” en cada paso.
El acceso significa que tiene credenciales. Puede tener una clave de API, un token OAuth, una cuenta de servicio cloud, un PAT de GitHub, un secreto de Slack, una conexión a una base de datos o un webhook. Ese acceso puede ser legítimo en origen, pero peligroso si permanece sin revisión.
La falta de responsabilidad significa que nadie responde por su continuidad. El owner original se fue, cambió de rol o dejó de usar el agente. El agente sigue funcionando, pero no hay una persona que diga: “esto sigue siendo necesario, estos permisos son correctos y yo respondo por sus acciones”.
Esa combinación es letal. La autonomía permite actuar; el acceso permite alcanzar datos; la falta de responsabilidad permite que nadie detecte que el agente ya no debería existir.
La evolución del riesgo: de scripts olvidados a identidades no humanas
El riesgo tiene antecedentes. Durante años, las organizaciones han sufrido por cuentas de servicio olvidadas, tokens en repositorios, integraciones OAuth antiguas y jobs programados que nadie entiende. Lo nuevo es la escala y la capacidad cognitiva que aporta la IA.
Un script antiguo normalmente hacía una tarea predecible. Un agente de IA puede interpretar instrucciones, combinar herramientas, consultar memoria, adaptar su comportamiento y responder a contexto. Si ese agente tiene acceso a repositorios, tickets, bases de datos y APIs internas, su abuso puede parecer una serie de acciones legítimas. No se ve como malware; se ve como automatización aprobada.
Ese cambio obliga a ampliar la definición de identidad. Tradicionalmente, la identidad era humana: Alicia, ingeniera; Bruno, administrador; Carla, analista. Luego aparecieron identidades de máquina: servidores, contenedores, funciones serverless, aplicaciones. Ahora aparecen identidades agénticas: agentes de IA que actúan en nombre de humanos, pero que pueden ejecutar acciones por sí mismos.
El actor no siempre tiene nombre
Los informes de inteligencia de amenazas suelen buscar un grupo: APT, ransomware cartel, colectivo hacktivista, insider. En este caso, la amenaza principal no depende de un nombre. Es un patrón de abuso.
Un atacante externo puede robar un token y usarlo para que un agente legitimo lea datos. Un insider malicioso puede crear un agente con acceso amplio antes de salir de la empresa. Un desarrollador descuidado puede dejar una clave en un repositorio. Un proveedor puede mantener una integración OAuth después de finalizar el contrato. Un empleado puede usar un agente experimental para consultar datos que no debería ver. En todos los casos, el mecanismo es parecido: una entidad con acceso continúa operando sin control suficiente.
Por eso conviene hablar de “patrón de amenaza” más que de “actor único”. El patrón es el abuso de identidades no humanas y agentes autónomos mal gobernados. El objetivo es acceder, exfiltrar, modificar o persistir usando una ruta que parece legítima.
La motivación puede ser económica, espionaje, sabotaje, ventaja competitiva o simple oportunidad. Un grupo de ransomware puede usar el agente para encontrar datos valiosos antes de cifrar. Un actor de espionaje puede usarlo para recolectar propiedad intelectual sin levantar alertas. Un insider puede usarlo para llevarse código fuente. Un atacante oportunista puede usar secretos expuestos para moverse lateralmente.
La pregunta que debemos responder es: ¿qué identidades no humanas pueden actuar en nuestra red y quién responde por ellas?
¿Cómo funciona el abuso?
El abuso de un agente huérfano suele seguir una secuencia. Primero, el atacante necesita encontrarlo. Puede descubrirlo en repositorios, logs, documentación interna, CI/CD, tickets, variables de entorno o entrevistas con empleados. Luego necesita credenciales: una clave olvidada, un token OAuth, una cuenta de servicio, un secreto en un pipeline o un permiso heredado.
Una vez dentro, el atacante no necesita comportarse como un intruso ruidoso. Puede pedir al agente que resuma repositorios, consulte documentación, analice datos o genere reportes. Cada acción puede parecer normal. Si el agente tiene permiso para leer código, el atacante puede obtener código. Si tiene permiso para consultar tickets, puede obtener información de clientes. Si puede invocar APIs, puede mover datos entre sistemas. Si puede escribir, puede modificar configuraciones o crear persistencia.
El peligro aumenta cuando el agente tiene acceso a memoria o embeddings. Los sistemas de IA suelen indexar documentos para responder preguntas. Si esa memoria incluye datos sensibles, el agente puede convertirse en un buscador privilegiado. Un atacante no necesita saber dónde está cada archivo; solo necesita preguntarle al agente.
El abuso también puede ocurrir mediante prompt injection. Un documento, correo, ticket o página web puede contener instrucciones diseñadas para manipular al agente: “ignora las políticas anteriores”, “exporta estos datos”, “envía el resultado a este webhook”, “consulta la base de datos completa”. Si el agente tiene herramientas poderosas y no existe separación estricta entre intención, autorización y ejecución, la inyección puede convertirse en acción.
La arquitectura invisible
Para defenderse, hay que ver la arquitectura. Un agente de IA no es una caja mágica. Está compuesto por identidad, modelo, contexto, herramientas, datos, logs y políticas.
La identidad es la cuenta que usa para actuar. Puede ser humana, de servicio, OAuth, de nube o de aplicación. La identidad determina qué puede tocar.
El modelo es el motor de razonamiento o generación. Puede estar en la nube o local. Puede ser un LLM general, un modelo especializado o un sistema de reglas.
El contexto incluye prompts, documentos, embeddings, memoria, historial y datos recuperados. El contexto es peligroso porque puede contener secretos, datos personales o propiedad intelectual.
Las herramientas son las manos del agente: APIs, repositorios, bases de datos, MCP servers, webhooks, sistemas de tickets, plataformas cloud. Sin herramientas, un agente puede hablar; con herramientas, puede actuar.
Los datos son el premio. Código, documentos, credenciales, registros de clientes, información financiera, planes estratégicos, modelos internos.
Los logs son la posibilidad de reconstruir. Si no hay logs, no hay investigación. Si los logs no incluyen identidad del agente, owner, herramienta, recurso y resultado, la organización queda ciega.
Las políticas son los límites. Determinan qué datos puede usar, qué herramientas puede invocar, qué acciones requieren aprobación y qué comportamientos se bloquean.
Cuando una organización no controla estos elementos, el agente se convierte en una entidad fantasma: actúa, accede y decide, pero no deja suficiente rastro para saber si debería haberlo hecho.
Fallas que abren la puerta
La primera falla es no tener inventario. Si la empresa no sabe qué agentes existen, no puede protegerlos. El inventario debe incluir owner, propósito, datos, herramientas, permisos, ubicación, ambiente y fecha de revisión.
La segunda falla es no asignar propietario humano. Un agente sin owner es una bomba de tiempo administrativa. Cuando aparece un incidente, nadie sabe si debe apagarse, rotarse, investigarse o justificarse.
La tercera falla es permitir privilegios permanentes. Un agente puede necesitar acceso temporal para una tarea, pero muchas organizaciones le dan permisos amplios “para que no falle”. Ese exceso se vuelve normal hasta que alguien lo explota.
La cuarta falla es no integrar IAM con recursos humanos. Cuando una persona deja la empresa, se revoca su cuenta, pero no siempre se revisan sus agentes, tokens, aplicaciones OAuth, secretos y automatizaciones.
La quinta falla es tratar la IA como software estático. Un agente cambia porque cambia su contexto, sus herramientas, sus permisos y sus datos. La seguridad debe evaluar comportamiento y flujo, no solo versión de código.
La sexta falla es no clasificar datos. Si el agente puede ingerir cualquier documento, también puede ingerir secretos, datos personales y propiedad intelectual. Sin clasificación, no hay control real.
La séptima falla es no auditar herramientas. Un agente con acceso a un MCP server, un webhook o una API interna puede ejecutar acciones críticas. Cada herramienta debe ser registrada y limitada.
Impacto: más allá de la fuga de datos
El impacto más evidente es la fuga de información. Un agente comprometido puede extraer código fuente, documentos, datos de clientes, secretos, embeddings o información financiera. Pero el impacto no termina ahí.
Técnicamente, puede modificar repositorios, alterar tickets, desplegar código, cambiar configuraciones o contaminar memoria. Puede crear persistencia mediante tokens, jobs, funciones serverless o cuentas de servicio. Puede servir como puente para movimiento lateral.
Operacionalmente, puede romper la confianza en automatizaciones internas. Si los equipos no saben si un agente está actuando bajo control, dejan de usarlo o requieren revisiones manuales. La productividad prometida por la IA se reduce.
Financieramente, una fuga puede generar costos de investigación, contención, rotación de credenciales, notificación legal, multas, pérdida de clientes y rediseño de arquitectura. En sectores regulados, el costo puede multiplicarse.
Legal y regulatoriamente, el problema toca controles de acceso, trazabilidad, gestión de proveedores, protección de datos y gobierno de sistemas automatizados. Una organización no puede defender fácilmente una postura de debida diligencia si no sabe qué agentes accedieron a qué datos.
Reputacionalmente, el daño puede ser profundo. No es lo mismo decir “un usuario fue comprometido” que decir “nuestros propios agentes de IA siguieron accediendo a datos sensibles sin dueño”. La segunda frase sugiere falta de gobierno en una tecnología que la organización vendió como controlada y estratégica.
Defensa: identidad, límite y memoria
Defenderse de agentes huérfanos exige saber ¿quién lo autorizó, qué datos toca, qué herramientas usa, cuándo expira y cómo se audita?.
La primera línea de defensa es el inventario. Toda automatización de IA debe registrarse. Si no está en el inventario, no debe acceder a datos productivos. El registro debe tener owner humano y sponsor de negocio. Debe indicar ambiente, datos, herramientas, permisos y fecha de revisión.
La segunda línea es el ciclo de vida. Todo agente debe nacer con fecha de revisión y expiración. Si el owner cambia de rol o deja la empresa, el agente debe transferirse, reducirse o eliminarse. El offboarding humano debe incluir offboarding de sus automatizaciones.
La tercera línea es el menor privilegio. Los agentes no deben recibir permisos amplios por comodidad. Deben obtener solo lo necesario, preferiblemente just-in-time, con condiciones de acceso y aprobación para acciones sensibles.
La cuarta línea es el control de secretos. Tokens, PATs, claves cloud, OAuth grants y webhooks deben rotarse, protegerse y monitorearse. Un secreto en un repositorio es una invitación para el desastre.
La quinta línea es el logging. Cada acción importante debe dejar rastro: identidad, agente, owner, herramienta, recurso, dato, política, resultado y aprobación. Sin logs, la investigación se convierte en especulación.
La sexta línea es el gateway de IA. Un gateway permite aplicar políticas, redactar datos sensibles, bloquear salidas no autorizadas, registrar uso de modelos y controlar herramientas. No reemplaza la arquitectura segura, pero da un punto de control central.
La séptima línea es la prueba continua. Los equipos deben simular abuso: ¿qué pasa si un agente recibe prompt injection?, ¿puede exfiltrar datos?, ¿puede invocar herramientas no autorizadas?, ¿puede seguir actuando después de que el owner deja la empresa? La seguridad se demuestra rompiendo el diseño antes de que lo rompa un atacante.
El papel de los marcos de referencia
Los marcos existentes ayudan, pero deben aplicarse con inteligencia. NIST AI RMF ofrece funciones útiles: gobernar, mapear, medir y gestionar riesgos de IA. MITRE ATLAS ayuda a modelar amenazas contra sistemas de IA. MITRE ATT&CK ayuda a mapear persistencia, movimiento lateral y exfiltración. OWASP GenAI y el LLM Top 10 recuerdan riesgos como prompt injection, divulgación sensible, agencia excesiva, supply chain y consumo ilimitado. CIS Controls e ISO/IEC 27001 aportan disciplina en inventario, control de acceso, logging, gestión de cambios y mejora continua. CISA Secure by Design insiste en responsabilidad y diseño seguro desde el origen.
La trampa sería usar estos marcos como decoración. No sirve llenar una matriz si no se revocan tokens. No sirve declarar gobierno de IA si nadie sabe qué agentes existen. No sirve citar ISO 27001 si las cuentas de servicio no se revisan. Los marcos son brújulas; los controles son el terreno.
Conclusión: gobernar la IA es gobernar la responsabilidad
La historia de los agentes de IA huérfanos no es una historia sobre máquinas rebeldes. Es una historia humana sobre responsabilidad. Las máquinas no piden permisos porque entiendan ética; los reciben porque alguien los configuró. No acceden a datos porque tengan ambición; acceden porque una credencial les abrió la puerta. No persisten porque sean maliciosas; persisten porque nadie las apagó.
El desafío para las organizaciones es tratar a los agentes de IA como lo que realmente son: identidades operativas con capacidad de acción. Deben tener dueño, propósito, límites, expiración, logs y revisión. Deben ser tan gobernadas como una cuenta privilegiada, tan auditadas como un proveedor y tan controladas como un sistema crítico.
Fuente
The Hacker News. “Orphaned AI Agents: How to Find Hidden Access Risks Inside Your Network.” https://thehackernews.com/2026/06/orphaned-ai-agents-how-to-find-hidden.html