Las amenazas internas no se definen por el puesto de trabajo, sino por el nivel de acceso: quién o qué tiene credenciales legítimas, permisos legítimos y una razón legítima para estar dentro de tu entorno. Según esa definición, un agente de IA que puede leer tu bandeja de entrada, tocar tus recursos compartidos de archivos o ejecutar código en un endpoint cumple con todos los requisitos.

Si no le das a un agente de IA una identidad claramente definida, un atacante puede asignarle una en su lugar. Sin su propio inicio de sesión, sus propios permisos delimitados y su propio registro de auditoría, un agente es solo un conjunto de credenciales sin etiquetar esperando a que alguien las tome. Una vez que eso ocurre, el agente hará exactamente lo que se le indique, sin importar quién lo esté indicando. Sin dudar, sin cuestionarse, sin un momento de reflexión.

Esa es la parte para la que los controles de seguridad tradicionales no están diseñados. Un empleado malicioso todavía tiene que escribir los comandos él mismo, uno por uno, con tiempo para reconsiderar. Un agente de IA secuestrado o mal dirigido simplemente continúa, ejecutando a velocidad de máquina sin ninguna de las dudas que podrían hacer que una persona se detenga y se pregunte: "Espera, ¿debería realmente estar haciendo esto?". Estos agentes están orientados a objetivos, no sujetos a reglas: apúntalos hacia una meta y encontrarán un camino hacia ella, aunque ese camino pase directamente por tu base de datos de producción o los datos de tus clientes. Un error de lógica o una sola instrucción envenenada es todo lo que se necesita para que ese camino termine en algún lugar que nunca aprobaste, y para cuando alguien se da cuenta, el daño ya está hecho.

Esto no es un problema futuro. La investigación de Huntress ya ha encontrado ejemplos reales de agentes de IA que crean exactamente el tipo de riesgo que esta guía busca ayudarte a abordar.

1. Agentes con más acceso del que nadie aprobó

Nuestra investigación sobre OpenClaw encontró agentes de IA apareciendo como aplicaciones cloud en tenants de Microsoft con conjuntos de permisos indistinguibles de herramientas administrativas de alto valor: acceso de lectura y escritura a todo el directorio, la capacidad de modificar métodos de autenticación, e incluso el poder de otorgar permisos de OAuth en nombre de otros usuarios. En muchos casos, un solo empleado había otorgado al agente acceso a su buzón de correo o calendario con un solo clic, y nadie más adelante revisó qué permitía realmente ese acceso. La etiqueta de la aplicación apenas importa una vez que te das cuenta de lo que se le ha entregado. Eso es una amenaza interna con un nombre conocido.

2. Agentes que enturbian la investigación durante un incidente real

No todo agente riesgoso es malicioso, ni siquiera está mal configurado. En un incidente que investigó nuestro Centro de operaciones de seguridad (SOC), un usuario legítimo recurrió a Codex de OpenAI para solucionar problemas en una máquina que, sin que él lo supiera, ya estaba comprometida por criptomineros y ladrones de credenciales. Los comandos de Codex, con el mismo formato que usa un atacante para sus comandos, activaron detecciones y añadieron ruido que nuestros analistas tuvieron que revisar manualmente. El usuario no hizo nada mal. Pero la actividad del agente de IA se parecía tanto a las técnicas de un atacante que complicó la misma investigación que debía ayudar.

3. Atacantes que explotan la confianza que depositas en la IA

Lo que podría ser el ejemplo más inquietante ni siquiera requiere que un agente esté comprometido; solo requiere que tú confíes en uno. Huntress descubrió una campaña en la que atacantes sembraron conversaciones de ChatGPT y Grok con instrucciones maliciosas para una búsqueda común como "liberar espacio en disco en macOS", y luego usaron técnicas clásicas de SEO poisoning para impulsar esas conversaciones de ChatGPT y Grok a los primeros lugares de los resultados de Google. Las víctimas buscaron, hicieron clic y copiaron y pegaron un comando de Terminal directamente desde lo que parecía un asistente de IA útil. Ese solo copiar y pegar entregó un payload completo de Atomic macOS Stealer (AMOS), lo que permitió el robo de credenciales, acceso root y malware persistente, sin necesidad de ningún correo de phishing.

Como lo expresó nuestro equipo, "El malware ya no necesita parecer software legítimo. Solo necesita parecer útil".

Los controles de acceso tradicionales toman decisiones a nivel de un usuario, un dispositivo o una dirección IP. Los agentes de IA no encajan claramente en ninguna de esas categorías, lo que crea vacíos que la mayoría de los stacks de seguridad no fueron diseñados para cerrar:

• El vacío de identidad. Una sola estación de trabajo o carga de trabajo en la cloud puede ejecutar múltiples agentes, cada uno persiguiendo objetivos distintos con datos distintos. Si tus herramientas solo pueden ver el host y no el agente, te quedan dos opciones malas: permitir todo o bloquear todo.
• El vacío de la IA en la sombra. Los agentes se instalan a través de herramientas de desarrollo, extensiones de navegador y scripts de automatización, no mediante procesos formales de implementación. Si no puedes ver cuándo un software está llamando a un LLM, invocando un servidor MCP o moviendo datos entre sistemas, tu inventario de activos está desactualizado.
• El vacío de criterio. La mayoría de los empleados humanos saben, sin que se les diga, que el código propietario no debería terminar en un foro público. Un agente de IA solo sabe lo que se le ha permitido hacer. Dale acceso lo bastante amplio, y lo usará por completo mientras parece actuar según lo previsto todo el tiempo.

La solución no es restringir tanto a los agentes que se vuelvan inútiles, ni tampoco quedarse de brazos cruzados esperando que nunca se vean comprometidos. Tanto las investigaciones propias de Huntress como los expertos externos apuntan a la misma respuesta: trata a los agentes de IA como tratarías a cualquier nuevo empleado con acceso real a tus sistemas.

• Dale a cada agente su propia identidad. Sin claves de API compartidas, sin aprovechar las credenciales de una persona. Si no puedes identificar qué agente hizo qué, no puedes investigar nada.
• Delimita los permisos como lo harías con un nuevo empleado. Aplica el principio de privilegio mínimo a los agentes de IA de la misma manera en que lo harías con una persona: da acceso exactamente a lo que el trabajo requiere y nada más.
• Observa el comportamiento, no solo la intención. Establece una base de lo que es "normal" para cada agente, incluyendo tokens procesados, aplicaciones utilizadas y datos a los que accede, y luego marca las desviaciones. Trata la actividad inusual de un agente de la misma manera en que la tratarías viniendo de un empleado.
• Trata cada modelo, plugin y servidor MCP como a un proveedor sin verificar. Ya circulan servidores MCP fraudulentos y habilidades maliciosas. No supongas que una integración es segura solo porque fue fácil de instalar.
• Crea un plan de respuesta para cuando un agente se vea comprometido, no si eso ocurre. Como dijo Brian Madden en el blog de Citrix, "No sirve de mucho preguntarse si los agentes de IA pueden verse comprometidos. Pueden serlo y lo serán". Tu trabajo es asegurarte de poder detectar, contener y responder cuando eso suceda.

Los riesgos de seguridad de los agentes de IA no son un problema futuro para planear más adelante. Ya están apareciendo hoy en los entornos de los clientes, escondidos detrás de la misma etiqueta útil y de aumento de productividad que logró que se aprobaran en primer lugar.

Huntress Managed ITDR te da un inventario de Aplicaciones Fraudulentas (las aplicaciones fraudulentas) para encontrar agentes de IA como OpenClaw que operan en tus entornos de Microsoft 365 y Google Workspace, junto con los permisos que se les otorgaron y quién los aprobó. Combina eso con Huntress Managed SIEM para rastrear la identidad y la actividad de registro vinculadas a un agente después de su instalación: a qué accedió, cuándo y con qué otras identidades tuvo contacto.

El objetivo no es prohibir los agentes de IA en tu negocio. Es someterlos al mismo nivel de escrutinio que le darías a cualquier persona nueva con acceso a tus sistemas. Obtén una demo para ver cómo Huntress te ayuda a encontrar, vigilar y contener los agentes de IA que ya operan en tu entorno.