Los agentes de IA están obligando a que el zero trust salga de la red
La guía más reciente sobre la gestión del riesgo cibernético de la IA agente se centra en un punto que los equipos de seguridad empresarial ya deberían estar abordando: un agente de IA no es solo otro usuario de aplicación.
Lee contenido no confiable, formula un plan y usa credenciales para actuar en varios sistemas. Esa combinación rompe una suposición cómoda detrás de muchos programas de zero trust: que una identidad autenticada, dentro de un flujo de trabajo aprobado, es suficientemente predecible.
No lo es.
Un empleado humano puede tener un rol amplio. Un servicio convencional tiene una función estrecha. Un agente ocupa un terreno intermedio incómodo y riesgoso. Puede heredar el acceso de una persona, consumir un correo o documento malicioso, llamar a una herramienta conectada y seguir intentando variaciones de una acción. Su identidad puede ser válida mientras su siguiente paso está completamente fuera de la intención de quien lo lanzó.
Por eso la conversación sobre IA empresarial está cambiando. La pregunta ya no es solo si el modelo está aprobado. Es si cada acción que el modelo puede desencadenar está explícitamente autorizada, limitada y observable.
Zero trust debe aplicarse a cada llamada de herramienta
Un buen programa de zero trust pide verificación antes de conceder acceso. La IA agente necesita el mismo principio a un nivel más fino: antes de cada llamada de herramienta con consecuencias.
Considere un agente que ayuda a un equipo de compras a revisar contratos de proveedores. Leer un documento y producir un resumen es bajo riesgo. Crear un borrador en el sistema de contratos es más relevante. Cambiar un registro de pago, exportar una carpeta de contratos o enviar un mensaje externo es diferente aún.
Esas acciones no deberían estar protegidas por el mismo permiso OAuth permanente solo porque aparezcan en un flujo de trabajo.
Trate cada acción como una decisión con cinco entradas:
- **Identidad del agente:** ¿Qué agente y versión específicos hacen la solicitud?
- **Contexto humano y empresarial:** ¿Quién la inició y qué tarea aprobada está completando?
- **Contexto de datos:** ¿Qué datos se leerán, escribirán o enviarán y qué sensibilidad tienen?
- **Herramienta y entorno:** ¿Qué conector está involucrado y es un sistema de pruebas o producción?
- **Impacto de la acción:** ¿La solicitud es reversible, limitada e interna, o cambia dinero, permisos, registros o comunicaciones externas?
Un motor de políticas no necesita hacer lento cada flujo de trabajo de bajo riesgo. Sí debe distinguir una búsqueda de un cambio de pago. Si no puede, la organización ha otorgado autoridad ambiental: credenciales técnicamente válidas pero demasiado amplias para la tarea.
El prompt no es el límite de la política
Los equipos aún intentan resolver el riesgo de agentes con mejores instrucciones. Escriben una regla que dice "Nunca enviar datos de clientes externamente" y luego conectan el agente a correo, almacenamiento y CRM con un token de larga duración.
Eso es dirección, no aplicación.
La inyección indirecta de prompt hace evidente la brecha. Un agente puede encontrar instrucciones hostiles en una página web, ticket, hoja de cálculo o documento. Incluso un modelo bien diseñado puede ser manipulado para elegir una llamada de herramienta insegura. El control importante no es si se le dijo al agente cómo comportarse, sino si el conector rechaza una acción que viola la política.
Para trabajos de alto impacto, traslade el límite fuera del chat y hacia controles de identidad y acceso. Use identidades dedicadas para agentes. Emita credenciales de corta duración vinculadas a una tarea. Restrinja los ámbitos de herramientas al conjunto útil más pequeño. Requiera un punto de aprobación para acciones irreversibles, visibles externamente o de alto valor.
Esto es ingeniería de seguridad conocida. La diferencia es la velocidad con que los creadores de agentes pueden ahora crear un flujo que cruza todos estos límites sin abrir una solicitud de cambio tradicional.
La IA sombra se está convirtiendo en autoridad sombra
La mayoría de las organizaciones han comenzado su gobernanza de IA inventariando modelos y herramientas de chat aprobadas. Eso sigue siendo importante. Pero el problema más difícil es descubrir dónde la IA ha adquirido autoridad.
Un asistente basado en navegador que puede abrir un documento en la nube, un flujo sin código con conector de correo, un agente de codificación con token de desarrollador y una herramienta de ventas que puede actualizar un CRM tienen riesgos diferentes. Ninguno necesita parecer una "plataforma de IA" formal para estar cerca de producción.
Esta es la siguiente forma de IA sombra: no solo uso no aprobado de modelos, sino acceso no observado de IA a sistemas.
Un inventario útil debe registrar más que el proveedor y propietario. Para cada agente o flujo habilitado con IA, los líderes de seguridad deben poder responder:
- ¿A qué datos puede acceder, incluidos conectores posteriores?
- ¿Qué acciones puede realizar y en qué entornos?
- ¿Qué identidad, token o contexto de usuario delegado hace posibles esas acciones?
- ¿Qué evento lo activa y qué contenido no confiable puede influir?
- ¿Qué lo detiene cuando la tarea, acceso o aprobación expira?
Si la respuesta solo está en una consola de administración del proveedor o en la memoria del propietario, la gobernanza no ha alcanzado la adopción.
Construya un registro de acciones, no otra hoja de cálculo
La respuesta práctica es un registro de acciones: un registro vivo que une descubrimiento, identidad, acceso a datos, permisos de herramientas y decisiones de política. Debe mostrar el camino desde un usuario iniciador y propósito empresarial hasta la acción exacta que intentó un agente y si el control la permitió, bloqueó o escaló.
Eso da a los equipos de seguridad algo que pueden operar. Apoya la respuesta a incidentes cuando un agente se comporta inesperadamente. Permite a cumplimiento demostrar supervisión. Y da a los equipos de negocio una vía para desplegar agentes útiles sin esperar un sí o no general.
Comience con cuatro niveles de acción:
1. Leer y redactar: Permitir dentro de límites de datos aprobados; registrarlo. 2. Recomendar: Permitir que el agente prepare un cambio, pero que la ejecución quede en manos de una persona. 3. Ejecución limitada: Permitir acciones reversibles con límites de transacción, destino y tiempo. 4. Ejecución de alto impacto: Requerir un aprobador explícito y autoridad just-in-time para movimientos de dinero, cambios de privilegios, cambios en producción, exportaciones masivas, eliminaciones o envíos externos.
La palabra importante es ejecución. Una revisión de riesgo del modelo puede decir si una herramienta es adecuada. No puede, por sí sola, controlar lo que un agente conectado hace a las 2 a. m. con un token válido.
Haga visible la autoridad antes de que se convierta en un incidente
La IA agente puede hacer a los equipos mucho más rápidos. La respuesta sensata no es prohibirla ni forzar cada solicitud a una revisión manual. Es hacer que la autoridad sea deliberada.
Aona ayuda a los equipos de seguridad y gobernanza a descubrir el uso de IA en el entorno, identificar dónde agentes y herramientas pueden tocar datos sensibles y aplicar controles aplicables en datos, identidad y acciones. [Vea cómo Aona aborda la gobernanza de IA](https://aona.ai/?utm_source=blog&utm_medium=internal&utm_campaign=agent-zero-trust) y [explore nuestros recursos de IA sombra](https://aona.ai/resources?utm_source=blog&utm_medium=internal&utm_campaign=agent-zero-trust).
La guía de esta semana es un buen recordatorio para una pregunta directa: ¿puede su equipo rastrear la próxima acción relevante de un agente hasta un propietario nombrado, una aprobación vigente y un permiso con límite temporal? Si no, aún no tiene zero trust para agentes de IA. Tiene confianza no probada.
