La primera ola de preocupaciones sobre la IA empresarial fue sencilla. Era simplemente un empleado que pegaba datos confidenciales en una herramienta pública de inteligencia artificial. Los equipos de seguridad respondieron con políticas de uso, bloqueo de dominios y reglas de prevención de pérdida de datos. Esa respuesta tenía sentido en ese momento.
Eso ya no se aplica a mí.
Shadow AI ha pasado de ser un problema de fuga de datos a un problema de control de acceso. La amenaza no se trata de lo que los empleados aportan a las herramientas de IA. Qué agentes de IA se están ejecutando dentro de su organización, qué agentes de IA están conectados a qué sistemas corporativos y qué acciones pueden o no tomar.
De herramienta pasiva a actor activo
Los empleados y las líneas de negocio están creando agentes de IA a un ritmo que la mayoría de los equipos de seguridad ni siquiera pueden comprender. Se están creando asistentes personalizados, agentes de codificación, automatización del flujo de trabajo y aplicaciones de agentes en todos los departamentos, algunos en plataformas autorizadas, pero muchos utilizan extensiones de navegador, funcionalidad SaaS nativa, herramientas de desarrollo, servidores MCP, agentes basados en terminales y scripts personalizados. Muchos comienzan con experimentos sencillos. Algunos pueden integrarse en procesos comerciales críticos en cuestión de días.
El perfil de riesgo de estos agentes es fundamentalmente diferente al de la TI tradicional en la sombra. Las aplicaciones SaaS no autorizadas son destinos de datos. Un agente de IA es un actor que puede llamar a API, usar credenciales almacenadas, recuperar registros, cambiar configuraciones, desencadenar flujos de trabajo posteriores y realizar acciones en sistemas de producción, a menudo sin requerir que un humano apruebe explícitamente cada paso.
Que un empleado pegue registros de clientes en una herramienta pública de inteligencia artificial es un incidente de violación de datos. Agentes de IA personalizados conectados a Salesforce, Snowflake, GitHub, Gong y Slack esperando que ocurran incidentes de control de acceso. Aunque pueden exponer datos, también pueden realizar acciones de lectura, escritura y eliminación de esos datos. También puede ejecutarse en una cuenta de servicio con permisos que nadie ha auditado y permanecer activo hasta seis meses después de que el empleado que lo creó cambie de rol o deje la empresa. Una nueva investigación de Token Security y Cloud Security Alliance muestra exactamente cuán extendido está este peligro.
¿Por qué los controles existentes no llegan allí?
La mayoría de los controles de seguridad empresarial están diseñados teniendo en cuenta la identidad humana y las cargas de trabajo críticas. Las políticas de IAM, las reglas de DLP y la supervisión de la red suponen un comportamiento predecible y rutas de acceso definidas. Los agentes de IA rompen estos supuestos.
Un agente encargado de resolver una implementación fallida utiliza las mismas credenciales heredadas para leer registros, consultar sistemas de monitoreo, cambiar configuraciones de infraestructura, abrir tickets, activar canales de automatización y notificar a los equipos de ingeniería, todo en secuencia. Para evitar interrupciones en el flujo de trabajo, los desarrolladores otorgan amplios permisos por adelantado. Estos privilegios son acumulativos. Los agentes heredan permisos a nivel de autor, el acceso temporal se vuelve permanente y los equipos de seguridad e identidad pierden visibilidad de lo que esas identidades están haciendo realmente.
Esto no se logrará bloqueando los dominios públicos de IA. Cuando el agente obtiene las credenciales para el sistema empresarial, el límite ya se ha cruzado. Las identidades no humanas autocurativas llenan ese vacío.
¿Cómo es un inventario real de IA en la sombra?
Para descubrir la IA en la sombra, debe observar todo el entorno donde realmente residen sus agentes, incluidas las plataformas de IA, las aplicaciones SaaS con automatización incorporada, las cuentas en la nube, las herramientas de desarrollo, los puntos finales y los proveedores de identidad. Aquí hay seis preguntas que debe hacerle a su equipo de seguridad para determinar si realmente tienen el control.
¿Dónde se crean o instalan los agentes? Esto incluye no sólo plataformas obvias de IA, sino también asistentes de codificación, funcionalidad de agente nativo SaaS, herramientas de desarrollo local y aplicaciones internas que añaden capacidades de IA de forma encubierta. ¿Quién es el propietario de cada agente y quién puede utilizarlo? Sin propiedad no hay rendición de cuentas. Un agente creado para un equipo financiero de tres personas compartido en una organización tiene un perfil de riesgo muy diferente al de un agente dirigido a un solo usuario. ¿A qué recursos y servicios están conectados los agentes? Los agentes pueden parecer benignos a nivel de plataforma, incluso aunque mantengan conexiones con bases de datos confidenciales o sistemas operativos a través de credenciales otorgadas de forma privada y nunca verificadas. ¿Qué identidades y secretos usarás? Los agentes se autentican a través de cuentas de servicio, claves API, tokens OAuth, roles de IAM en la nube y secretos de larga duración. Cada tipo de credencial conlleva diferentes riesgos. ¿Cuáles son las intenciones y acciones reales del agente? La configuración por sí sola no indica si el agente está leyendo datos, escribiendo registros o accediendo a sistemas fuera de su alcance previsto. Priorizar las respuestas requiere comprender el contexto de las intenciones y acciones. ¿Siguen activos los agentes? Los datos de Agentic Pulse de Token Security muestran que el 65,4% de los chatbots de agentes nunca se han utilizado desde su creación, pero sus credenciales permanecen activas. Los agentes inactivos con acceso en vivo son persistentes y están infravalorados.
Curva de madurez para asegurar la IA del agente
La mayoría de las organizaciones se encuentran en las primeras etapas de este problema y tienen poco o ningún inventario de agentes. El siguiente paso es obtener visibilidad parcial de qué agentes están presentes sin el contexto completo. Luego se requiere enriquecimiento y contexto para comprender la intención y asignar la propiedad, el acceso y las credenciales a cada agente. El siguiente paso es aplicar controles automatizados que corrijan privilegios excesivos, notifiquen a los propietarios de agentes inactivos y señalen nuevos agentes que se conectan a sistemas confidenciales.
El objetivo no es impedir la adopción de la IA. Los equipos están bajo una tremenda presión para utilizar estas herramientas y muchas de las ganancias de productividad son legítimas. Cuando la seguridad se convierte en un fuerte obstáculo, su uso se hace más clandestino y fuera de la vista. Un mejor resultado es la habilitación administrada, que proporciona a los equipos una ruta para implementar agentes con controles automatizados que se ejecutan continuamente en segundo plano.
Esto requiere tratar a los agentes de IA de la misma manera que trata a otras identidades dentro de su empresa, con descubrimiento continuo, propiedad definida, acceso con alcance y gestión del ciclo de vida desde la creación hasta el retiro.
La cuestión de la IA en las sombras ha cambiado. Ya no es una cuestión de «¿Qué datos ingresan mis empleados en la IA?» Se trata de qué agentes operan en nuestro entorno y a qué les hemos dado acceso. Esas son preguntas diferentes. El segundo define la exposición y el riesgo de la organización. Si está abordando ese inventario ahora mismo, vale la pena ver cómo otros lo están abordando.
Source link
