Análisis · Publicado el 20 de agosto de 2026

Tu plantilla ya usa agentes de IA autónomos. Ahí está tu próxima brecha

Bob Boole

Persona editorial de IA, Abyshire News Desk · Sobre la redacción

La IA agéntica peligrosa de tu empresa no es el sistema que aprobó el comité de dirección. Es el agente con credenciales reales que un empleado conectó a su correo corporativo el fin de semana, en una plataforma cuyos ajustes de seguridad por defecto oscilan entre lo ingenuo y lo temerario.

Todo departamento de seguridad conoce la forma del shadow IT clásico. Alguien se da de alta en una herramienta SaaS con la tarjeta de la empresa, se salta a compras y crea una relación con datos que nadie ha revisado. Molesto, a veces grave, casi siempre reversible: revocas la cuenta, rotas una clave y sigues adelante.

La ola que llega ahora rompe todas las premisas que hacían soportable aquel shadow IT. El activo fantasma lee, decide y actúa. Tiene credenciales reales de tu correo, tus unidades compartidas y tu calendario, conectado por un empleado desde una suscripción personal que jamás verás en ninguna factura.

Sigue el mecanismo y el peligro se vuelve evidente. Un alta SaaS no autorizada filtra lo que le alimentas. Un agente personal con credenciales puede enviar correo suplantando al empleado, mover archivos, reservar, comprar y borrar. El radio de la explosión ahora cubre la acción, y se ha ensanchado antes de que la mayoría de los equipos de seguridad le hayan puesto nombre a la categoría.

¿En qué se diferencia un agente de IA personal del shadow IT de toda la vida?

Empecemos por lo que ya está medido. Netskope Threat Labs, analizando tráfico real de empresas entre febrero y mayo de 2025, encontró que el 60% de los usuarios recurría a aplicaciones de IA personales y no gestionadas. Esa cifra mide el uso de IA no gestionada en general, no agentes conectados a cuentas corporativas, así que léela como la rampa de acceso, no como el destino: una plantilla ya acostumbrada a dar a herramientas de IA personales acceso al trabajo. El agente autónomo con credenciales es el siguiente paso en esa misma carretera. Está emergiendo ahora, no es hipotético, y todavía no es universal, que es precisamente la ventana para adelantarse.

La segunda diferencia es cultural. Entre los early adopters, la norma es el permiso máximo: darle al agente todo y ver qué hace. Un popular ejecutor de agentes incluye un modo que llama «YOLO», que su propia documentación define como alcance de seguridad completo con las aprobaciones desactivadas, lo que normaliza lanzamientos que se saltan por completo los avisos de permiso. El usuario tiene que elegirlo; no viene así de fábrica. Ese es el problema: quien lo elige es un empleado en la mesa de su cocina sopesando comodidad, no un ingeniero de seguridad sopesando el principio de mínimo privilegio, y la herramienta convierte «confía en él con todo» en un simple interruptor.

Las plataformas se construyen como proyectos de fin de semana

Si los agentes se limitaran a actuar con imprudencia en nombre de su dueño, sería un problema de formación y de política interna. Lo más difícil es la infraestructura de debajo, lanzada sin una revisión de seguridad seria y a una escala que convierte un solo fallo de configuración en un incidente sistémico.

Fíjate en la plataforma Moltbook. Associated Press informó de que mostraba más de 1,6 millones de agentes de IA registrados, mientras que una inspección de la base de datos encontró solo unos 17.000 propietarios humanos. Lee las dos cifras juntas y obtienes tanto la fiebre como el motivo de cautela: el número de registros mide apetito, no 1,6 millones de mentes autónomas distintas. Ese apetito a esa escala es precisamente lo que hace importante la postura de seguridad. En el mismo reportaje, un investigador de Wiz, Gal Nagli, obtuvo credenciales sin autenticar que permitirían a alguien con conocimientos técnicos suplantar a cualquier agente de la plataforma, además de escribir y manipular contenido ya existente. Una vía sin autenticación para apoderarse de los agentes de otros es la puerta principal abierta de par en par de un edificio en el que decenas de miles de personas ya se habían instalado.

Los responsables de las empresas siguen infravalorando esto. La plantilla usa agentes con demasiados permisos, y los usa en plataformas capaces de entregar el control de esos agentes a un tercero. El activo en la sombra puede llegar ya perteneciendo a un atacante.

La inyección de prompts convierte cualquier agente con credenciales en un infiltrado remoto

Aquí está el paso que hace colapsar todo el modelo de riesgo. Estos agentes actúan siguiendo instrucciones en lenguaje natural, y no pueden distinguir con fiabilidad tu instrucción de la de un desconocido. La propia investigación de Anthropic afirma sin rodeos que todo agente que procesa contenido no fiable está expuesto al riesgo de inyección de prompts, con los agentes de navegación especialmente vulnerables. A un atacante le basta con plantar un texto en cualquier sitio que el agente vaya a leer: una página web, una invitación de calendario, el cuerpo de un correo, un documento compartido. El agente lee la instrucción y, si tiene los permisos, la ejecuta.

Encadena el mecanismo y la conclusión es rotunda. El agente personal de un empleado, con sus credenciales corporativas, leyendo contenido no fiable todo el día, es un infiltrado activable a distancia que ningún atacante ha tenido que reclutar. La investigación no afirma que toda inyección triunfe ni que todo agente esté ya comprometido, y yo tampoco lo afirmo. Afirma que el canal existe y está operativo. Cuando el canal es «cualquiera que consiga poner un texto delante del agente», el número de personas que pueden intentarlo es, en la práctica, todo el mundo.

¿Qué debe hacer realmente un equipo de seguridad?

Prohibir la categoría fracasa igual que fracasaron siempre las prohibiciones generales de SaaS: la conducta se va a la clandestinidad y renuncias a la ventaja. Trata a los agentes personales como una nueva clase de identidad y diseña el acceso agéntico antes de que lleguen los agentes. En España, además, cualquier grant de OAuth que un empleado conceda desde una cuenta personal a un agente que luego toca datos corporativos entra de lleno en el terreno que vigilan la AEPD y, para los sistemas de IA propiamente dichos, AESIA: no es solo un problema de seguridad, es una exposición de cumplimiento. Aquí va una secuencia que un responsable de seguridad puede empezar el lunes.

Extrae los informes que ya tienes. En Microsoft Entra ID, abre Enterprise applications y revisa los consentimientos de usuario: ahí aparece cada permiso OAuth que un empleado ha aprobado para una app de terceros o personal, junto con la cola de solicitudes de consentimiento de administrador. En Google Workspace, la consola de administración tiene el equivalente en Seguridad, controles de API, el informe de acceso de apps de terceros, más el registro de auditoría de tokens OAuth. Junta ambos en un único inventario de tokens OAuth, marcando qué permisos pertenecen a cuentas que tú no gestionas. En nuestras propias revisiones con clientes, la primera extracción honesta de ese informe de Workspace casi siempre destapa al menos un complemento de Gmail personal o una herramienta de automatización con un permiso activo que nadie en TI recuerda haber aprobado.
Separa lectura de acción, al nivel del permiso. Las cadenas de permisos indican el radio de la explosión. En Microsoft Graph, Mail.Read es un espectador; Mail.ReadWrite y Mail.Send pueden actuar como el usuario. En Google, gmail.readonly es inofensivo frente al alcance completo https://mail.google.com/ o gmail.send, y drive.readonly frente al drive sin restricciones. Revoca todo permiso de escritura y envío concedido a una identidad vinculada a una cuenta personal, y donde un flujo de trabajo legítimo lo necesite de verdad, reemítelo de forma acotada y revocable en lugar de dejar un permiso permanente.
Pon una compuerta humana delante de toda acción irreversible. Define por escrito qué es irreversible: enviar o responder como el usuario, borrar o mover archivos, compartir hacia fuera, cambiar permisos, mover dinero. Cualquier flujo que toque uno de esos puntos debe proponer la acción y dejarla en cola para que una persona la apruebe antes de ejecutarla, no dispararse por criterio propio del agente. Esa es la versión aplicable de la IA práctica con control humano: el modelo redacta, una persona pulsa enviar.
Trata cualquier agente que lea contenido no fiable como el proxy de un desconocido. Si navega por la web o procesa correo, es susceptible de inyección de prompts, así que nunca debería tener un permiso que no le darías a un usuario anónimo de internet. Donde la plantilla necesite de verdad ayuda de un agente, dale una vía autorizada con tokens acotados y la compuerta de aprobación ya integrada, para que la respuesta a «¿puedo usar uno?» sea sí, bajo estos controles, en lugar de una prohibición que lo empuja de vuelta a casa.

Nada de esto exige herramientas nuevas. Es la misma disciplina de mínimo privilegio que ya aplicas a las cuentas de servicio y a las claves de API, extendida a un principal que habla castellano y razona sobre tu bandeja de entrada. Las organizaciones que salgan bien paradas de esto habrán hecho el trabajo aburrido de mapear el acceso antes de que la capacidad se adelantara al control. La categoría ya está dentro del edificio. La única pregunta abierta es si encontrarás tus agentes antes de que lo haga otro.

Preguntas frecuentes

¿Puede nuestra empresa bloquear los agentes de IA personales para que no se conecten a cuentas corporativas?

En parte, y merece la pena intentarlo, pero un bloqueo puro subestima el problema. Las conexiones suelen viajar sobre sesiones autenticadas normales y permisos OAuth que parecen legítimos, así que el control duradero es acotar lo que cualquier principal externo puede alcanzar y exigir aprobación para las acciones de alto impacto, no solo intentar dejar fuera a los agentes.

¿La inyección de prompts es una amenaza real o solo teórica?

Es un riesgo asumido en el diseño actual de agentes. La investigación publicada por Anthropic trata como expuesto a todo agente que procesa contenido no fiable, con los agentes de navegación como los más vulnerables. No se deduce que todo intento triunfe, pero el canal de ataque está activo allí donde un agente lee entrada externa y a la vez tiene permisos reales, que es justo el caso de la mayoría de los agentes personales conectados a sistemas de trabajo.

¿Cómo detectamos los agentes de IA en la sombra que ya están en uso?

Empieza por el acceso, no por los dispositivos. En Microsoft Entra ID, revisa los consentimientos de aplicaciones empresariales; en Google Workspace, extrae el informe de acceso de apps de terceros y el registro de auditoría de tokens OAuth. Construye un inventario de tokens y conexiones de apps en manos de cuentas que no gestionas, vigila patrones de acceso automatizado en identidades vinculadas a cuentas personales y pregunta directamente a la plantilla. La detección es, en el fondo, un ejercicio de gestión de identidad y accesos, por eso tratar a los agentes como una clase de principal gobernada importa más que los controles de endpoint.

Relacionado

Escrito por una persona editorial de IA del sistema editorial propietario de Abyshire y revisado por nuestro equipo.