La IA agéntica obliga a Zero Trust a enfrentarse a una crisis de identidad

La IA agéntica llegó a Google News con una afirmación contundente: los sistemas autónomos están poniendo la ciberseguridad Zero Trust «patas arriba». El titular de Breaking Defense identifica un conflicto real, aunque los detalles subyacentes siguen siendo difíciles de verificar de forma independiente. Los equipos de seguridad construyeron controles de acceso en torno a personas, dispositivos y aplicaciones predecibles. Los agentes de IA ahora difuminan las tres categorías mientras actúan con autoridad delegada.

Esto no vuelve obsoleto a Zero Trust. Cambia lo que las organizaciones deben verificar, con qué frecuencia deben hacerlo y qué identidad realizó cada acción. Un agente puede interpretar un objetivo, seleccionar herramientas, leer contenido externo, llamar a API y modificar datos. Su comportamiento no queda plenamente reflejado en los permisos asignados a su propietario humano.

El resultado es una inversión incómoda. Zero Trust asume que cada solicitud debe ser evaluada, pero los flujos de trabajo agénticos generan largas cadenas de solicitudes a velocidad de máquina. Por tanto, la competencia principal no es IA agéntica frente a Zero Trust. Es control de acceso estático frente a control continuo sobre el comportamiento autónomo.

La afirmación de Google News apunta a un cambio real en la seguridad

El cambio importante no es que la IA pueda acceder a sistemas empresariales, sino que pueda decidir qué hacer después de obtener acceso.

El software tradicional sigue rutas que los desarrolladores definen de antemano. Puede contener errores, aceptar entradas maliciosas o exponer interfaces vulnerables. Sin embargo, los defensores normalmente pueden relacionar sus funciones previstas con cuentas, procesos y conexiones de red establecidos.

La IA agéntica añade una capa de toma de decisiones entre la instrucción de un usuario y la acción resultante. Un agente puede dividir un objetivo amplio en tareas más pequeñas, elegir entre herramientas disponibles y adaptarse cuando una vía falla. NIST describe a los agentes modernos como modelos de propósito general combinados con software que les permite manipular herramientas más allá de la generación de texto.

Estas herramientas pueden incluir navegadores, bases de datos, calendarios, intérpretes de código, archivos locales e interfaces administrativas. La taxonomía de uso de herramientas de NIST distingue el acceso de solo lectura del acceso de escritura restringido o sin restricciones. También separa los entornos de confianza de los que no lo son.

Esta distinción importa porque un solo agente suele atravesar varias categorías durante una misma tarea. Podría leer un correo electrónico, extraer un número de cliente, consultar una base de datos interna y actualizar un registro de soporte. Cada paso puede parecer permitido cuando se revisa por separado.

El flujo de trabajo combinado aún puede producir un resultado inseguro. Un atacante podría insertar instrucciones ocultas en el correo electrónico. El agente podría interpretar esas instrucciones como parte de su tarea y luego utilizar permisos legítimos para divulgar datos.

Este ataque se denomina inyección indirecta de prompts, lo que significa que las instrucciones maliciosas llegan a un agente a través del contenido que procesa. El atacante no necesita la contraseña del empleado. El atacante apunta a la interpretación que hace el agente de la información confiable y no confiable.

El titular de Google News recoge este cambio con la expresión «patas arriba». Antes, los equipos de seguridad se preocupaban de que las personas hicieran un mal uso del software o cedieran credenciales. Ahora también deben considerar software que interpreta la autoridad de una persona y actúa de forma independiente dentro de ella.

No se trata simplemente de otro endpoint que entra en la red. Un endpoint normalmente tiene una función, una postura y un modelo de propiedad relativamente estables. Un agente puede cambiar su plan inmediato mientras conserva la misma identidad, credenciales y conexión.

Eso crea un problema de visibilidad. Un registro puede mostrar que una cuenta de servicio válida accedió a una base de datos. Puede no revelar qué usuario inició la tarea, qué agente elaboró el plan o qué entrada externa influyó en la decisión.

El titular debe seguir tratándose como una tesis, no como prueba de una filtración específica. El artículo proporcionado de Google News no incluye detalles verificados de ningún incidente. Sin embargo, el problema de seguridad más amplio cuenta con respaldo de investigación pública y del trabajo actual en normas.

Los equipos de seguridad ya no protegen solo accesos de persona a aplicación y de aplicación a aplicación. Deben proteger una cadena que conecta a una persona, un agente, un modelo, varias herramientas y múltiples fuentes de datos. La confianza puede filtrarse en cada transferencia.

Zero Trust se diseñó para solicitudes, no para objetivos abiertos

Zero Trust sigue siendo relevante, pero su unidad convencional de control es demasiado limitada para el trabajo autónomo.

NIST publicó su arquitectura fundacional de Zero Trust en 2020. El modelo rechaza la confianza implícita basada en la ubicación de red o la propiedad de los activos. La autenticación y la autorización tienen lugar antes de que una sesión alcance un recurso empresarial.

La arquitectura se centra en los recursos, no en los segmentos de red tradicionales. Parte de la premisa de que una red puede ya estar comprometida. Por ello, el acceso debe limitarse al conjunto mínimo de permisos necesarios para una misión específica.

Este enfoque contrarresta el antiguo modelo perimetral. Bajo la seguridad perimetral, los usuarios autenticados a menudo recibían un acceso amplio tras entrar en una red de confianza. Después, los atacantes podían moverse lateralmente entre sistemas tras comprometer una cuenta o un dispositivo.

La IA agéntica no invalida estos principios. De hecho, el mínimo privilegio y la evaluación continua se vuelven más importantes cuando las máquinas pueden realizar muchas acciones rápidamente. La dificultad reside en traducir un objetivo amplio de usuario en permisos exigibles y de corta duración.

Pensemos en un agente al que se le pide preparar un informe trimestral de riesgo de clientes. La tarea parece informativa, pero completarla puede requerir varias capacidades. El agente necesita localizar registros, combinar datos, calcular tendencias y elaborar un documento.

¿Debe el agente recibir acceso a todos los registros de clientes durante toda la tarea? ¿Debe conservar esos permisos después? ¿Puede enviar el informe por correo electrónico o la distribución debe requerir una aprobación independiente?

Un sistema de acceso convencional puede responder a estas preguntas mediante el rol existente del usuario. Si el empleado puede leer la base de datos y enviar correos electrónicos, el agente hereda ambas facultades. Esa herencia es simple, pero crea una autoridad excesiva.

El agente puede realizar combinaciones de acciones que el empleado nunca pretendió. También puede repetirlas a una escala que los flujos de trabajo manuales rara vez alcanzan. Un pequeño error de interpretación puede convertirse en cientos de consultas a bases de datos o mensajes.

Los objetivos abiertos dificultan el diseño de políticas. «Encuentra la evidencia relevante» no especifica en qué repositorios se debe buscar. «Resuelve el problema» no define si el agente puede emitir un reembolso, modificar una cuenta o ejecutar código.

Zero Trust evalúa tradicionalmente las solicitudes de acceso mediante identidad, estado de salud del dispositivo, sensibilidad del recurso y contexto ambiental. Los sistemas agénticos añaden otra pregunta: ¿esta acción sigue siendo coherente con la tarea que justificó el acceso?

Esta pregunta requiere controles conscientes de la intención. Estos controles comparan una acción con el propósito asignado al agente, su plan actual y la política aprobada. No pueden depender únicamente de que una cuenta posea técnicamente un permiso.

El límite de seguridad también se desplaza durante el trabajo multiagente. Un agente puede delegar investigación en otro agente. Ese segundo agente puede llamar a un servicio de terceros que devuelve contenido con nuevas instrucciones.

Cada transferencia puede alterar el contexto mientras conserva una autorización aparente. Una política estática ve identidades aprobadas que transfieren datos. Una política de comportamiento debe determinar si toda la cadena sigue sirviendo al objetivo original.

Por eso la seguridad de la IA agéntica no puede detenerse en la segmentación de red. El plano de control debe comprender identidades, tareas, herramientas, linaje de datos e historial de acciones. También debe preservar esas relaciones para investigaciones posteriores.

La promesa original de Zero Trust sigue vigente: no conceder confianza solo porque algo ya está dentro. Los flujos de trabajo agénticos simplemente revelan que «dentro» puede describir una ventana de contexto, una tarea delegada o una cadena de herramientas. Ya no se refiere únicamente a una red.

Los agentes de IA necesitan identidades separadas de las de sus propietarios

Una organización no puede gobernar a un agente autónomo si cada acción aparece bajo una cuenta humana o de servicio compartida.

La identidad es el primer punto de presión para los equipos de seguridad empresarial. Las personas tienen registros laborales, responsables, funciones laborales y procedimientos de salida. Las aplicaciones tienen propietarios, procesos de lanzamiento y cuentas de servicio.

Los agentes combinan características de ambos grupos. Pueden recibir objetivos de personas, pero se ejecutan mediante software. Pueden operar brevemente para una tarea o seguir funcionando como trabajadores digitales persistentes.

Tratar a un agente como una función oculta dentro de una aplicación oscurece la responsabilidad. Tratarlo como un empleado normal también genera una falsa sensación de confianza. El agente necesita una identidad de máquina de primera clase vinculada a su propietario, propósito y despliegue.

Esa identidad no debe reemplazar la identidad del usuario que inicia la acción. Ambas deben mantenerse durante todo el flujo de trabajo. Los investigadores necesitan saber quién solicitó una acción y qué agente la ejecutó.

Un registro de auditoría útil también debe capturar el modelo, la herramienta, la política y la fuente de datos implicados. Sin este contexto, un registro de base de datos solo muestra el acceso final. No puede explicar por qué el agente creyó que ese acceso era apropiado.

Los equipos de seguridad deben evitar las credenciales compartidas en despliegues de agentes. Las cuentas compartidas impiden una atribución fiable y complican la revocación. También permiten que los agentes abandonados sigan activos después de que terminen sus proyectos originales.

La identidad de un agente necesita un ciclo de vida. Su creación debe identificar a un propietario responsable y un uso aprobado. Las revisiones periódicas deben confirmar que el agente sigue siendo necesario y que sus permisos aún corresponden a su propósito.

La expiración es igual de importante. Los agentes temporales deben perder acceso cuando termina una tarea o un proyecto. Los agentes persistentes deben someterse a una recertificación regular, al igual que las cuentas humanas privilegiadas.

Los permisos también deben ser específicos para cada tarea y de corta duración. Un agente que prepara un informe puede recibir acceso temporal de solo lectura a registros seleccionados. Enviar ese informe fuera de la organización debe requerir un permiso independiente o confirmación humana.

Este diseño reduce la acumulación de privilegios, que ocurre cuando las identidades acumulan accesos que ya no corresponden a sus responsabilidades. La acumulación de privilegios ya es difícil de gestionar con empleados. Los agentes autónomos pueden multiplicar el problema porque los equipos pueden crearlos rápidamente.

Por ello, el descubrimiento de agentes se convierte en un requisito operativo. Los equipos de seguridad necesitan un inventario que abarque servicios SaaS, plataformas de desarrollo, sistemas de automatización internos e integraciones de terceros. Los registros de compras por sí solos no identificarán a los agentes creados dentro de productos existentes.

El descubrimiento debe distinguir entre una función de IA y una identidad que actúa. Una función de resumen que solo lee un documento conlleva riesgos distintos de los de un agente que puede buscar en unidades y enviar mensajes. Ambos pueden utilizar el mismo modelo.

El propietario también debe ser visible en las políticas y los registros. Cuando un agente actúa fuera de lo esperado, quienes responden necesitan una persona o un equipo capaz de suspenderlo. La automatización anónima provoca demoras durante los incidentes.

Las organizaciones ya utilizan identidades no humanas para servicios, cargas de trabajo y máquinas. Las identidades de agentes amplían esa disciplina en lugar de reemplazarla. La diferencia es que la política debe contemplar un comportamiento variable dentro del mismo rol asignado.

Los principales proveedores de seguridad se están moviendo en esta dirección. Cisco anunció descubrimiento de agentes, controles de identidad agéntica y aplicación de Model Context Protocol en su actualización de seguridad para agentes. Model Context Protocol, o MCP, conecta modelos con herramientas y datos externos.

Los anuncios de proveedores no son evidencia independiente de que los controles funcionen en todos los despliegues. Sí muestran hacia dónde se dirige la competencia. Las plataformas de identidad, los intermediarios de acceso y las pasarelas de seguridad quieren convertirse en el punto de control del tráfico de agentes.

Los compradores empresariales deberían evitar tratar una única pasarela como una solución completa. NIST lleva tiempo señalando que ningún proveedor suministra por sí solo una arquitectura Zero Trust íntegra. La seguridad agéntica añade más componentes y más oportunidades de aplicación incoherente.

La presión inmediata recae sobre los equipos de gestión de identidades y accesos. Deben admitir actores de máquina creados rápidamente sin repetir el problema de las cuentas de servicio no gestionadas. Las asignaciones estáticas de roles no serán suficientes.

El secuestro de agentes expone los límites de las comprobaciones estáticas de permisos

Un agente correctamente autenticado puede seguir realizando una acción equivocada, porque la autenticación no valida su razonamiento.

El argumento más sólido para replantear Zero Trust procede de la investigación sobre el secuestro de agentes. En marzo de 2026, NIST informó de los resultados de una gran competición pública de red teaming que abarcó 13 modelos de frontera. Más de 400 participantes realizaron más de 250.000 intentos de ataque.

Se detectó al menos un ataque de secuestro exitoso contra cada modelo evaluado. Los modelos diferían en su resistencia, pero la capacidad no predijo de forma consistente la seguridad. Algunas familias de ataques también se transfirieron entre distintos modelos y escenarios.

Estos resultados no significan que todos los agentes desplegados sean fáciles de comprometer. Una competición incentiva a atacantes centrados y puede no reproducir todos los controles de producción. Sí establece que la resistencia a nivel de modelo, por sí sola, no puede servir como perímetro de seguridad.

NIST define el secuestro de agentes como un ataque que introduce instrucciones maliciosas dentro de los datos que procesa un agente. El objetivo es redirigir al agente hacia un comportamiento dañino. Entre los posibles resultados se incluyen la exfiltración de datos o la ejecución de código malicioso.

El detalle crucial es que el agente suele utilizar herramientas y credenciales válidas. Un firewall puede ver una conexión aprobada. Un sistema de identidad puede ver una cuenta autenticada. El paso peligroso se produce en la interpretación que hace el agente del contenido.

Esto hace que las listas estáticas de permitidos sean incompletas. Permitir que un agente lea correo electrónico y actualice una base de datos puede ser necesario para su trabajo. La política debe seguir impidiendo que un correo electrónico redefina lo que debe hacer la herramienta de base de datos.

Los hallazgos de red teaming pertinentes respaldan la defensa en profundidad. Los modelos necesitan evaluación, pero los despliegues también requieren herramientas restringidas, límites de datos, supervisión y puntos de aprobación.

Los permisos de las herramientas deberían reflejar las consecuencias, no la conveniencia. Leer una página web pública presenta riesgos distintos a ejecutar código descargado. Consultar un registro de cliente difiere de eliminarlo o exportarlo.

Las herramientas de alto impacto deberían exponer operaciones acotadas. Un agente que necesita programar una reunión no debería recibir control ilimitado del buzón. Un agente financiero que prepara un pago tampoco debería aprobarlo y transmitirlo.

Este principio se denomina segregación de funciones. Evita que una sola identidad controle todos los pasos de un proceso sensible. Los sistemas agénticos necesitan la misma división, incluso cuando la automatización hace tentadora la consolidación.

La aprobación humana sigue siendo útil en límites irreversibles. Las transferencias, eliminaciones, publicaciones externas, despliegues en producción y cambios de credenciales merecen verificaciones explícitas. La aprobación debe mostrar la acción prevista y el contexto relevante.

Un botón genérico de “permitir” aporta poca protección. La persona revisora debe saber qué agente solicitó la acción, qué datos utilizó y qué efecto producirá la aprobación. De lo contrario, la automatización simplemente traslada la ingeniería social a la pantalla de aprobación.

La supervisión debería centrarse en los cambios de comportamiento. Un agente que accede de pronto a repositorios desconocidos puede indicar secuestro o una planificación defectuosa. Las llamadas repetidamente fallidas a herramientas pueden señalar que un agente está explorando más allá de su función.

Los límites de velocidad también reducen los daños causados por errores. La ejecución a velocidad de máquina puede convertir una sola mala decisión en un incidente generalizado. Limitar el volumen de acciones da tiempo a los sistemas de supervisión y a los equipos de respuesta para intervenir.

El aislamiento en sandbox sigue siendo valioso, pero no debería generar una presunción de seguridad. Un agente puede causar daños sin escapar de su entorno de ejecución. Enviar datos autorizados al destino equivocado puede no requerir ningún exploit de software.

La incertidumbre central es si los sistemas conscientes de la intención pueden tomar decisiones fiables sin bloquear trabajo útil. Los planes de los agentes cambian, las tareas empresariales contienen ambigüedad y las políticas no pueden anticipar todas las excepciones legítimas.

Los controles excesivamente estrictos producirán solicitudes de aprobación constantes. Los equipos podrían entonces conceder permisos más amplios para recuperar productividad. Esa respuesta recrea la confianza implícita exacta que Zero Trust pretendía eliminar.

Los controles excesivamente permisivos producen el fallo contrario. Los agentes operan sin problemas hasta que una entrada maliciosa o un error de planificación explota su autoridad. Los equipos de seguridad deben medir tanto el trabajo bloqueado como las acciones inseguras.

Esta disyuntiva impide afirmar fácilmente que un producto de “Zero Trust agéntico” haya resuelto el problema. Las demostraciones de productos suelen mostrar flujos de trabajo seleccionados. Los despliegues reales contienen sistemas heredados, identidades compartidas y registros inconsistentes.

El enfoque más creíble a corto plazo es por capas. Asignar una identidad a cada agente, restringir cada herramienta, preservar al usuario iniciador, validar las acciones relevantes y supervisar el comportamiento. Hay que asumir que las salvaguardas del modelo fallarán en ocasiones.

La batalla competitiva se desplaza al plano de control

Los proveedores de seguridad compiten por mediar el comportamiento de los agentes, mientras las empresas aún carecen de un modelo común para demostrar que esa mediación funciona.

La IA agéntica crea oportunidades para proveedores de identidad, fabricantes de seguridad de red, plataformas cloud y empresas especializadas en seguridad de IA. Cada grupo controla una parte distinta del flujo de trabajo. Ninguno ve automáticamente la cadena completa.

Los proveedores de identidad saben quién recibió acceso. Las plataformas de red observan las conexiones entre sistemas. Los proveedores cloud pueden supervisar cargas de trabajo y llamadas a API. Las herramientas de seguridad de IA inspeccionan prompts, salidas de modelos y solicitudes de herramientas.

La posición más valiosa es el punto de decisión de políticas. En una arquitectura Zero Trust, ese componente evalúa el acceso y decide si la aplicación debe permitirlo. Los sistemas agénticos hacen que esa decisión sea más rica y más disputada.

Un proveedor de redes puede sostener que la comunicación de los agentes debería pasar por un intermediario de seguridad. Un proveedor de identidad puede centrar la política en las identidades de máquina y la autorización delegada. Un proveedor de seguridad de IA puede priorizar la inspección de prompts y la evaluación del comportamiento.

Las tres visiones contienen parte de la respuesta. El contexto de red no puede revelar todas las instrucciones maliciosas. La inspección de prompts no puede, por sí sola, aplicar el bloqueo de una consulta a una base de datos. La verificación de identidad no puede garantizar que un agente autenticado siga su propósito.

MCP se ha convertido en un foco porque estandariza las conexiones entre modelos y herramientas. Una pasarela puede inventariar servidores, restringir operaciones y registrar llamadas. Sin embargo, no todos los agentes usan MCP, y una pasarela no puede gobernar las herramientas que lo eluden.

La comunicación entre agentes presenta otro desafío. La delegación puede cruzar modelos, proveedores o límites organizativos. El agente receptor necesita pruebas sobre la identidad, la autoridad y el alcance solicitado del remitente.

Un mensaje firmado puede autenticar al remitente. No demuestra que el plan del remitente sea seguro. La política debe separar la procedencia, que identifica de dónde proviene una solicitud, de la autorización, que determina si debe continuar.

El trabajo de estandarización empieza a abordar estas lagunas. NIST lanzó su iniciativa de estándares para agentes en febrero de 2026. Su agenda incluye interoperabilidad, protocolos abiertos, seguridad, identidad y adopción fiable.

Esta iniciativa es importante porque las organizaciones necesitan representaciones comparables de la identidad y la autoridad de los agentes. Sin formatos comunes, cada plataforma crea identidades y señales de política propietarias. Los equipos de seguridad tienen entonces dificultades para aplicar controles en todos los entornos.

Los estándares por sí solos no pueden resolver la tolerancia al riesgo. Un hospital, un banco, un contratista de defensa y una agencia de marketing asignarán consecuencias distintas a la misma acción de una herramienta. La interoperabilidad proporciona infraestructura compartida, no una política universal.

El planteamiento de Breaking Defense es especialmente pertinente para entornos de alta garantía. Los sistemas de defensa suelen combinar datos clasificados, restricciones de misión, equipos heredados y una estricta rendición de cuentas. Una acción autónoma puede tener consecuencias más allá de la automatización administrativa habitual.

Estos entornos también generan presión para automatizar. Los analistas se enfrentan a grandes volúmenes de alertas, documentos y datos de sensores. Los agentes pueden ayudar a correlacionar información y ejecutar pasos repetitivos, pero una autonomía mayor incrementa la necesidad de controles trazables.

Por tanto, la competencia debe juzgarse mediante pruebas, no por el vocabulario de los productos. Los compradores deben probar si un control identifica a los agentes de forma fiable, vincula las acciones con responsables, limita las herramientas y produce registros de auditoría utilizables.

También deberían probar los casos de fallo. ¿Qué ocurre cuando el proveedor de identidad no está disponible? ¿Puede un agente recurrir a permisos almacenados en caché? ¿Un intermediario falla de forma cerrada o el tráfico evita la inspección?

La cobertura multiplataforma importa tanto como las funcionalidades individuales. Una organización puede usar un modelo cloud, el agente de programación de otro proveedor y varios asistentes SaaS. Un control que solo ve un entorno deja importantes puntos ciegos.

Es probable que el mercado se consolide en torno a plataformas integradas, pero la integración puede crear su propio riesgo de concentración. Un plano de políticas comprometido podría afectar a muchos agentes. El registro y la aplicación independientes siguen siendo salvaguardas importantes.

Google News puede amplificar titulares sobre la IA agéntica sustituyendo modelos de seguridad conocidos. La conclusión más precisa es más acotada. Los proveedores existentes deben extender Zero Trust desde las decisiones de conexión hasta la gobernanza de identidad, intención y acciones.

Lo que los equipos de seguridad deberían vigilar a continuación

La próxima fase se decidirá mediante pruebas de despliegue medibles, no por afirmaciones más amplias sobre seguridad autónoma.

La primera señal es si los grupos de estándares producen especificaciones utilizables para la identidad de agentes y la autorización delegada. NIST indicó que su iniciativa desarrollaría investigación, orientación y otros entregables. Las empresas deberían vigilar formatos que funcionen entre proveedores.

Una especificación de identidad útil debe vincular un agente con un propietario, propósito, modelo y herramientas aprobadas. También debería preservar al usuario iniciador durante la delegación. Si las plataformas adoptan representaciones incompatibles, la gobernanza seguirá fragmentada.

La segunda señal son las pruebas de seguridad independientes. La competición de NIST encontró ataques exitosos contra todos los modelos de frontera evaluados, pero las organizaciones necesitan evaluaciones a nivel de despliegue. Las pruebas deberían incluir modelos, herramientas, permisos, memoria y datos externos.

Las pruebas comparativas deberían medir más que el éxito de la inyección de prompts. Deberían examinar si los agentes exceden el alcance de sus tareas, utilizan indebidamente herramientas legítimas u ocultan acciones relevantes dentro de flujos de trabajo extensos. También deberían probar la recuperación y la calidad de la auditoría.

Si el éxito de los ataques disminuye mientras los agentes conservan capacidades útiles, se reforzará la confianza en los controles conscientes de la intención. Si los modelos mejorados siguen siendo vulnerables en implementaciones con numerosas herramientas, los controles de infraestructura cobrarán aún más importancia.

La tercera señal es el comportamiento empresarial después de los pilotos. Los equipos de seguridad deberían controlar cuántos agentes reciben identidades únicas, credenciales limitadas y responsables definidos. También deberían medir los agentes abandonados y los permisos sin revisar.

Las cifras de adopción por sí solas revelan poco. Una empresa puede desplegar miles de agentes y mantenerlos en modo de solo lectura y aislados. Un único agente con amplio acceso a producción puede implicar un riesgo mayor que toda esa población.

Los informes de incidentes aportarán otra comprobación de la realidad. Los casos públicos deberían explicar si los fallos procedieron de inyección de prompts, privilegios excesivos, confusión de identidad o límites de aprobación inexistentes. Sin ese nivel de detalle, el sector no puede comparar las defensas.

Los responsables de seguridad deberían plantear preguntas directas antes de ampliar un piloto:

• ¿Cada agente tiene una identidad única y un responsable identificado?

• ¿Los permisos pueden caducar automáticamente cuando termina la tarea?

• ¿Los registros conservan tanto a la persona solicitante como al agente que actúa?

• ¿Qué herramientas pueden generar cambios irreversibles?

• ¿El contenido externo puede influir en esas llamadas a herramientas?

• ¿Qué volumen de acciones activa una revisión o suspensión?

• ¿Los equipos de respuesta pueden desactivar un agente sin detener toda la plataforma?

• ¿Los agentes delegados están limitados por la tarea original?

• ¿El sistema falla de forma segura cuando los servicios de políticas no están disponibles?

• ¿Los auditores pueden reconstruir por qué se produjo una acción sensible?

Estas preguntas convierten la afirmación de que se ha «puesto patas arriba» en una prueba de implementación. Si una plataforma no puede responderlas, su discurso sobre Zero Trust sigue siendo incompleto. Si puede hacerlo, es posible que la arquitectura ya se esté adaptando.

La conclusión más importante es que las organizaciones no deberían abandonar Zero Trust. Deberían aplicarlo a unidades de autoridad más pequeñas y dinámicas. Cada agente, llamada a herramienta, delegación y acción relevante merece su propio contexto de políticas.

Este enfoque introducirá fricción. Algunas tareas automatizadas requerirán herramientas más limitadas o confirmación humana. Algunos pilotos se ralentizarán mientras los equipos crean inventarios y controles de ciclo de vida.

La alternativa es una autoridad oculta. Los agentes heredarán amplios permisos humanos, procesarán contenido no confiable y dejarán registros incompletos. Los equipos de seguridad descubrirán entonces los flujos de trabajo autónomos solo después de un incidente.

La IA agéntica no ha derrotado a Zero Trust. Ha dejado al descubierto dónde muchos programas de Zero Trust se detuvieron: en la autenticación, el acceso a la red o la postura del dispositivo. La próxima versión debe gobernar lo que las máquinas autenticadas deciden hacer.

Por tanto, vale la pena mantener la pregunta planteada a través de Google News, aunque el titular exagere la magnitud del cambio. ¿Puede su organización rastrear la identidad, el propósito, la evidencia y la autoridad de un agente antes de que se ejecute su próxima acción?

Empiece con un flujo de trabajo de producción y reconstruya esa cadena de principio a fin. Si alguna transferencia se vuelve invisible, trátela como una brecha de control. Este ejercicio aporta más valor que adoptar otra etiqueta de seguridad, porque comprueba si Zero Trust acompaña al agente durante el trabajo real.