Durante mucho tiempo, la seguridad empresarial se construyó alrededor de una idea bastante sencilla: si alguien estaba dentro de la red corporativa, podía considerarse relativamente confiable. El firewall protegía el perímetro, la VPN permitía entrar a la red y, una vez autenticado, el usuario podía acceder a los recursos para los que tenía permisos. Era un modelo que tenía sentido cuando las aplicaciones estaban en los servidores de la empresa y buena parte de los usuarios trabajaba desde las mismas oficinas.
El problema es que esa arquitectura dejó de representar la realidad hace bastante tiempo. Hoy una empresa puede tener aplicaciones en la nube, servidores locales, servicios SaaS, APIs, dispositivos personales, proveedores externos y, cada vez más, agentes de inteligencia artificial capaces de consultar información y ejecutar acciones. El hecho de que una solicitud provenga de la red corporativa ya dice muy poco sobre si debería ser autorizada.
Ahí es donde Zero Trust deja de ser simplemente una tendencia de ciberseguridad y empieza a convertirse en una cuestión de arquitectura. La idea no es desconfiar de todo de manera indiscriminada, sino eliminar la confianza implícita y tomar las decisiones de acceso con base en identidad, contexto, permisos y riesgo. CISA, por ejemplo, estructura su modelo de madurez alrededor de cinco pilares: identidad, dispositivos, redes, aplicaciones y cargas de trabajo, y datos.
El problema no es solamente dónde está el usuario
En una infraestructura tradicional todavía es común escuchar argumentos como “eso está dentro de la red” o “ese servidor está detrás del firewall”. El problema es que estar dentro de una red nunca debería convertirse, por sí solo, en una autorización.
Google lleva años trabajando precisamente sobre esta idea con BeyondCorp. Su modelo trasladó los controles de acceso desde el perímetro de red hacia usuarios y dispositivos concretos, de manera que la ubicación desde la que alguien se conecta deja de ser el principal criterio para decidir si puede acceder a un recurso.
Pero la evolución más interesante aparece cuando este principio deja de aplicarse solamente a personas.
En una arquitectura moderna, también existen servicios, aplicaciones, microservicios y agentes de IA que realizan solicitudes en nombre de usuarios o de otros sistemas. Cada uno de ellos puede convertirse en un punto desde el cual alguien —o algo— intenta acceder a información empresarial. Por eso Google extendió estos principios a sus sistemas de producción mediante BeyondProd, donde la confianza entre servicios se basa en elementos como la identidad del servicio, el origen del código y el entorno en el que se ejecuta, y no simplemente en la ubicación del servidor dentro de la red. Y esto cambia bastante la conversación cuando introducimos inteligencia artificial.
¿Qué ocurre cuando el usuario ya no es una persona?
Imaginemos una empresa que implementa un agente de IA conectado al CRM. El equipo comercial podría preguntarle qué clientes tienen oportunidades abiertas, cuáles llevan más de 30 días sin seguimiento o qué negocios están próximos a cerrarse. Para responder, el agente necesita consultar diferentes objetos del CRM mediante una API.
La integración puede parecer sencilla. Se crea una cuenta de servicio, se le entregan permisos y se conecta el agente. El problema aparece cuando, para evitar complicaciones, esa cuenta termina teniendo acceso prácticamente completo al sistema.
En ese escenario, una vulnerabilidad en la aplicación, una credencial comprometida o incluso una instrucción mal procesada podría permitir que el agente haga mucho más de aquello para lo que fue diseñado. Podría consultar información que no necesita, modificar registros, acceder a otros sistemas o ejecutar acciones que originalmente no formaban parte de su función.
Desde la perspectiva de Zero Trust, la pregunta no debería ser si confiamos en ese agente. La pregunta correcta es mucho más concreta: ¿qué puede hacer técnicamente ese agente aunque deje de comportarse como esperamos?
Un caso técnico: cómo Microsoft está aplicando Zero Trust a los agentes de IA
Este problema ya está siendo abordado directamente por los grandes fabricantes de infraestructura. Microsoft, por ejemplo, plantea en su documentación de Microsoft Entra Agent ID que los agentes de IA deben contar con una identidad propia y gestionada durante todo su ciclo de vida, en lugar de depender simplemente de la identidad de un usuario o de una cuenta de servicio genérica.
Un agente diseñado únicamente para consultar oportunidades del CRM podría tener una identidad exclusiva y permisos de solo lectura sobre determinados recursos. No tendría por qué poder eliminar registros, administrar usuarios ni modificar configuraciones. Además, Microsoft recomienda definir explícitamente el propósito del agente, los datos a los que puede acceder, las herramientas que puede utilizar y sus dependencias, evitando que se le concedan permisos amplios simplemente por comodidad.
La arquitectura podría incluso separar las acciones de lectura de las acciones de escritura. El agente tendría permiso permanente para consultar información comercial, pero si necesita modificar una oportunidad o ejecutar una operación sensible, podría requerir una autorización adicional. Para privilegios elevados, Microsoft plantea mecanismos de acceso just-in-time, de modo que ese permiso exista solamente durante el tiempo necesario para ejecutar una tarea concreta.
Esto también cambia la forma de investigar un incidente. Si cada agente tiene una identidad propia, es posible registrar qué agente realizó una acción, qué rol tenía, cuál era su alcance, qué recurso intentó utilizar y qué operación ejecutó. Microsoft recomienda precisamente mantener este nivel de trazabilidad, incluyendo identificadores de correlación y, cuando corresponda, el usuario en cuyo nombre actuó el agente.
La ventaja no es solamente saber qué ocurrió después de un incidente. Es poder limitar el incidente desde el principio.
Si un agente es comprometido pero únicamente tiene acceso de lectura a un conjunto específico de datos, el atacante se encuentra con una barrera arquitectónica. No basta con controlar el agente: también tendría que superar los controles de autorización de los sistemas posteriores.
Zero Trust también cambia la forma de diseñar las APIs
Este principio resulta especialmente importante cuando una aplicación de IA empieza a consumir APIs internas.
Una práctica bastante común es crear una cuenta con permisos suficientes para que la integración “funcione” y luego concentrarse en proteger la credencial. Zero Trust plantea el problema desde otro ángulo: incluso si la credencial es válida, la solicitud debe estar autorizada para realizar exactamente esa acción sobre exactamente ese recurso.
Por eso conceptos como RBAC, ABAC, scopes, tokens de corta duración y políticas de autorización vuelven a adquirir protagonismo. No se trata solamente de autenticar al agente, sino de comprobar qué está autorizado a hacer en cada interacción.
Google aplica un principio similar en BeyondProd: los servicios no deberían confiar implícitamente unos en otros, y la autorización debe basarse en identidades de servicio y políticas específicas. Uno de los objetivos es reducir el blast radius: si un componente es comprometido, el atacante no debería poder utilizarlo fácilmente como puente para desplazarse por toda la infraestructura.
Para una arquitectura con IA, este concepto es especialmente relevante. Un agente puede encadenar varias acciones: consultar una base de datos, llamar una API, ejecutar una función, recuperar información de un sistema documental y finalmente generar una respuesta. Cada salto representa una nueva relación de confianza que debería poder validarse.
No basta con proteger al usuario: hay que proteger al agente
Aquí aparece una diferencia importante frente a las implementaciones tradicionales de Zero Trust. Durante años, buena parte de la conversación estuvo centrada en usuarios, dispositivos y accesos remotos. Con los agentes de IA aparece una nueva categoría de identidad.
El agente puede no ser una persona, pero tiene credenciales, permisos, herramientas, acceso a datos y capacidad para ejecutar acciones. Desde el punto de vista de seguridad, eso lo convierte en un actor dentro de la arquitectura.
Microsoft incluso recomienda políticas específicas para identidades de agentes, revisión periódica de sus permisos y controles que limiten herramientas, integraciones y accesos no aprobados.
Esto también ayuda a evitar un problema que probablemente veremos con más frecuencia: la proliferación descontrolada de agentes. Una empresa puede comenzar con un asistente para consultar el CRM, después crear otro para facturación, otro para soporte y otro para operaciones. Si todos utilizan identidades genéricas y permisos amplios, en poco tiempo puede resultar difícil saber qué agente tiene acceso a qué información.
Zero Trust obliga a hacer la pregunta desde el principio: ¿quién es este agente, qué puede hacer, sobre qué recursos y durante cuánto tiempo?
La red sigue siendo importante, pero ya no es suficiente
Esto no significa que el firewall, la segmentación de red, las VPN o los sistemas de detección hayan dejado de ser necesarios. El problema aparece cuando cualquiera de ellos se convierte en la principal barrera de seguridad.
Una arquitectura Zero Trust puede seguir utilizando controles de red, pero los complementa con identidad, autorización, estado del dispositivo, contexto, segmentación, protección de aplicaciones, gestión de datos y monitoreo. CISA plantea precisamente estos elementos como pilares que deben evolucionar de manera coordinada, acompañados de capacidades transversales de visibilidad, automatización y gobierno.
La razón es sencilla: hoy una solicitud puede recorrer varios sistemas antes de llegar al recurso que realmente contiene la información sensible. El hecho de que el primer punto de entrada esté protegido no garantiza que los siguientes saltos también lo estén.
¿Cómo empezar a llevar Zero Trust a una arquitectura con IA?
No hace falta transformar toda la infraestructura de una empresa de un día para otro. De hecho, suele ser más razonable comenzar por identificar los sistemas que concentran información crítica y los flujos que actualmente tienen mayor nivel de privilegio.
El primer paso es saber qué identidades existen —humanas, aplicaciones, servicios y agentes— y qué permisos tiene cada una. Después conviene revisar si esos permisos corresponden realmente a las funciones que ejecutan. En muchos entornos aparecen cuentas antiguas, integraciones que ya no se utilizan y permisos heredados que nadie recuerda por qué existen.
Con los agentes de IA, además, conviene definir desde el diseño qué herramientas pueden utilizar, qué datos pueden consultar y cuáles acciones requieren una autorización adicional. Microsoft recomienda documentar el propósito, los datos, las herramientas y el entorno operativo de cada agente, además de revisar sus permisos cuando cambian sus flujos de trabajo o integraciones.
También es importante pensar desde el principio en la revocación. ¿Qué ocurre si un agente se comporta de manera anómala? ¿Se puede deshabilitar rápidamente? ¿Se pueden invalidar sus tokens? ¿Se pueden retirar sus permisos sin afectar a otros servicios? Estas preguntas forman parte de la seguridad de la arquitectura, no de una etapa posterior.
Zero Trust no consiste en impedir que la IA actúe
La llegada de agentes autónomos hace que Zero Trust sea todavía más relevante porque aumenta la capacidad de los sistemas para actuar sin intervención humana constante.
El objetivo no debería ser impedir que un agente consulte información, ejecute una tarea o interactúe con otros sistemas. Lo importante es que esas acciones estén delimitadas por arquitectura y no dependan exclusivamente de que el software se comporte correctamente.
La experiencia de Google con BeyondCorp y BeyondProd muestra cómo este principio puede aplicarse tanto a usuarios como a servicios. Microsoft, por su parte, está trasladando conceptos como identidad dedicada, mínimo privilegio, autorización por alcance y acceso just-in-time directamente al mundo de los agentes de IA.
En otras palabras, Zero Trust no busca impedir que la IA actúe; busca que, incluso cuando un componente falle, sea comprometido o tome una decisión incorrecta, su capacidad de hacer daño esté limitada por la propia arquitectura.
Y probablemente esa sea una de las diferencias más importantes entre incorporar IA a una infraestructura existente y diseñar una infraestructura realmente preparada para la IA.