Las amenazas internas de los agentes de IA sitúan el acceso de confianza en el centro de la seguridad
Los agentes de IA han cruzado un umbral crítico: ahora pueden usar credenciales de confianza para leer datos, invocar herramientas y modificar sistemas empresariales sin supervisión constante.
Este cambio transforma la amenaza interna de los agentes de IA de una cuestión de seguridad del modelo en un problema de control de acceso. Un agente no necesita tener una intención maliciosa para exponer registros, enviar mensajes no autorizados o ejecutar un flujo de trabajo inseguro. Solo necesita permisos legítimos, una instrucción perjudicial y suficiente autonomía para actuar.
El argumento más reciente de Cybersecurity Insiders refleja esta inversión. Antes, las empresas trataban la IA como software que debía protegerse de atacantes externos. Ahora, los equipos de seguridad deben considerar si el propio software puede convertirse en un operador de confianza pero inseguro.
Esto no significa que todos los agentes deban clasificarse como hostiles. Significa que las organizaciones ya no pueden tratar la autenticación como prueba de que una acción es segura. Una identidad válida responde quién o qué solicitó acceso. No determina si la acción solicitada coincide con la verdadera intención del usuario.
Por tanto, la competencia emergente no es entre humanos y máquinas. Es entre un acceso amplio y persistente, y una autorización limitada y específica para cada tarea. Los equipos de seguridad deben decidir si los agentes heredarán los patrones de acceso permisivo creados para empleados y aplicaciones convencionales.
La respuesta determinará si la adopción de agentes genera automatización controlada o una nueva clase de incidentes internos difíciles de detectar.
La amenaza interna de los agentes de IA comienza con el acceso legítimo
El riesgo definitorio no es que un agente de IA atraviese el perímetro, sino que actúe mediante el acceso que la empresa le concedió deliberadamente.
Los programas tradicionales de riesgo interno se centran en empleados, contratistas y cuentas comprometidas. Estos sujetos ya se encuentran dentro de un límite de confianza. Pueden hacer un uso indebido de datos o sistemas sin explotar una vulnerabilidad expuesta al exterior.
Los agentes encajan sorprendentemente bien en ese modelo. Pueden disponer de autorizaciones OAuth, identidades de servicio, acceso a API, permisos de bases de datos y autoridad delegada. También pueden combinar esos privilegios a lo largo de un flujo de trabajo de varios pasos.
Un agente encargado de preparar una presentación comercial podría buscar registros de clientes, recuperar notas internas y redactar un correo electrónico. Un agente de programación podría leer un repositorio, abrir una terminal, modificar archivos y enviar una solicitud de extracción. Un agente de soporte podría consultar información de cuentas e iniciar un reembolso.
Cada permiso individual puede parecer razonable. La capacidad peligrosa surge cuando el agente los conecta en una secuencia inesperada.
Esta es una diferencia fundamental entre un agente y una aplicación convencional. El software tradicional suele seguir rutas predeterminadas. Un agente interpreta un objetivo, selecciona herramientas y decide los pasos intermedios durante la ejecución.
Esa flexibilidad aporta valor, pero también debilita los supuestos incorporados en controles más antiguos. Un permiso concedido para un flujo de trabajo previsto puede respaldar varios flujos de trabajo no previstos. El agente puede descubrir esas rutas más rápido que un operador humano.
La inyección de prompts agrava el problema. La inyección de prompts es un ataque que inserta instrucciones engañosas dentro de datos que lee un sistema de IA. El agente puede confundir esas instrucciones con parte de la tarea asignada.
Imagine un asistente que revisa documentos de una carpeta externa. Un documento contiene texto oculto que le indica al asistente recuperar archivos confidenciales y enviar su contenido a otro lugar. El agente podría obedecer porque ambas acciones utilizan herramientas aprobadas.
El sistema puede registrar un inicio de sesión correcto, un token válido y llamadas a API permitidas. La monitorización convencional observa actividad autorizada. La empresa observa una filtración de datos.
La guía sobre amenazas agénticas de OWASP identifica riesgos derivados de la planificación autónoma, el uso de herramientas, la memoria y las interacciones entre agentes. No son comportamientos aislados del modelo. Son riesgos a nivel de sistema creados al combinar un modelo con autoridad.
El mismo problema aparece cuando un agente recibe un objetivo mal especificado. «Resolver todas las solicitudes vencidas» podría llevarlo a enviar mensajes, modificar registros o cerrar casos que requerían revisión humana. No es necesario comprometer primero el modelo.
Por eso la intención importa tanto como la identidad. Un diseño seguro debe determinar quién autorizó la tarea, qué recursos abarca, qué acciones están permitidas y cuánto tiempo sigue siendo válida esa autoridad.
Sin esos límites, un agente autenticado se convierte en un usuario interno con un ritmo operativo inusualmente rápido.
El acceso de confianza se está convirtiendo en el nuevo perímetro de seguridad
Los agentes de IA hacen que el acceso de confianza sea más importante que la ubicación de la red porque su trabajo legítimo ya abarca aplicaciones, nubes y almacenes de datos.
La arquitectura de confianza cero anticipó parte de este cambio. El estándar de confianza cero del NIST rechaza la confianza implícita basada únicamente en la ubicación de red o la propiedad de los activos. Centra las decisiones de seguridad en usuarios, activos, recursos y autorización explícita.
Este modelo se vuelve más urgente cuando el sujeto que solicita acceso es un sistema autónomo. Un agente puede operar a través de límites que antes ralentizaban a los usuarios internos humanos. No necesita cambiar de dispositivo, abrir varias interfaces ni copiar manualmente datos entre aplicaciones.
Una sola instrucción puede desencadenar una cadena de llamadas a herramientas. Esa cadena podría pasar de una plataforma de mensajería al almacenamiento en la nube, luego a una base de datos de clientes y a un servicio externo. El agente ejecuta la secuencia mediante integraciones de confianza.
Un firewall de red observa conexiones permitidas. Los sistemas de identidad observan credenciales reconocidas. Los registros de aplicaciones muestran operaciones que la cuenta asignada tenía permitido realizar.
Sin embargo, el resultado combinado todavía puede infringir las políticas.
Por tanto, la seguridad debe acercarse a cada acción. La autorización debe considerar la identidad del agente, su propietario, la tarea actual, el recurso solicitado, la herramienta utilizada y las señales de riesgo del entorno.
Esto requiere una identidad distinta para cada agente desplegado. Las cuentas de servicio compartidas dificultan la investigación porque varios agentes pueden generar actividad bajo un mismo nombre. También permiten que los permisos se acumulen a medida que nuevos flujos de trabajo reutilizan la misma cuenta.
Una identidad dedicada crea un rastro de propiedad. Los equipos de seguridad pueden conectar un agente con su patrocinador, propósito, herramientas permitidas, entorno de despliegue y calendario de revisión. Pueden suspender un flujo de trabajo sin desactivar automatizaciones no relacionadas.
Sin embargo, la identidad por sí sola no es suficiente. Un agente identificado de forma única puede seguir teniendo privilegios excesivos. También puede utilizar un permiso válido en el momento equivocado o para el objetivo equivocado.
Los controles eficaces deben reducir tanto el alcance como la duración de los permisos. Un agente que prepara un informe trimestral no debería conservar acceso permanente a todas las fuentes que utilizó. Debería recibir una autoridad limitada para la tarea actual.
Las credenciales de corta duración reducen el tiempo disponible para un uso indebido. El acceso justo a tiempo concede autoridad cuando comienza la tarea y la revoca después. Las políticas a nivel de herramienta limitan qué operaciones puede invocar el agente.
Estos controles reflejan la lección central de la amenaza interna de los agentes de IA. La confianza debe vincularse a una acción específica bajo condiciones específicas, no a un agente para siempre.
Las empresas también deben separar la lectura de la acción. Un agente que resume un calendario requiere una autoridad diferente de uno que programa reuniones. Un sistema que propone cambios de código no debería recibir automáticamente permiso para desplegarlos.
Esta distinción puede desaparecer durante una adopción rápida. Los equipos empiezan con un asistente de solo lectura y después añaden gradualmente acceso de escritura, control del navegador y automatización de flujos de trabajo. La evaluación de riesgos original ya no coincide con el sistema desplegado.
Por tanto, los inventarios de agentes deben rastrear capacidades, no solo instalaciones. Los equipos de seguridad necesitan saber qué agentes pueden acceder a datos sensibles, invocar herramientas externas, comunicarse públicamente, modificar registros o autorizar transacciones.
El inventario debe cambiar tan rápido como los propios agentes.
Por qué los controles internos existentes no detectan el comportamiento de los agentes
Los controles diseñados en torno a la velocidad y las motivaciones humanas tienen dificultades cuando el software puede realizar cientos de acciones legítimas sin fatiga ni vacilación.
Los programas de riesgo interno para humanos suelen buscar cambios de comportamiento reconocibles. Un empleado descarga volúmenes inusuales de datos, inicia sesión a una hora inesperada o accede a un departamento ajeno a su función habitual.
Estas señales siguen siendo útiles, pero los agentes crean una línea de base diferente. Pueden operar de forma continua. Pueden procesar más registros que una persona. Su actividad puede originarse en infraestructura de nube estable en lugar de en un endpoint de empleado.
Una elevada tasa de acciones puede indicar automatización normal en vez de comportamiento malicioso. Una baja tasa de acciones aún puede ocultar una divulgación cuidadosamente dirigida. El volumen por sí solo se convierte en una señal poco fiable.
La intención también es más difícil de inferir. Un usuario humano suele realizar acciones mediante una sesión interactiva. Los investigadores pueden comparar esas acciones con las responsabilidades laborales, las comunicaciones y los procesos empresariales conocidos.
Un agente traduce una instrucción amplia en decisiones intermedias. Es posible que el usuario nunca vea esas decisiones. La acción final puede estar a varios pasos de distancia de la solicitud original.
Los registros deben preservar esa cadena. Los investigadores deberían poder reconstruir la instrucción del usuario, las decisiones del modelo, el contexto recuperado, las selecciones de herramientas, los resultados de autorización y los efectos finales.
Esto no significa almacenar todos los cálculos internos del modelo. Significa mantener un registro auditable de las acciones externas relevantes y de la autoridad que respaldó cada una.
Los registros estándar de aplicaciones suelen proporcionar solo fragmentos. Un sistema registra el token. Otro registra la consulta a la base de datos. Un tercero registra un mensaje saliente. Sin un identificador de tarea compartido, la organización no puede conectarlos en un único flujo de trabajo del agente.
El problema de observabilidad crece en los sistemas multiagente. Un agente puede delegar investigación a otro, que pide a un tercer sistema ejecutar una herramienta. La autoridad puede desplazarse por la cadena incluso cuando el usuario original nunca aprobó a cada participante.
La confianza recursiva describe esta relación en expansión. Una organización confía en un agente, que confía en otro servicio, que depende de otra identidad o herramienta. La superficie de ataque efectiva se extiende a través de cada eslabón.
La amenaza interna de los agentes de IA puede explotar esa cadena sin generar un evento de intrusión evidente. Una respuesta de herramienta comprometida puede influir en el agente de planificación. Una entrada de memoria envenenada puede afectar decisiones futuras. Un documento externo puede redirigir un flujo de trabajo de confianza.
Las defensas existentes de endpoints y redes siguen siendo importantes. Pueden bloquear malware, detectar destinos sospechosos y aislar infraestructura comprometida. No pueden determinar de forma fiable si una acción empresarial autorizada refleja el resultado previsto por el usuario.
Ese juicio requiere un contexto más rico.
Las organizaciones deberían establecer líneas de base de comportamiento para cada función de agente. Un agente de generación de informes podría normalmente leer fuentes de datos aprobadas y escribir en un almacén documental específico. Un intento de enviar correo electrónico o acceder a credenciales quedaría fuera de ese perfil.
Las políticas también pueden imponer restricciones de secuencia. Leer una página web no confiable no debería autorizar de inmediato el acceso a registros confidenciales. Un cambio en la sensibilidad de los datos debería desencadenar una nueva decisión de autorización.
La aprobación humana sigue siendo útil para las acciones de alto impacto. Sin embargo, las pantallas de aprobación deben presentar información significativa. Una solicitud vaga para “continuar” no ayuda a quien revisa a entender qué datos se moverán ni qué registros cambiarán.
La aprobación debe indicar la acción, el destino, los recursos afectados y la consecuencia prevista. De lo contrario, la persona se convierte en un punto de control ceremonial, en lugar de un control de seguridad.
El principio de mínimo privilegio debe seguir la tarea, no al agente
El modelo de acceso más seguro concede a un agente la autoridad mínima necesaria para una tarea y exige una nueva decisión cuando la tarea cambia.
El mínimo privilegio ha sido durante mucho tiempo un principio de seguridad. Los sistemas basados en agentes hacen que su implementación sea más exigente porque sus flujos de trabajo son dinámicos.
Una aplicación convencional recibe permisos que corresponden a un conjunto estable de funciones. Un agente puede elegir distintas herramientas según la solicitud, la información recuperada o los resultados de un paso anterior.
Concederle de antemano todos los permisos posibles simplifica el desarrollo. También genera una acumulación de autoridad inactiva. Un agente manipulado puede usar capacidades que la tarea actual nunca requirió.
La autorización vinculada a la tarea ofrece una mejor vía. El sistema evalúa el objetivo declarado y emite una capacidad restringida para el recurso necesario. Esa capacidad expira cuando termina el paso o la sesión.
El patrón de mínimo privilegio de Microsoft recomienda definir la identidad, el alcance, el acceso a herramientas y la auditabilidad antes de ampliar la autonomía. También subraya la importancia de identidades de agente dedicadas con propietarios responsables.
Pensemos en un agente que procesa informes de gastos. Necesita leer los documentos presentados, compararlos con la política y preparar una recomendación. No necesita autoridad permanente para emitir pagos.
Si posteriormente la empresa permite el reembolso automático por debajo de un umbral definido, ese permiso de escritura debe ser independiente. El sistema debe registrar la política que lo autorizó y exigir una escalación fuera de ese límite.
Esta descomposición limita el daño cuando algo sale mal. Una instrucción maliciosa dentro de un recibo podría influir en la recomendación. No debería conceder automáticamente la capacidad de redirigir fondos.
El mismo modelo se aplica al trabajo basado en conocimiento. Un agente de investigación puede buscar en los documentos aprobados de un equipo, pero el destino de su resultado debe seguir estando restringido. El material fuente sensible no debe fluir hacia prompts públicos, canales externos ni proyectos no relacionados.
Las decisiones de acceso necesitan contexto sobre los datos. Una etiqueta de archivo, la pertenencia a un proyecto, una retención legal, una restricción de cliente o un nivel de confidencialidad pueden modificar si la misma llamada a una herramienta es adecuada.
Las organizaciones que crean una base de conocimiento de IA deben tratar los límites de permisos como parte de la calidad de recuperación. Una respuesta útil debe basarse en información relevante sin cruzar los límites de propiedad o confidencialidad.
El diseño de las herramientas también importa. Las herramientas amplias generan modos de fallo amplios. Un conector genérico de base de datos que puede ejecutar consultas arbitrarias implica más riesgo que una función diseñada específicamente para devolver campos aprobados.
Los desarrolladores deben exponer la operación útil más limitada. En lugar de otorgar a un agente acceso completo al buzón, un servicio podría permitirle recuperar mensajes que coincidan con un identificador de caso. En lugar de acceso al shell, podría exponer un comando de compilación controlado.
La vinculación de herramientas conecta identidades específicas de agentes con operaciones específicas. El agente no puede invocar todas las integraciones disponibles simplemente porque la plataforma sabe que esas herramientas existen.
Las entradas y salidas también requieren validación fuera del modelo. Un modelo no debe ser el único responsable de decidir si su propia acción propuesta infringe una política.
Una capa de políticas independiente puede inspeccionar destinos, clasificaciones de datos, límites de transacción y contexto de la tarea. Puede bloquear, transformar o escalar una operación antes de su ejecución.
Esta separación aborda una idea errónea común sobre la seguridad de los agentes. Mejores prompts y modelos más robustos pueden reducir errores, pero no pueden sustituir límites exigibles.
Un prompt es una instrucción. Una política de autorización es un control.
La distinción importa porque un agente puede malinterpretar un prompt, heredar contexto contaminado o recibir instrucciones conflictivas. Un motor de políticas debe seguir imponiendo límites incluso cuando el modelo se comporta de forma impredecible.
Zero Trust ayuda, pero no resuelve la intención
Zero Trust puede limitar el alcance de un agente, pero no puede determinar automáticamente si una acción permitida sirve al objetivo real del usuario.
Este es el equilibrio central en el debate sobre el acceso de confianza. Los proveedores de seguridad posicionan cada vez más la identidad, el acceso condicional y Zero Trust como respuestas al riesgo de los agentes. Estos controles abordan debilidades importantes.
El Zero Trust para IA de Microsoft amplía la verificación explícita y el mínimo privilegio a los datos, modelos, cargas de trabajo, usuarios y comportamiento de los agentes de IA. Microsoft también describe a los agentes manipulados, con privilegios excesivos o desalineados como posibles “agentes dobles”.
Este enfoque es útil, pero las organizaciones deben evitar tratar Zero Trust como una categoría completa de producto. NIST describe Zero Trust como un conjunto de principios arquitectónicos, no como la compra de una única tecnología.
Una organización puede implementar controles modernos de identidad y dejar a los agentes con permisos excesivos. Puede exigir autenticación sin distinguir una tarea de agente de otra. Puede recopilar registros que nadie revisa.
Los casos más difíciles implican acciones que son a la vez autorizadas y plausibles.
Un agente de atención al cliente puede acceder legítimamente a datos de clientes y enviar mensajes. Un agente de programación puede modificar legítimamente archivos de código fuente. Un agente de compras puede contactar legítimamente a proveedores.
La versión maliciosa o equivocada de cada acción puede parecer casi idéntica en la capa de identidad.
La autorización contextual reduce esa brecha. El sistema puede preguntar si el destino está aprobado, si los campos solicitados son necesarios, si la acción coincide con el comportamiento histórico y si la clasificación de los datos permite la transferencia.
Aun así, los modelos de contexto generan falsos positivos y falsos negativos. Los controles estrictos pueden interrumpir flujos de trabajo útiles. Los controles flexibles pueden preservar la productividad y, al mismo tiempo, permitir combinaciones dañinas.
La organización debe decidir dónde termina la autonomía. Las tareas reversibles y de bajo impacto pueden tolerar mayor libertad. Las tareas irreversibles y de alto impacto requieren una verificación más sólida y, a menudo, aprobación humana.
La reversibilidad merece atención especial. Un agente que redacta un mensaje crea un artefacto revisable. Un agente que envía el mensaje cambia el mundo exterior. Un agente que recomienda eliminar registros es distinto de uno que efectivamente los elimina.
La arquitectura de seguridad debe reflejar esas diferencias.
Los equipos también deben probar los agentes como sistemas, no solo como modelos. Las evaluaciones de modelos pueden medir si un agente sigue instrucciones en condiciones controladas. El riesgo en producción depende de las herramientas, credenciales, memoria, fuentes de datos y aplicaciones circundantes.
Los ejercicios de red team deben introducir documentos maliciosos, objetivos ambiguos, respuestas de herramientas comprometidas y combinaciones inesperadas de permisos. El objetivo es observar si los controles externos contienen el fallo.
El marco de OWASP ayuda a los equipos a enumerar estas amenazas, mientras que el modelo de acceso en la nube de NIST explica cómo las políticas del nivel de identidad y los controles granulares de aplicaciones respaldan Zero Trust en servicios distribuidos.
Ninguno garantiza que un agente comprenda la intención empresarial. Esa incertidumbre debe seguir siendo visible en las decisiones de despliegue.
Por ello, los responsables de seguridad deben cuestionar las afirmaciones de que una plataforma “protege a los agentes” sin explicar su alcance. ¿Descubre identidades de agentes? ¿Gobierna los permisos? ¿Inspecciona las llamadas a herramientas? ¿Protege los prompts y los datos? ¿Mantiene trazas de auditoría entre sistemas?
La mayoría de los productos abordan solo una parte del ciclo de vida. Las empresas seguirán necesitando responsables de políticas, procesos operativos, respuesta a incidentes y controles específicos de cada aplicación.
La amenaza interna de los agentes de IA no es una vulnerabilidad con un único parche. Es la consecuencia de situar responsables de decisiones probabilísticos dentro de flujos de trabajo de confianza.
Tres señales mostrarán si el acceso de confianza está mejorando
La próxima etapa de la seguridad de la IA se medirá por controles desplegables y evidencia de incidentes, no por promesas más amplias sobre agentes responsables.
La primera señal es la adopción de identidades de agente diferenciadas y gobernadas. Las organizaciones deberían poder enumerar los agentes, identificar a sus responsables, revisar sus permisos y deshabilitarlos individualmente.
El marco de identidad de agentes de Microsoft Entra muestra hacia dónde se dirigen las principales plataformas de identidad. Admite estructuras dedicadas para agentes, registro de actividad, gobernanza y acceso condicional para actores no humanos.
Otros proveedores de identidad y nube afrontarán presión para ofrecer controles comparables en entornos heterogéneos. Las empresas rara vez operan con una sola plataforma de agentes o un único sistema de identidad.
El progreso será creíble cuando los administradores puedan rastrear una acción de un agente entre aplicaciones sin depender de una cuenta de servicio compartida. Si las identidades dedicadas siguen siendo opcionales o específicas de una plataforma, la visibilidad continuará fragmentada.
La segunda señal es un uso más amplio de autorización de corta duración y con alcance por tarea. Las plataformas de agentes deberían solicitar acceso para una operación definida en lugar de heredar permisos permanentes de un usuario o desarrollador.
Este cambio exigirá una mejor integración entre los sistemas de orquestación y la infraestructura de identidad. La plataforma debe describir lo que el agente pretende hacer de una forma que un motor de políticas pueda evaluar.
Las interfaces de aprobación también deben mejorar. Antes de otorgar autoridad sensible, los usuarios deben ver el recurso, la acción, el destino y el efecto esperado.
Si los proveedores lanzan estos controles como opciones predeterminadas, la tesis del acceso de confianza se fortalece. Si una configuración segura exige una amplia ingeniería personalizada, los equipos sometidos a presión de entrega seguirán eligiendo permisos amplios.
La tercera señal es la evidencia pública procedente de incidentes reales y pruebas independientes. Los equipos de seguridad necesitan saber cómo fallan los agentes fuera de las demostraciones.
Las divulgaciones útiles explicarán la instrucción inicial, la vía de acceso, las herramientas implicadas, el control que falló y el punto en el que la contención tuvo éxito. Las referencias vagas a resultados inseguros no ofrecerán suficiente orientación arquitectónica.
Las evaluaciones independientes deben probar sistemas de agentes completos frente a inyección de prompts, autonomía excesiva, memoria contaminada, exposición de credenciales y manipulación entre agentes. También deben medir si los controles preservan el trabajo útil.
Los informes de incidentes aclararán qué riesgos predominan. La inyección de prompts recibe mucha atención, pero los errores de configuración, los permisos excesivos, las identidades compartidas y las integraciones no revisadas podrían resultar igual de importantes.
El resultado dará forma a las prioridades de inversión y diseño. Si la mayoría de los incidentes implica credenciales robadas, la protección de identidad tendrá prioridad. Si agentes válidos hacen un uso indebido repetidamente de herramientas permitidas, la autorización en tiempo de ejecución y los controles de comportamiento se convertirán en el principal campo de batalla.
Las empresas no necesitan esperar a estándares perfectos. Ya pueden inventariar agentes, separar identidades, eliminar permisos no utilizados, restringir herramientas, registrar cadenas de acciones y exigir aprobación para operaciones irreversibles.
También deben definir qué ocurre cuando un agente se comporta de manera inesperada. La suspensión rápida, la revocación de credenciales, el aislamiento del flujo de trabajo y la preservación de evidencia deben formar parte del plan de respuesta a incidentes.
La pregunta práctica es sencilla: ¿puede su organización explicar cada acción relevante de un agente y revocar su autoridad sin desactivar todo un proceso empresarial?
Si la respuesta es no, el agente cuenta con más confianza de la que la arquitectura de seguridad puede gestionar de forma segura.
La amenaza interna de los agentes de IA cambia el orden de las operaciones. Las empresas no pueden conceder acceso amplio primero y añadir supervisión después del despliegue. La identidad, los límites de las tareas, la auditabilidad y la contención deben llegar antes que la autonomía.
Para los desarrolladores y compradores empresariales, la próxima evaluación debería ir más allá de si un agente completa una demostración. Pregunte a qué puede acceder, cómo expira esa autoridad y si un control independiente puede detener la acción final.
El acceso de confianza es ahora el campo de batalla, porque el acceso convierte la salida del modelo en consecuencias reales. Las organizaciones que gobiernen esa transición captarán el valor de la automatización sin tratar cada acción autenticada como intrínsecamente fiable.
