La seguridad de los agentes de IA comienza con la identidad, pero las empresas necesitan más que credenciales

Google News destacó una advertencia del 2 de septiembre sobre los agentes de IA, pero el conflicto va mucho más allá de otra lista de verificación de seguridad. El artículo sostiene que las empresas deben responder tres preguntas antes de que los agentes se extiendan aún más: dónde están, a qué pueden conectarse y qué pueden hacer.

Este planteamiento apareció en un artículo invitado de GuidePoint Security escrito por Ariel Zommer, especialista en marketing de productos de seguridad de Okta. Su afirmación central es sencilla. Un agente se convierte en un problema de identidad cuando puede autenticarse, acceder a sistemas corporativos o actuar sin una dirección humana constante.

El momento importa. NIST publicó una advertencia independiente sobre identidad el 27 de agosto, menos de una semana antes de que apareciera el artículo de GuidePoint. Microsoft, Okta y otros proveedores de identidad también están convirtiendo las identidades de los agentes en objetos formales de producto.

Esta convergencia cambia el debate empresarial. La pregunta central ya no es si un modelo puede producir una respuesta precisa. Es si cada acción resultante tiene un actor visible, autoridad limitada, un responsable asignado y una conexión revocable.

El argumento resulta familiar porque la gestión de identidades ya gobierna a empleados, aplicaciones y cargas de trabajo tradicionales. Los agentes complican ese modelo porque sus acciones son probabilísticas, sus conexiones cambian y una sola solicitud puede desencadenar muchas operaciones posteriores.

Por tanto, la identidad es necesaria, pero no suficiente. Una credencial puede identificar a un agente sin demostrar que su acción actual sea segura. La verdadera pugna es entre una autonomía responsable y un acceso conveniente que las organizaciones no pueden rastrear por completo.

Lo que Google News realmente destacó

La noticia no es la divulgación de una nueva vulnerabilidad. Es una advertencia coordinada de que la adopción de agentes está superando los controles empresariales de identidad.

El argumento original sobre identidad fue publicado por GuidePoint Security el 2 de septiembre de 2026. Fue escrito por un empleado de Okta y presentado como una perspectiva de un socio.

Esa distinción importa. Los lectores deberían considerar el artículo como un análisis respaldado por un proveedor, no como una prueba independiente de que una sola plataforma comercial resuelve todos los problemas de seguridad de los agentes. Sus tres preguntas siguen siendo útiles porque describen brechas de control medibles.

La primera pregunta plantea dónde existen los agentes de una organización. Un inventario debe incluir agentes desarrollados internamente, funciones integradas en productos SaaS, agentes alojados en la nube, herramientas autorizadas por empleados y sistemas experimentales.

Los inventarios tradicionales de activos suelen pasar por alto estas categorías. Un desarrollador puede crear un agente dentro de una cuenta de nube aprobada sin registrarlo como una aplicación empresarial independiente. Un empleado también puede autorizar una herramienta externa mediante OAuth.

OAuth es un estándar de autorización que permite a una aplicación recibir acceso limitado a otro servicio. Su conveniencia puede ocultar relaciones de confianza persistentes a equipos que nunca aprobaron el agente subyacente.

Por ello, el descubrimiento requiere más que analizar repositorios de código. Los equipos de seguridad también necesitan inventarios en la nube, registros de aplicaciones, concesiones OAuth, cuentas de servicio, señales del navegador, registros de API gateway y conexiones de Model Context Protocol.

Model Context Protocol, o MCP, permite que las aplicaciones de IA se conecten con herramientas y datos mediante una interfaz común. Puede simplificar la integración al tiempo que amplía el conjunto de sistemas accesibles.

La segunda pregunta plantea a qué puede conectarse cada agente descubierto. Ese mapa debería abarcar aplicaciones empresariales, API internas, bases de datos, sistemas de colaboración, secretos, cuentas de servicio y otros agentes.

Una conexión no revela el riesgo completo. Los equipos de seguridad también necesitan conocer su método de autorización, alcance de permisos, duración de las credenciales, responsable empresarial, historial de aprobaciones y ruta de revocación.

La tercera pregunta plantea qué puede hacer un agente después de conectarse. El acceso de lectura, la modificación de registros, la ejecución de código, el movimiento de dinero y la suplantación de usuarios tienen consecuencias muy distintas.

Estos permisos también pueden combinarse. Un agente que lee correo electrónico y crea tickets de soporte parece limitado cuando cada conexión se revisa por separado. Se vuelve más relevante cuando puede extraer instrucciones y activar acciones externas.

Google News ayudó a situar la advertencia ante una audiencia más amplia. Sin embargo, el evento importante ocurrió bajo la capa de agregación. Los proveedores de identidad y los organismos públicos de estándares están convergiendo en torno a los agentes como actores empresariales de primera clase.

Ese cambio ofrece a los líderes de seguridad un punto de partida más claro. También genera presión para distinguir la identidad de un agente de la del usuario, la aplicación o la cuenta de servicio que lo lanzó.

Un token prestado de un empleado no puede proporcionar esa distinción de forma clara. Tampoco puede hacerlo una única clave API compartida por varios agentes. Ambos esquemas debilitan la atribución durante auditorías e investigaciones de incidentes.

El cambio inmediato es conceptual, pero operativo. Las empresas ahora necesitan registros de ciclo de vida independientes para los agentes, incluidos su creación, titularidad, autorización, revisión, suspensión y retirada.

La identidad se ha convertido en el plano de control de la IA

Un agente necesita una identidad distinta porque la autoridad sin atribución convierte la automatización rutinaria en un problema de investigación sin límites.

La gestión de identidades y accesos, o IAM, determina quién puede acceder a un recurso y bajo qué condiciones. Los sistemas IAM existentes ya proporcionan directorios, motores de políticas, revisiones de acceso, servicios de tokens y registros de auditoría.

Estos componentes brindan a las empresas una base práctica. Pueden registrar un agente, asociarlo con un responsable, conceder permisos específicos y revocar esos permisos cuando el agente cambia o se retira.

NIST reforzó esta postura en su reciente análisis sobre la base de identidad. La agencia advirtió que los primeros despliegues están priorizando las funciones y el valor inmediato por encima de las prácticas establecidas de identidad.

NIST también destacó el uso compartido de credenciales como un problema central. Las credenciales compartidas socavan la rendición de cuentas porque los investigadores no pueden determinar de forma fiable qué persona, servicio o agente realizó una transacción.

El problema se vuelve más agudo cuando los agentes delegan tareas. Un usuario podría pedir a un agente que prepare una presentación comercial. Ese agente podría llamar a otro sistema para obtener datos de cuentas y a un tercer servicio para realizar investigación competitiva.

Cada transferencia crea una decisión de autorización. La empresa debe preservar el usuario de origen, el agente que actúa, el recurso solicitado y el propósito de la solicitud.

Sin esa cadena, los registros pueden mostrar que una cuenta de servicio accedió a una base de datos. No pueden explicar qué agente inició la acción, qué usuario la solicitó o si la acción coincidía con un flujo de trabajo aprobado.

Una identidad de primera clase puede restaurar parte de ese contexto. Cada agente recibe un identificador único en lugar de tomar prestada una cuenta de propósito general. Entonces, las políticas pueden dirigirse al agente específico.

Ese modelo respalda el principio de mínimo privilegio, que limita una identidad al acceso mínimo requerido para la tarea asignada. También permite la revocación sin interrumpir aplicaciones o empleados no relacionados.

Los tokens de corta duración refuerzan el diseño. Un token es una credencial firmada que representa autoridad concedida para un alcance y una duración limitados. Las expiraciones breves reducen el valor de las credenciales robadas.

Las credenciales federadas ofrecen otra mejora. Permiten a una carga de trabajo de confianza solicitar un token sin almacenar un secreto reutilizable en código, archivos de configuración o la memoria de un agente.

La titularidad completa el registro básico. Cada agente de producción necesita una persona designada o un equipo responsable que responda por su propósito, permisos, revisiones y retirada.

El responsable no puede ser simplemente el desarrollador que creó el primer prototipo. La titularidad empresarial importa porque alguien debe decidir si el acceso del agente sigue siendo necesario.

El estado del ciclo de vida también importa. Un agente experimental no debería conservar permisos de producción una vez finalizada una prueba. Un agente sustituido no debería permanecer activo porque su clave API aún funciona.

Esta estructura se parece a la gobernanza de empleados y aplicaciones. Sin embargo, los agentes requieren evaluaciones más frecuentes porque sus herramientas, instrucciones, modelos y tareas delegadas pueden cambiar de forma independiente.

Por ello, las empresas deberían tratar el directorio de identidades como un plano de control, no como una libreta de direcciones estática. El registro inicia la gobernanza, pero la aplicación continua de políticas le da sentido.

Esta distinción también protege la experimentación legítima. Los desarrolladores pueden recibir una vía definida para registrar un agente, en lugar de esperar una gran revisión de seguridad después del despliegue.

Un proceso de registro útil debería capturar el propósito, responsable, entorno, herramientas, clases de datos, permisos y límites operativos esperados. También debería asignar una fecha de expiración o revisión.

Si la vía aprobada es más lenta que crear un agente no registrado, los equipos la evitarán. Por tanto, el programa de identidad debe hacer que la incorporación segura sea más fácil que el despliegue oculto.

Aquí es donde las prácticas de gestión del conocimiento pueden respaldar la gobernanza. Los equipos necesitan registros consultables que conecten decisiones, responsables, requisitos, aprobaciones y cambios posteriores.

Un inventario por sí solo responde dónde se registró un agente. El conocimiento operativo conectado explica por qué existe y si su comportamiento actual sigue correspondiendo a ese propósito.

Las tres preguntas revelan tres fallos diferentes

El descubrimiento, el control de conexiones y la gobernanza de acciones son disciplinas independientes, y superar una no compensa fallar en otra.

“¿Dónde están mis agentes?” evalúa la visibilidad. Los equipos de seguridad no pueden gobernar un agente que aparece únicamente dentro de la cuenta de un desarrollador, el navegador de un empleado o la configuración de un administrador de SaaS.

Un inventario útil debe incluir despliegues autorizados y no autorizados. También debe distinguir los agentes activos de las plantillas, los experimentos abandonados, las instancias deshabilitadas y las aplicaciones comunes que utilizan funciones de IA.

El inventario debería identificar el entorno y el estado operativo de cada agente. Los agentes de desarrollo, pruebas y producción no deberían compartir las mismas premisas de aprobación.

Los equipos de seguridad también deben decidir qué se considera un agente. Un chatbot que solo devuelve texto presenta un perfil de autoridad distinto al de un sistema que invoca herramientas o modifica registros.

La definición debería centrarse en el comportamiento. Si el software selecciona acciones, llama a herramientas conectadas o delega trabajo con una revisión humana limitada, pertenece a la población gobernada.

“¿A qué pueden conectarse?” evalúa el grafo de confianza de la organización. Un grafo de confianza registra las relaciones entre identidades, credenciales, aplicaciones, recursos y servicios delegados.

Ese grafo debería mostrar el acceso directo e indirecto. Un agente podría no tener acceso a una base de datos, pero contar con permiso para llamar a un servicio que puede consultar esa misma base de datos.

Las conexiones entre agentes dificultan el mapeo. Un agente puede transferir contexto o autoridad a otro, creando una cadena que atraviesa plataformas y límites administrativos.

Las empresas deben registrar si cada conexión utiliza acceso permanente o autorización específica por tarea. El acceso permanente sigue disponible entre tareas, lo que aumenta la exposición si el agente se ve comprometido.

“¿Qué pueden hacer?” evalúa el control en tiempo de ejecución. La respuesta no puede ser una lista de ámbitos de API copiados de un registro de aplicación.

Un ámbito puede permitir la modificación de archivos, pero la política debe distinguir entre la edición rutinaria y la eliminación de un repositorio. El mismo permiso técnico puede abarcar acciones con consecuencias empresariales distintas.

La autorización en tiempo de ejecución evalúa una acción propuesta cuando ocurre. Puede considerar al agente actuante, al usuario de origen, la sensibilidad del recurso, la operación solicitada, la ubicación y las señales de riesgo actuales.

Algunas decisiones deben seguir siendo automáticas. Exigir aprobación humana para cada consulta de bajo riesgo eliminaría el valor de productividad que prometen los agentes.

Las acciones de alto impacto merecen una fricción mayor. Los cambios en sistemas de producción, las transferencias de dinero, la divulgación de información regulada y las eliminaciones irreversibles necesitan salvaguardas explícitas.

La aprobación con supervisión humana es una opción. Sitúa a una persona en un punto de decisión definido antes de que el agente complete una acción sensible.

La aprobación debe proporcionar un contexto significativo. Una solicitud que dice “permitir acción” sin indicar el recurso, los datos, el propósito y el efecto esperado se convierte en una casilla ceremonial.

Las organizaciones también necesitan una desactivación fiable. Un interruptor de emergencia debe revocar el acceso activo del agente en todos los sistemas conectados, en lugar de deshabilitar solo su interfaz visible.

Esa capacidad depende de la arquitectura de credenciales. La revocación centralizada funciona mal cuando los agentes usan claves de API dispersas, tokens en caché o credenciales copiadas en servicios externos.

Por tanto, las tres preguntas forman una secuencia. El descubrimiento establece el sujeto, el mapeo de conexiones define el alcance potencial y la gobernanza de acciones controla la autoridad ejercida.

Omitir la secuencia genera una falsa confianza. Una organización puede mantener un directorio completo de agentes y, aun así, dejar a todos los agentes registrados con permisos excesivos.

También puede emitir tokens con ámbitos limitados mientras no detecta agentes creados por empleados. Como alternativa, puede registrar las acciones de los agentes sin conservar suficiente contexto de identidad para atribuirlas.

El valor del marco reside en esos límites de fallo. Cada pregunta ofrece a los auditores y líderes de seguridad una afirmación específica que evaluar, en lugar de una garantía general sobre una “IA responsable”.

Los controles de identidad no pueden decidir si una acción es sensata

Una identidad válida responde quién está actuando, pero no garantiza que el agente haya entendido la solicitud ni elegido una acción segura.

Esta limitación define la disyuntiva central del artículo. Las empresas necesitan controles basados en identidad, pero los agentes siguen siendo menos predecibles que las aplicaciones tradicionales que usan las mismas credenciales.

Un servicio convencional ejecuta código escrito para un flujo de trabajo conocido. Un agente puede interpretar instrucciones, seleccionar herramientas, generar parámetros y ajustar su ruta según la información recibida.

Esa flexibilidad crea valor. También significa que el éxito de la autenticación no puede servir como evidencia de que la siguiente decisión coincide con la intención del usuario.

La inyección de prompts ilustra esta brecha. Un agente puede encontrar instrucciones maliciosas dentro de un documento, correo electrónico, página web o registro recuperado, y tratarlas como parte de su tarea.

El atacante no necesita robar la identidad del agente. Puede intentar manipular a un agente correctamente autenticado para que haga un mal uso de sus permisos legítimos.

OWASP incluye el abuso de identidad y privilegios entre sus riesgos de seguridad de los agentes. La categoría abarca la manipulación de cadenas de delegación, roles heredados, credenciales en caché y contexto del agente.

El uso indebido de herramientas crea otro problema. Un agente puede invocar una herramienta aprobada con argumentos inseguros o en la fase equivocada de un flujo de trabajo.

Los controles de identidad pueden denegar el acceso a una herramienta no aprobada. No pueden determinar de forma independiente si cada llamada permitida respalda el objetivo real del usuario.

Por ello, la arquitectura de seguridad debe tratar al modelo como un componente de decisión no confiable. Los controles deterministas deben permanecer fuera del modelo siempre que haya consecuencias importantes.

Un control determinista sigue reglas explícitas en lugar de generar una respuesta probabilística. Algunos ejemplos son las comprobaciones de permisos, la validación de esquemas, los límites de transacciones y las puertas de aprobación obligatoria.

El motor de políticas debe evaluar lo que propone el agente, sin depender de que el agente se controle a sí mismo. El agente no debe poder reescribir las reglas que controlan su autoridad.

La validación de entradas y salidas sigue siendo importante. Los parámetros de las herramientas deben ajustarse a los esquemas esperados, los límites de recursos, las clasificaciones de datos y los destinos aprobados.

Los controles de red pueden reducir aún más el alcance. Un agente que nunca necesita acceso a internet público no debería recibirlo de forma predeterminada.

Los controles de datos importan porque la identidad no evita la divulgación inapropiada a un destinatario aprobado. Las políticas también deben considerar la sensibilidad de los datos, el propósito y la retención.

La supervisión debe centrarse tanto en el comportamiento como en los inicios de sesión. Una autenticación exitosa seguida de enumeración inusual, descargas masivas o acciones denegadas repetidas merece investigación.

Aquí es donde la afirmación de priorizar la identidad necesita una formulación cuidadosa. La identidad proporciona el ancla para la rendición de cuentas, la revocación y las políticas. No es un sistema completo de seguridad para agentes.

Una plataforma comercial de identidad puede centralizar el registro y los tokens. No puede garantizar que todos los modelos conectados resistan la manipulación o interpreten correctamente objetivos ambiguos.

La neutralidad frente a proveedores también sigue siendo incierta. Los agentes abarcarán Microsoft, Google Cloud, Amazon Web Services, Salesforce, ServiceNow, marcos internos y productos SaaS especializados.

Cada plataforma puede representar a los agentes de manera diferente. La identidad multiplataforma requiere tokens interoperables, claims coherentes, emisores confiables y políticas que sobrevivan a las transferencias.

MCP añade otro límite. Una empresa puede gobernar al agente y, al mismo tiempo, depender de un servidor externo para exponer herramientas con precisión y proteger sus propias credenciales.

Una capa de identidad también necesita protección frente a compromisos. Los directorios centralizados y los servicios de tokens se convierten en objetivos valiosos porque pueden afectar a muchos agentes a la vez.

Las empresas deben separar las responsabilidades administrativas, proteger los cambios de alto privilegio y supervisar modificaciones inusuales de políticas. La gobernanza de agentes no puede descansar en una sola cuenta de consola con privilegios amplios.

Los registros de auditoría merecen el mismo escepticismo. Un gran volumen de eventos no produce automáticamente evidencia útil.

Los investigadores necesitan registros que vinculen la solicitud del usuario, la identidad del agente, los agentes delegados, la herramienta seleccionada, la decisión de autorización, el recurso afectado y el resultado final.

Las políticas de retención deben preservar esa cadena el tiempo suficiente para investigaciones y revisiones regulatorias. Los prompts y resultados sensibles pueden requerir minimización o acceso restringido.

La conclusión correcta es más limitada que el mensaje del proveedor. La identidad es el comienzo de la seguridad de los agentes porque el control necesita un sujeto conocido.

La seguridad sigue requiriendo defensas en capas alrededor de ese sujeto. Esas capas incluyen herramientas restringidas, políticas externas, credenciales protegidas, controles de datos, supervisión y revisión humana.

Microsoft y Okta están convirtiendo el modelo en productos

La idea de priorizar la identidad está pasando del lenguaje de conferencias a directorios, flujos de tokens, sistemas de descubrimiento y controles de revocación.

Microsoft Entra Agent ID ilustra cómo una gran plataforma representa ahora a los agentes de forma directa. Microsoft describe una identidad de agente como un principal de servicio especializado con un identificador único.

Un principal de servicio representa una aplicación o carga de trabajo dentro de un tenant de identidad. La versión para agentes permite que las políticas y los registros distingan al agente de su plano subyacente.

El flujo de autenticación autónoma de Microsoft separa una identidad de agente de los secretos de producción reutilizables. La documentación recomienda identidades administradas o certificados en lugar de secretos de cliente.

Los agentes autónomos pueden solicitar tokens de aplicación para su propia identidad. Los agentes interactivos pueden usar flujos delegados cuando actúan para un usuario autenticado.

Esa diferencia es esencial. Un agente autónomo de informes nocturnos no debería parecer idéntico a un asistente que realiza una acción para un empleado que ha iniciado sesión.

La autorización en nombre de otro preserva la relación con el usuario durante la delegación. El token resultante puede identificar al usuario como sujeto y al agente como actor.

Este diseño proporciona a los servidores de recursos más contexto para la autorización. Un sistema puede preguntar si ese usuario, actuando mediante ese agente, puede realizar la operación solicitada.

Microsoft también documenta cuentas de usuario especiales para agentes destinadas a recursos que requieren objetos similares a usuarios. Estas cuentas pueden admitir buzones de correo o funciones colaborativas sin usar credenciales humanas normales.

Estas cuentas incluyen restricciones. Microsoft afirma que no pueden recibir roles de administrador con privilegios, lo que establece un límite frente a algunas formas de escalada.

Okta persigue el mismo mercado desde una posición de identidad neutral respecto a las plataformas. Su lanzamiento de identidad de agentes en abril describió descubrimiento, registro, conexiones administradas, gobernanza y desactivación.

La empresa afirma que su directorio puede importar agentes de plataformas externas y registrar agentes personalizados. También describe la detección de agentes en la sombra mediante señales de consentimiento OAuth.

Okta enmarca su producto en torno a las mismas tres preguntas repetidas en el artículo invitado de GuidePoint. Esa coincidencia confirma el contexto comercial del artículo.

El mensaje del producto merece escrutinio, pero las categorías de implementación son concretas. Las empresas necesitan directorios para agentes, tokens limitados para conexiones y aplicación de políticas para acciones.

La competencia debería beneficiar a los compradores si las plataformas exponen controles interoperables. El modelo de Microsoft puede encajar en organizaciones centradas en Entra y Microsoft Graph.

Okta enfatiza la gobernanza en múltiples nubes, aplicaciones y marcos de agentes. Los proveedores de nube integrarán naturalmente sus servicios de agentes con sus sistemas existentes de identidad de cargas de trabajo.

El peligro es la fragmentación. Una empresa podría terminar con un inventario de agentes por nube, otro dentro de su proveedor de identidad y varios más en portales de administración SaaS.

Esos inventarios discreparán a menos que la organización defina un proceso canónico de propiedad y ciclo de vida. Las herramientas de descubrimiento deben alimentar ese proceso, en lugar de crear fuentes de verdad paralelas.

La compatibilidad de tokens es otro problema. OAuth puede estandarizar los mecanismos de autorización, pero los proveedores pueden diferir en los claims de identidad, la evidencia de delegación y los controles de políticas en tiempo de ejecución.

La comunicación entre agentes eleva las exigencias. El primer agente puede llevar la autoridad delegada de un usuario, mientras que un agente posterior opera de forma autónoma bajo permisos de aplicación.

La cadena de autorización debe mostrar dónde cambió la autoridad. De lo contrario, una solicitud de usuario aprobada puede convertirse en una acción amplia de máquina sin una escalada visible.

Los equipos de compras deben probar los productos frente a flujos de trabajo reales. Una interfaz de directorio pulida importa menos que si la plataforma puede revocar el acceso en todos los conectores afectados.

También deben probar la capacidad de exportación. Los datos de auditoría deben permanecer accesibles para la respuesta a incidentes, el cumplimiento y la migración, sin depender de una única vista de investigación propietaria.

Los equipos de seguridad deben evitar conceder a una nueva plataforma de agentes acceso sin restricciones solo para mejorar la visibilidad. La arquitectura de descubrimiento necesita su propia revisión de mínimo privilegio.

Por tanto, el mercado avanza hacia la identidad como infraestructura compartida. Los ganadores no se limitarán a registrar agentes.

Preservarán la atribución entre plataformas, reducirán las credenciales permanentes, permitirán una revocación granular y mostrarán las decisiones de política en registros que las herramientas externas puedan evaluar.

Lo que las empresas deben verificar antes de escalar agentes

La próxima etapa se medirá por la evidencia de implementación, no por cuántos proveedores repiten la expresión «identidad de primera clase».

La primera señal es si las empresas elaboran inventarios completos que incluyan agentes ocultos. Un directorio poblado únicamente mediante la incorporación formal dejará fuera las implementaciones de mayor riesgo.

Las organizaciones deberían comparar los registros de identidad con las autorizaciones OAuth, los recursos en la nube, la telemetría del navegador, el uso de API y las configuraciones SaaS. Grandes brechas debilitarían la promesa de un enfoque centrado en la identidad.

La segunda señal es si la autorización de alcance limitado y corta duración sustituye a los secretos estáticos. Los recuentos de migración importan más que la capacidad de una plataforma para emitir tokens modernos para nuevos agentes.

Los equipos deberían identificar los agentes existentes que usan claves de API integradas, cuentas de servicio compartidas y tokens de actualización de larga duración. Después, deberían medir la rapidez con la que desaparecen esas credenciales.

La documentación de Microsoft ofrece a las empresas un punto de referencia técnico. Sus directrices para producción priorizan las credenciales federadas y las identidades administradas frente a los secretos de cliente almacenados.

La tercera señal es si los controles de ejecución resisten la delegación entre plataformas. Esto determinará si la identidad de los agentes se convierte en infraestructura real o en otra categoría de producto aislada.

Una prueba útil comienza con una solicitud humana que activa varios agentes y herramientas. Los investigadores deberían poder reconstruir toda la cadena sin correlacionar manualmente registros no relacionados.

El registro debería identificar a la persona que originó la solicitud, cada agente participante, cada intercambio de tokens, la política aplicada y cada recurso afectado.

La revocación debería funcionar en toda esa misma cadena. Deshabilitar al agente iniciador no debe dejar activas las credenciales delegadas ni las sesiones posteriores.

Las empresas también deberían realizar pruebas adversariales. Un equipo rojo puede insertar instrucciones maliciosas en contenido que se espera que recupere un agente autorizado.

La prueba debería revelar si una política externa bloquea acciones peligrosas después de que el modelo acepte las instrucciones. La identidad por sí sola no producirá ese resultado.

Los líderes empresariales necesitan un marco de decisión para definir una autonomía aceptable. No todos los agentes requieren la misma revisión, porque las consecuencias varían considerablemente.

Un asistente de investigación que lee documentos públicos conlleva riesgos distintos a los de un agente que edita código de producción. Un agente de cuentas por pagar introduce una categoría completamente diferente.

Las revisiones de acceso deberían reflejar esas diferencias. Los agentes de alto impacto necesitan ciclos de certificación más cortos, límites más estrictos, una supervisión más sólida y puntos definidos de aprobación humana.

Los planes de respuesta a incidentes deben incluir a los agentes como actores. Los equipos deberían saber cómo suspender una identidad, invalidar tokens, aislar conectores, conservar registros e identificar los datos afectados.

El plan también debería cubrir a los agentes de terceros comprometidos. La confianza OAuth concedida previamente puede seguir siendo peligrosa incluso cuando el código interno de la empresa nunca fue vulnerado.

Los equipos de seguridad deberían preguntar a los proveedores con qué rapidez divulgan compromisos de conectores y revocan el acceso emitido. El lenguaje contractual debería abordar los registros, las notificaciones y el apoyo a las investigaciones.

Los desarrolladores necesitan estándares más claros en la fase de diseño. Cada agente nuevo debería declarar su propietario, herramientas, clases de datos, patrón de autorización y la consecuencia máxima permitida.

Esa información puede formar parte de un registro interno de flujo de trabajo de IA. Los equipos de producto, seguridad e ingeniería podrán revisar los cambios frente al propósito original.

El artículo de Google News ofrece un punto de control útil, pero la repetición no debe confundirse con una resolución. Los proveedores de identidad han definido el problema con más claridad de la que las empresas han implementado la respuesta.

Las tres preguntas plantean una primera revisión práctica. ¿Puede su organización nombrar a cada agente? ¿Puede mapear cada sistema accesible? ¿Puede limitar y reconstruir cada acción relevante?

Un «sí» necesita pruebas procedentes de directorios, tokens, políticas y registros. Una hoja de cálculo mantenida para una auditoría no demuestra control en tiempo de ejecución.

Empiece con un flujo de trabajo de producción y sígalo desde la intención humana hasta el efecto final. Elimine las credenciales compartidas, limite cada conexión y defina dónde debe detenerse la acción automática.

Después, pruebe la revocación y la reconstrucción bajo presión. Si alguna falla, el agente tiene más autonomía de la que la organización puede explicar de forma segura.

Google News pasará a otro titular. La brecha de identidad persistirá hasta que las empresas puedan vincular cada acción de un agente con una autoridad limitada, una propiedad clara y una política aplicable.