A la shadow AI agéntica le da igual el nombre «Super Intelligence»

El 29 de septiembre de 2026, la Casa Blanca firmó la Orden Ejecutiva 14434, «Inaugurating the Era of Super Intelligence». La orden indica a las agencias federales que, en sus comunicaciones oficiales, usen «Super Intelligence», o «SI», en lugar de «AI». Intenta cambiar un término. No define ninguna tecnología nueva ni crea una nueva categoría de riesgo, así que no existe ninguna Shadow Super Intelligence para la que prepararse.

El riesgo que ya existe es la shadow AI agéntica (IA en la sombra basada en agentes): agentes autónomos que funcionan sin autorización ni supervisión. Son sistemas de IA que operan dentro de la organización sin que una persona apruebe cada acción y que tienen sus propias credenciales en lugar de tomar prestado el inicio de sesión de alguien. A ese tipo de agente le da igual cómo lo llame el Gobierno federal. El agente sigue teniendo el token OAuth, y el token sigue funcionando tanto si los documentos dicen AI como si dicen Super Intelligence.

Qué cambia realmente la orden sobre «Super Intelligence» (nada)

La Orden Ejecutiva 14434 es una directiva terminológica para el poder ejecutivo de Estados Unidos. Ordena a las agencias que escriban «Super Intelligence» («SI») en lugar de «AI» en los documentos oficiales sin rango legal. No impone obligaciones a las empresas privadas ni prevé sanciones. También pone en marcha un proceso de 60 días que podría terminar en una nueva definición legal.

El presidente Trump firmó la orden el 29 de septiembre de 2026. Se publicó en el Federal Register el 2 de octubre (91 Fed. Reg. 63129). Las disposiciones operativas:

• La sección 1 fija la política: en la medida máxima permitida por la ley, el poder ejecutivo usa «SI» en lugar de «AI» y «no reconocerá» los términos anteriores en ningún contexto aplicable.
• La sección 2(a) aplica la norma a la correspondencia oficial, las comunicaciones públicas, los sitios web, los informes, los documentos de políticas y otros documentos sin rango legal.
• La sección 2(b) establece que nada de lo dispuesto en esa sección obliga a modificar las regulaciones, las acciones presidenciales, los contratos, las subvenciones ni otros documentos históricos existentes.
• La sección 3(a) define «SI» remitiéndose a la definición legal vigente de IA en 15 U.S.C. § 9401(3). Esa definición se mantiene hasta que la sustituya una acción presidencial o una ley del Congreso.
• La sección 3(b) concede al asesor científico de la Casa Blanca 60 días para proponer un nuevo texto legislativo, que necesitaría una actuación independiente del Congreso para entrar en vigor.
• La sección 4(c) establece que la orden no crea derechos exigibles.

Redacción estricta, escaso efecto jurídico

El lenguaje de la orden es más estricto que su efecto. La sección 1 dice que el poder ejecutivo «no reconocerá» el término AI en ningún contexto aplicable; sin embargo, la propia orden usa «artificial intelligence» y ancla su definición de SI en 15 U.S.C. § 9401(3). Todas las obligaciones se aplican solo «en la medida máxima permitida por la ley» y solo a documentos sin rango legal, por lo que las leyes, las regulaciones, los contratos y las subvenciones siguen diciendo AI.

La sección 3(a) hace que SI signifique exactamente lo mismo que AI hoy, y la sección 4(c) no crea derechos exigibles. Los abogados de Arnold & Porter señalan que la orden no contiene ninguna disposición sancionadora ni de aplicación. La publicación del presidente del 8 de octubre, que calificaba de «EL ENEMIGO» a cualquiera que dijera «Artificial Intelligence», fue más allá que la orden, y la orden no establece consecuencias por ello. Las agencias cambian su vocabulario. La tecnología y su regulación siguen igual.

Ese es todo el alcance de la orden: un ejercicio de comunicación y una norma de vocabulario para los documentos de un solo gobierno. A los agentes ya conectados a sistemas de producción, con las credenciales que ya tienen, les da igual qué palabra aparezca en esos documentos.

Qué es realmente la shadow AI agéntica

La shadow AI agéntica es el uso no autorizado o no supervisado de agentes autónomos dentro de una organización. Estos agentes planifican y encadenan acciones por sí mismos, tienen sus propias credenciales y funcionan sin que una persona apruebe cada paso. A diferencia del shadow IT o la shadow AI general, no necesitan a nadie frente al teclado para actuar.

El shadow IT tradicional (TI en la sombra) consiste en que un empleado adopte una herramienta, como una aplicación de sincronización de archivos o un gestor de proyectos, sin pasar por el departamento de compras. La shadow AI general, la que tratan la mayoría de los artículos sobre gobernanza, es un empleado que pega datos en un chatbot público. En ambos casos una persona toma una decisión en el momento, y ambos acaban apareciendo en algún sitio: una nota de gastos, un registro de uso de SaaS, una entrada del historial del navegador.

La shadow AI agéntica funciona de otra manera. Un agente deja rastro una sola vez. Alguien conecta un bot de Slack, una integración de herramientas de ventas o un script que vigila un repositorio de código, y a partir de ese momento el agente actúa según su propio calendario. Se autentica con su propia clave de API, token OAuth o cuenta de servicio. Un token emitido una vez sigue funcionando hasta que alguien lo revoca, así que no existe ninguna decisión humana posterior que alguien pueda detectar o señalar.

Por qué el MCP agrava el problema

Los agentes basados en el Model Context Protocol (MCP) acceden a herramientas y fuentes de datos con la credencial con la que se configuró la integración. Heredan todo el acceso de esa credencial. Ese acceso suele ser más amplio que la única tarea para la que se creó el agente, y nadie revisa el alcance una vez que la integración funciona.

Algunos proveedores llaman a estos sistemas «shadow agents» (agentes en la sombra). Este artículo usa «shadow AI agéntica» en todo momento. Ambas etiquetas describen el mismo problema: agentes autónomos que nadie ha inventariado, con credenciales que nadie vigila.

Por qué la shadow AI agéntica es peor que el shadow IT

La shadow AI agéntica es más difícil de contener que el shadow IT porque los agentes se conectan a sistemas reales más rápido de lo que las organizaciones les asignan responsables, limitan el alcance de sus credenciales o los inventarían. El shadow IT necesita que una persona siga usando la herramienta. Un agente de IA sigue funcionando después de que su creador pase a otra cosa.

El desfase se aprecia en tres cifras publicadas.

• JumpCloud constató que el 83 % de las organizaciones gestiona más identidades no humanas (NHI), es decir, cuentas de servicio, claves de API y credenciales de agentes, que usuarios humanos. Solo el 21 % aplica gobernanza de accesos a esas identidades.
• Cyberhaven Labs registró un aumento interanual del 509 % en el uso empresarial de agentes de IA basados en endpoints entre febrero de 2025 y febrero de 2026. Solo los asistentes de programación crecieron un 357 %.
• Gartner predijo en agosto de 2025 que el 40 % de las aplicaciones empresariales incluiría agentes de IA específicos para tareas a finales de 2026, frente a menos del 5 % en 2025.

La adopción se acelera, y la gobernanza cubre una pequeña parte de las identidades implicadas. La mayoría de los equipos no puede responder al momento a la pregunta «¿a qué puede acceder esta credencial?». Sin esa respuesta, nadie puede limitar el alcance de la credencial, rotarla ni revocarla.

Lo que cuesta un vacío de control

El coste de una filtración de datos permite poner cifra al problema. El Cost of a Data Breach Report 2026 de IBM sitúa el coste medio mundial de una filtración en 4,99 millones de dólares, un récord y un aumento del 12 % respecto al año anterior. IBM no atribuye esa cifra a los agentes, así que debe leerse como el precio de ese tipo de fallo, no como el precio de la shadow AI agéntica.

Una credencial sin responsable es el mismo fallo tanto si la tiene una persona como un agente. La diferencia está en la detección. Una persona que hace un uso indebido de un acceso deja un evento de inicio de sesión. Un agente con un token válido genera tráfico que parece automatización rutinaria.

Dicho claramente: las organizaciones acumulan identidades no humanas (NHI) y conectan agentes a sistemas de producción mucho antes de crear los registros de responsables, la disciplina para limitar alcances y la monitorización.

Cómo se produce la proliferación de agentes de IA en las organizaciones

Siete vías llevan a la proliferación de agentes en organizaciones con gobernanza: herramientas para desarrolladores, pilotos que nunca terminan, agentes huérfanos, feature flags de proveedores, plataformas low-code, agentes personales y equipos externos. Cada una termina con un agente que tiene una credencial que ningún responsable central ha registrado.

1. Herramientas para desarrolladores. Los asistentes de programación y los servidores MCP que se ejecutan en local funcionan con los tokens de repositorio y las claves de la nube que ya están en el equipo del desarrollador. Se ejecutan en el endpoint, así que ninguna consola de administración de SaaS los muestra.
2. Un piloto que nunca terminó. Un equipo configura un agente para resolver una tarea molesta. Ahorra horas, los compañeros empiezan a depender de él y nadie programa la decisión de aprobarlo o desactivarlo. La clave con la que se creó conserva su alcance original.
3. Agentes huérfanos. La persona que creó un agente cambia de puesto o se marcha, y el agente sigue funcionando. Desactivar su cuenta de directorio no revoca necesariamente las autorizaciones OAuth y las claves de API que creó. Compruebe cómo se comporta cada uno de sus sistemas.
4. Un feature flag en una herramienta de confianza. Un proveedor incluye un agente en una actualización rutinaria y lo activa para todos los clientes. El agente accede a los datos a través de conexiones que el producto ya tiene. La revisión de seguridad archivada describe el producto tal como era hace un año.
5. Plataformas de agentes low-code. Los usuarios de negocio montan agentes en plataformas de flujos de trabajo para las que la empresa ya tiene licencia. Cada conexión que establece el agente se crea con la identidad de quien lo construye, así que el administrador de la plataforma ve aplicaciones, no las credenciales que hay detrás.
6. Un agente personal. Un empleado vincula un asistente a su bandeja de entrada, su calendario o su repositorio de código y le deja actuar con sus propios permisos. Esos permisos se concedieron para todo el trabajo de esa persona, así que el agente tiene mucho más alcance del que requiere su única tarea.
7. Equipos externos y adquiridos. Una agencia, un consultor o una empresa recién adquirida aporta agentes que ya funcionan con sus propias credenciales. Esas credenciales nunca pasan por el proceso de incorporación de la organización.

Dos brechas por credenciales con diez meses de diferencia

Dos incidentes concretos, con un año de diferencia, muestran lo que cuesta realmente una credencial de máquina sin gobernanza. En ambos casos, un token OAuth o una clave de acceso olvidados seguían conectados a una integración relacionada con la IA sin que nadie los vigilara, hasta que un atacante los encontró primero.

Salesloft Drift, agosto de 2025

El actor de amenazas UNC6395, al que sigue el Threat Intelligence Group de Google, explotó la integración del chatbot de IA Drift de Salesloft con Salesforce para obtener tokens OAuth de acceso y de actualización. Drift se conecta a la instancia de Salesforce del cliente para automatizar las conversaciones de ventas, y esa conexión funciona con una autorización OAuth permanente, no con un inicio de sesión puntual.

Una vez que UNC6395 tuvo tokens válidos, el ataque avanzó a velocidad de máquina: el grupo los usó para consultar directamente objetos de Salesforce y extraer todas las credenciales y los datos de casos a los que esos tokens podían acceder.

Desde ahí, el atacante extrajo claves de acceso de AWS, tokens de Snowflake, contraseñas almacenadas y datos de casos de soporte de los entornos conectados. El objetivo en todo momento fue la exfiltración de datos a través de un canal de confianza y ya autorizado, no una intrusión por la puerta principal. Un analista de amenazas de Google declaró a Cybersecurity Dive que más de 700 organizaciones podrían haberse visto afectadas. Cloudflare, Zscaler y Palo Alto Networks confirmaron que estaban entre ellas.

Klue, junio de 2026

El 11 de junio de 2026, un atacante usó un token de acceso personal de GitHub para introducir código no autorizado en el servicio de integración de Klue. El código recopilaba los tokens OAuth de acceso y de actualización que los clientes habían concedido a la aplicación Klue Battlecards. Con esos tokens, el atacante consultó los entornos de Salesforce de los clientes y exportó contactos, oportunidades, presupuestos y notas de ventas.

Según el resumen de la investigación de CrowdStrike encargada por Klue, citado por el NHI Management Group, el token había sido «comprometido previamente». Huntress lo describe como un token sin uso desde hacía tiempo, pero todavía activo. Klue declaró a TechCrunch que se emitió para un tercero en 2022 para un piloto limitado. Salesforce alertó a Klue el 12 de junio, y Klue revocó los tokens y rotó las credenciales esa misma mañana. El grupo de extorsión Icarus reivindicó el ataque.

Klue no ha publicado el número de víctimas. A 25 de junio, al menos once empresas habían confirmado que se vieron afectadas, entre ellas Huntress, Recorded Future, Tanium, Jamf, Gong, HackerOne, Snyk, OneTrust, Insurity y Sprout Social. Un segundo grupo de extorsión afirmó haber afectado a 195 clientes, y esa afirmación no está verificada.

Qué tienen en común los dos incidentes

Los puntos de entrada son distintos. En Klue fue un token obsoleto de control de código fuente. Las fuentes sobre Drift describen el uso de tokens OAuth robados, no cómo se obtuvieron. La exposición común es una credencial no humana con acceso permanente a datos de clientes, en manos de un proveedor y utilizable sin un evento de inicio de sesión. El tráfico de un token válido parece el de la propia integración.

El token de Klue siguió siendo válido unos cuatro años después de que terminara un piloto. Los tokens de Drift siguieron siendo válidos hasta que alguien los revocó.

Riesgos de la shadow AI agéntica

La shadow AI agéntica genera cinco riesgos: credenciales de larga duración expuestas, actividad que parece tráfico normal, agencia excesiva (Excessive Agency), encadenamiento de credenciales entre agentes y carencias de cumplimiento normativo. Todos tienen una misma causa. El agente actúa por su cuenta con una credencial que nadie ha inventariado, limitado ni revisado.

Credenciales de larga duración que sobreviven a su propósito

Un agente sigue funcionando mientras su clave o su token sean válidos, y nada en el agente obliga a revisarlos. Las credenciales de los pilotos rara vez se rotan y a menudo conservan el alcance amplio que tenían durante las pruebas.

Klue es el caso más claro. Según la propia versión de la empresa, un token emitido en 2022 para un piloto limitado seguía siendo válido cuando los atacantes lo usaron en junio de 2026. Nadie había decidido conservarlo. Tampoco nadie había decidido retirarlo.

Actividad que parece tráfico normal

Un agente se autentica con su propia clave de API o token OAuth, así que no existe ningún evento de inicio de sesión humano que señalar. Sus solicitudes proceden de una integración conocida, a intervalos regulares, a través de API aprobadas. Las reglas de detección diseñadas para contraseñas de usuario robadas no tienen nada con lo que coincidir.

Por eso, la pérdida de datos a través de un agente suele detectarse tarde. La primera señal suele ser un aviso del proveedor o una factura inusual, no una alerta en el SIEM.

Agencia excesiva (Excessive Agency)

Los agentes que acceden a herramientas y datos mediante MCP heredan los permisos de la cuenta de servicio que hay detrás. Esos permisos suelen concederse para una amplia gama de tareas, no para la que realiza el agente. Esa diferencia es la superficie de ataque.

OWASP recoge este patrón como Excessive Agency (LLM06:2025) en su Top 10 para aplicaciones LLM. Un agente que lee contenido no fiable, como un correo electrónico o una página web, puede ser manipulado para usar accesos que nunca debió tener. Un alcance reducido limita lo que puede conseguir una inyección de prompts (prompt injection) que tenga éxito.

Encadenamiento de credenciales entre agentes

Cuando un agente llama a otro, el agente receptor suele recibir la credencial del agente que llama o un token derivado de ella. Comprometer el agente más débil abre entonces todo lo que puede tocar el más fuerte. Los agentes no registrados lo empeoran, porque nadie ha trazado qué agente confía en cuál.

Carencias de cumplimiento y auditoría

Un agente no inventariado procesa datos fuera de los registros y controles de la organización. El artículo 32 del RGPD exige «medidas técnicas y organizativas apropiadas» para proteger los datos personales, y es difícil defender como tal una credencial sin responsable. La Directiva NIS2, artículo 21, apartado 2, letra i), incluye las políticas de control de acceso y la gestión de activos entre las medidas de gestión de riesgos obligatorias.

Gobernar la shadow AI agéntica: Lista de verificación en 5 pasos

La lista de verificación de credenciales de agentes en 5 pasos gobierna la shadow AI agéntica a través de las credenciales con las que funcionan los agentes. Localice cada agente y sus secretos, asigne a cada uno una identidad propia con alcance limitado, designe un responsable de negocio y uno técnico, fije límites de ejecución y, por último, registre, pruebe y revoque de forma periódica.

Paso 1. Descubrir los agentes a través de las credenciales que tienen

Los agentes son fáciles de pasar por alto, pero sus credenciales dejan registros en los sistemas que tocan. Busque primero en estos lugares:

• autorizaciones OAuth y aplicaciones conectadas en cada consola de administración de SaaS
• cuentas de servicio y entidades de servicio en el proveedor de identidad y en las cuentas en la nube
• almacenes de secretos, variables de repositorio y configuración de CI/CD
• listas de consumidores de la pasarela de API
• endpoints: asistentes instalados, extensiones del navegador y archivos de configuración del Model Context Protocol (MCP)

Para cada agente, registre a qué puede acceder, a qué herramientas o API llama, qué datos lee o escribe y quién lo activó. La primera pasada será incompleta. Repítala periódicamente, porque los nuevos agentes aparecen más rápido de lo que permiten las revisiones trimestrales.

Paso 2. Asignar a cada agente su propia identidad y limitar su alcance

Un agente nunca debería funcionar con una cuenta compartida ni con el inicio de sesión personal de un empleado. Cree una identidad por agente, vinculada a su carga de trabajo. Después, elimine los permisos amplios que el agente acumuló durante las pruebas, para que el acceso se ajuste a la única tarea que realiza en producción.

La misma regla se aplica a los agentes que llaman a otros agentes. Cada agente se autentica por su cuenta, y la credencial de un agente nunca se transmite a otro.

En Passwork, una cuenta de servicio es una cuenta no interactiva diseñada para la automatización. Una cuenta de servicio puede tener varios tokens de API con alcance limitado, de modo que cada agente o pipeline tiene el suyo. Las políticas de bóveda definen quién administra cada tipo de bóveda, así que una bóveda para credenciales de agentes tiene administradores corporativos desde su creación. Rotar una credencial no interrumpe los pipelines que dependen de la cuenta.

Pruebe los tokens de cuentas de servicio con alcance limitado y las políticas de bóveda con las credenciales de sus propios agentes. Probar Passwork gratis en su infraestructura.

Paso 3. Designar un responsable de negocio y un responsable técnico

Cada credencial necesita dos personas. El responsable de negocio asume la responsabilidad de para qué sirve el agente y qué riesgo es tolerable. El responsable técnico se encarga del acceso en ejecución, los logs y el mantenimiento. Sin ambos, nadie puede decir si una credencial debería seguir existiendo.

Klue muestra lo que cuesta un campo de responsable vacío. Según la propia versión de la empresa, un token emitido en 2022 para un piloto limitado seguía siendo válido cuando los atacantes lo usaron en junio de 2026. Guarde los responsables, el propósito y una fecha de revisión junto a la credencial. Cuando un responsable cambie de puesto o se marche, reasigne la credencial en el mismo ticket.

Paso 4. Fijar límites de ejecución antes de que el agente entre en producción

Documente lo que el agente puede hacer y lo que nunca debe hacer, y ajuste la profundidad de la revisión a su autonomía. Un agente que solo lee un calendario necesita una lista de verificación breve. Un agente que mueve dinero o escribe en sistemas externos necesita una revisión formal de riesgos y una aprobación.

Una vez que el agente esté en funcionamiento, aplique los límites fuera de su propia capa de razonamiento:

• restrinja a qué herramientas puede llamar y valide lo que entra y sale de cada llamada
• impida que los secretos y los datos personales salgan mediante subidas de archivos o el portapapeles
• exija aprobación humana para pagos, cambios de permisos y escrituras en API externas

Prohibir todas las herramientas no aprobadas aleja el trabajo de la vista. Ofrezca una vía autorizada que sea más rápida que la solución alternativa, como una plataforma interna de agentes con estos límites ya incorporados.

Paso 5. Registrar, probar y retirar

Envíe la actividad de los agentes al SIEM. En Passwork, el registro de actividad recoge quién leyó o modificó una credencial y se exporta a Syslog o a un SIEM. Configure alertas cuando se use un token desde un origen nuevo o con un volumen inusual.

Dos simulacros muestran si los controles funcionan:

1. Prueba de trazabilidad: elija una acción automatizada y siga su rastro hasta la persona que la autorizó y los datos que usó.
2. Simulacro de revocación: mida cuánto se tarda en cortar el acceso de un agente en todos los sistemas que toca.

Revise cada agente en su fecha de revisión. Busque permisos que hayan crecido desde el lanzamiento, rote sus credenciales y retire los agentes que ya no tengan un propósito. El Threat Intelligence Group de Google dio a los clientes el mismo consejo tras la brecha de Drift: revisar las integraciones conectadas y, después, revocar y rotar sus credenciales.

Conclusión

La etiqueta cambió el 29 de septiembre de 2026. El riesgo de fondo, no. La shadow AI agéntica, es decir, un agente autónomo con una credencial activa y sin rotar de la que nadie es responsable, era exactamente igual de peligrosa el día antes de la Orden Ejecutiva 14434 que el día después. Salesloft Drift y Klue, con un año de diferencia, ya lo demostraron por partida doble.

Empiece esta semana con el primer paso de la lista de verificación anterior: un inventario completo de qué agentes tienen qué credenciales. Nada más de la lista funciona hasta que exista ese inventario, porque no se puede limitar ni rotar lo que no se ha encontrado. Es también el único paso que cualquier equipo de seguridad puede empezar hoy, sin esperar a tener presupuesto, una nueva plataforma o una reescritura de políticas motivada por una orden federal que no tiene nada que ver con las credenciales que hay ahora mismo en su entorno.

La higiene de credenciales de los agentes de IA empieza igual que la de los empleados: saber qué accesos existen, quién es su responsable y cuándo se rotaron por última vez. Probar Passwork gratis.

Preguntas frecuentes

Passwork 7.7: Modo sin conexión seguro para aplicaciones de escritorio y móviles

Las contraseñas ahora también funcionan sin conexión. Passwork 7.7 ofrece acceso sin conexión seguro con supervisión completa del administrador, controles de archivos adjuntos para toda la organización y cinco nuevas guías de incorporación por rol para una implementación más fluida.

PassworkPasswork Team

Passwork 7.6: Cuentas de servicio

La última versión de Passwork añade cuentas de servicio compatibles con varios tokens de API, filtros guardados, interfaz web para dispositivos móviles y vaciado automático de la papelera. Consulte qué ha cambiado.

PassworkPasswork Team

Qué es la shadow AI: La amenaza oculta que cuesta a las empresas 670 000 dólares por brecha

La shadow AI cuesta a las empresas 670 000 dólares adicionales por brecha, y la mayor parte se debe a credenciales pegadas en LLM públicos. Conozca cómo es realmente la shadow AI, por qué es más difícil de frenar que el shadow IT y cómo gobernarla.

PassworkAlex Muntyan