La seguridad de IA de Thales Google Cloud añade controles, pero la autonomía eleva lo que está en juego
Thales amplió su alianza con Google Cloud el 28 de septiembre, incorporando controles de seguridad para agentes de IA pese a las dudas aún sin resolver sobre cuán fiablemente pueden las barreras de protección contener sistemas autónomos. La integración de seguridad de IA de Thales Google Cloud conecta Thales AI Security Fabric con Gemini Enterprise. Se enfoca en las interacciones entre usuarios, agentes, modelos, datos empresariales y herramientas externas.
El anuncio refleja un cambio más amplio en la IA empresarial. Los asistentes generaban principalmente respuestas para que las personas las revisaran. Ahora los agentes pueden seleccionar herramientas, recuperar registros confidenciales, llamar a API y modificar sistemas empresariales. Por tanto, una instrucción maliciosa o un permiso excesivo puede provocar un incidente operativo, no solo una respuesta deficiente.
Google Cloud ya presenta Agent Gateway como un punto de control para las conexiones entre agentes y herramientas. Thales está añadiendo inspección, aplicación de políticas y detección de amenazas en torno a esas conexiones. Esto sitúa a la alianza en el mismo campo de batalla estratégico que Microsoft, Zscaler, Palo Alto Networks y otros proveedores que intentan definir la capa de seguridad para los agentes empresariales.
La cuestión central ya no es si los agentes de IA requieren protección adicional. La orientación gubernamental y la investigación independiente en seguridad han zanjado ese punto. La verdadera pregunta es si una capa integrada de ejecución puede restringir de forma consistente a los agentes sin volverlos demasiado lentos, costosos o limitados como para justificar su despliegue.
Qué cambia con la integración de seguridad de IA de Thales Google Cloud
La alianza acerca la seguridad de los agentes al momento en que un sistema de IA lee datos, elige una herramienta o intenta realizar una acción.
Según el anuncio de seguridad, Thales AI Security Fabric se integrará con Google Cloud Gemini Enterprise. Thales afirma que el sistema combinado puede aplicar visibilidad, gobernanza y políticas de seguridad a las comunicaciones que involucran usuarios, agentes, modelos, herramientas e información empresarial.
La cobertura prevista incluye varias etapas de un flujo de trabajo agéntico. El sistema puede inspeccionar el tráfico que entra en un agente, observar los intercambios entre el agente y su modelo, y supervisar las llamadas a herramientas externas. También busca imponer límites sobre la información a la que un agente puede acceder y las acciones que puede realizar.
Estas distinciones importan porque un agente no es una sesión aislada de un modelo. Es una cadena de decisiones, credenciales, fuentes de datos e interfaces de software. Cada transferencia crea otro punto en el que un atacante, un error de configuración o una decisión poco fiable del modelo puede alterar el resultado.
Thales identifica la inyección de prompts, la filtración de datos, las salidas inseguras, las acciones no autorizadas y la comunicación entre agentes como riesgos clave. La inyección de prompts ocurre cuando instrucciones hostiles incrustadas en contenido manipulan el comportamiento de un modelo. Un correo electrónico, documento, sitio web o respuesta de una herramienta puede contener esas instrucciones sin que el usuario lo advierta.
La respuesta propuesta por la alianza es una capa unificada de aplicación. Thales afirma que su fabric puede detectar amenazas específicas de IA, mantener visibilidad sobre el comportamiento de los agentes y bloquear acciones que infrinjan las políticas de la organización. La empresa también presenta los registros centralizados como apoyo para revisiones de cumplimiento e investigaciones de incidentes.
Consideremos el ejemplo de seguros proporcionado por Thales. Un agente autorizado para ayudar a resolver reclamaciones podría recurrir a información personal procedente de fuentes no aprobadas. Incluso si el cálculo del pago parece razonable, el flujo de trabajo puede generar problemas de privacidad, equidad y cumplimiento.
Un control de ejecución podría examinar la fuente de datos solicitada, el rol asignado al agente y la acción propuesta antes de permitir que el flujo de trabajo continúe. Podría denegar la solicitud, registrar el intento de acceso o requerir aprobación humana. Es un modelo de seguridad distinto de filtrar únicamente el prompt enviado por un usuario.
La integración también se basa en la arquitectura de agentes más amplia de Google Cloud. Su ecosistema de Agent Gateway ofrece conectividad gobernada para el tráfico de usuario a agente, de agente a agente y de agente a herramienta. Google ha descrito la puerta de enlace como un punto de control abierto que puede trabajar con varios proveedores de seguridad.
Por tanto, Thales no está sustituyendo los controles nativos de Google Cloud. Está proporcionando una capa especializada de inspección y aplicación dentro de una arquitectura más amplia. Su valor depende de cuánto contexto adicional pueda analizar y de cuán fiablemente pueda intervenir antes de que una actividad riesgosa alcance un sistema empresarial.
Por qué los agentes de IA necesitan controles más allá de las barreras del modelo
Una respuesta segura del modelo no garantiza un flujo de trabajo seguro cuando el sistema puede tener credenciales y actuar sin revisión humana inmediata.
La seguridad tradicional de la IA generativa suele centrarse en el contenido. Las organizaciones intentan evitar respuestas dañinas, la exposición de datos confidenciales o prompts inapropiados. Estas preocupaciones siguen siendo importantes, pero los agentes introducen otra categoría de riesgo: acciones de software con consecuencias reales.
Un agente puede recibir una instrucción, crear un plan, seleccionar una herramienta y ejecutar una transacción. Podría enviar un mensaje, editar un registro de cliente, aprobar un reembolso, modificar código fuente o iniciar un cambio de infraestructura. Un error puede propagarse antes de que una persona vea el razonamiento intermedio.
Esta diferencia explica por qué la autorización en tiempo de ejecución está adquiriendo un papel central. Una política debería evaluar no solo lo que dice el agente, sino también qué identidad utiliza, qué recurso solicita y si esa acción se ajusta a su tarea asignada. La decisión puede tener que repetirse cada vez que el flujo de trabajo cambia de dirección.
El problema se vuelve más difícil cuando los agentes colaboran. Un agente podría recopilar información mientras otro formula una recomendación y un tercero ejecuta una acción. Un componente comprometido puede transmitir contexto o solicitudes manipulados al resto de la cadena.
Thales afirma que sus controles cubrirán estas interacciones entre agentes. Esa promesa aborda una brecha importante, pero los detalles de implementación determinarán su valor. Los equipos de seguridad necesitan saber cómo se verifican las identidades, cómo se representan los permisos delegados y cómo las políticas acompañan una tarea a través de múltiples agentes.
NIST ha identificado el mismo problema. Su análisis de seguridad de agentes de mayo de 2026 halló un amplio consenso en que los agentes introducen amenazas novedosas. Los participantes también indicaron que las prácticas conocidas de ciberseguridad siguen siendo útiles, pero requieren adaptación para los sistemas de agentes.
La identidad ilustra esa adaptación. Una aplicación convencional suele operar mediante una cuenta de servicio estable con funciones predecibles. Un agente puede elaborar un plan de manera dinámica y elegir entre varias herramientas según un contexto cambiante.
Otorgar a ese agente credenciales amplias lo hace útil, pero aumenta el daño potencial de la manipulación. Restringir de antemano cada permiso reduce el riesgo, pero puede impedir que el agente complete trabajo legítimo. Los equipos de seguridad deben equilibrar una autonomía útil con un radio de impacto estrictamente limitado.
Los registros de auditoría presentan otro desafío. Registrar una llamada a una herramienta no basta si los investigadores no pueden determinar qué usuario inició la tarea, qué información influyó en el agente o por qué una acción recibió autorización. Los registros útiles deben vincular la intención humana, la identidad del agente, el acceso a datos y el cambio resultante en el sistema.
El enfoque de seguridad de IA de Thales Google Cloud aborda este problema mediante visibilidad a lo largo del flujo de trabajo. En principio, una capa compartida puede correlacionar actividad que de otro modo aparece en registros separados de modelos, identidad, API y aplicaciones.
Esa visibilidad puede ayudar a los equipos de operaciones de seguridad a reconocer comportamientos inusuales. Un agente que normalmente lee datos regionales de ventas debería atraer atención si de pronto solicita registros de empleados o un endpoint externo desconocido. El contexto conductual es valioso cuando las reglas estáticas no pueden anticipar cada secuencia válida.
Sin embargo, la visibilidad no es contención. Un panel puede explicar un incidente después de que ocurra el daño. La afirmación más sólida es que las políticas pueden detener la acción insegura en tiempo real, sin bloquear las variaciones legítimas que hacen útiles a los agentes.
La aplicación en tiempo de ejecución se convierte en el principal campo de batalla competitivo
La competencia estratégica enfrenta la seguridad integrada en una plataforma de nube con controles independientes que prometen políticas coherentes entre modelos, agentes y herramientas.
Google Cloud está reuniendo un ecosistema de socios en torno a Agent Gateway en lugar de depender de un único proveedor de seguridad. Entre sus participantes publicados se encuentran Thales, Zscaler, Exabeam, Silverfort, Cisco, CrowdStrike, Palo Alto Networks y otros. Cada proveedor aborda una parte distinta del flujo de trabajo de los agentes.
Thales incorpora la seguridad de aplicaciones y API de Imperva a esta estructura. Su cobertura declarada incluye el tráfico de cliente a agente, los intercambios de agente a modelo y las interacciones con herramientas que utilizan interfaces como Model Context Protocol. MCP es un protocolo que permite a las aplicaciones de IA conectarse a datos externos y capacidades de software.
Este enfoque ofrece flexibilidad a los compradores empresariales. Una empresa puede utilizar la infraestructura de Google y seleccionar controles adicionales que se ajusten a sus operaciones de seguridad existentes. También puede reducir la presión de depender por completo de las salvaguardas proporcionadas por un proveedor de modelos.
La contrapartida es la complejidad. Varios productos pueden inspeccionar el mismo flujo de trabajo desde perspectivas diferentes. Los equipos de seguridad deben decidir qué componente es responsable de la identidad, la protección de datos, el análisis conductual, la autorización y la respuesta ante incidentes.
Los controles superpuestos pueden producir brechas con la misma facilidad que profundidad. Un producto podría aprobar una solicitud según la identidad del agente, mientras otro carece del contexto de la tarea necesario para reconocer un uso indebido. Un tercero podría registrar la llamada a la herramienta sin comprender los datos confidenciales devueltos.
Microsoft está siguiendo una vía más integrada verticalmente. Su estrategia de seguridad para agentes conecta identidad, políticas de acceso, gobernanza de datos y aplicaciones de productividad. Microsoft Entra puede asignar identidades a agentes, mientras que las políticas de Purview gobiernan la información confidencial dentro del entorno de Microsoft.
Ese modelo ofrece una ruta administrativa más clara para las organizaciones ya centradas en los servicios de Microsoft. También plantea las conocidas preocupaciones de dependencia de plataforma. Los controles optimizados para las aplicaciones de un proveedor pueden ofrecer una cobertura menos coherente cuando los flujos de trabajo atraviesan nubes, modelos y herramientas de terceros.
La arquitectura basada en socios de Google convierte la apertura en parte de su propuesta. Sin embargo, la apertura transfiere el trabajo de integración a la plataforma y a sus clientes. Una política solo es útil si sobrevive a cada transferencia y produce una decisión con la rapidez suficiente para el tráfico de producción.
Los proveedores independientes enfrentan un desafío relacionado. Deben demostrar que su capa adicional aporta más que otra consola de supervisión. Los compradores esperarán políticas aplicables, investigaciones utilizables y evidencia de que los controles reducen el riesgo sin interrumpir el trabajo rutinario.
Thales tiene una posición creíble porque Imperva ya opera en torno a aplicaciones web y API. Los flujos de trabajo de agentes utilizan muchas de las mismas interfaces. La inspección de tráfico existente, la gestión de bots y la protección de API pueden proporcionar una base para reconocer clientes y controlar solicitudes.
El comportamiento de los agentes sigue diferenciándose del tráfico convencional de aplicaciones. Un agente válido puede realizar una solicitud de API técnicamente válida con un propósito inaceptable. Detectar esa diferencia exige contexto sobre la intención del usuario, la autoridad delegada, la sensibilidad de los datos y la secuencia de acciones previas.
Ahí es donde la presión competitiva va más allá de la seguridad web establecida. Los proveedores deben interpretar el contexto operativo de un agente sin depender de la propia explicación del agente. Un modelo manipulado puede generar una justificación convincente para una llamada insegura.
Los proveedores de nube también cuentan con una ventaja informativa. Operan el servicio de modelos, el plano de identidad, la red y la plataforma de agentes. Un socio debe recibir suficiente telemetría para tomar decisiones precisas, al tiempo que respeta la privacidad de los clientes y el rendimiento del sistema.
Por ello, la arquitectura más sólida puede ser estratificada. Los controles nativos de la nube pueden imponer una identidad y un aislamiento fundamentales, mientras que los productos especializados inspeccionan el comportamiento de las aplicaciones y el movimiento de datos sensibles. La aprobación humana sigue siendo adecuada para decisiones irreversibles o de alto impacto.
Esta competencia no se decidirá por la lista de funciones más larga. Las empresas evaluarán qué tan bien maneja cada arquitectura los entornos mixtos, las identidades delegadas y el contexto incompleto. También examinarán si los equipos de respuesta a incidentes pueden reconstruir un flujo de trabajo sin tener que unir varios registros incompatibles.
La promesa de seguridad aún necesita evidencia en producción
Thales y Google Cloud describen los puntos de control adecuados, pero el anuncio no demuestra con qué precisión o consistencia funcionan esos controles bajo presión adversaria.
Las empresas no han publicado cifras de despliegue, mediciones de latencia, evaluaciones independientes ni tasas detalladas de falsos positivos en el anuncio. Tampoco identifican casos de clientes que demuestren que la infraestructura integrada detiene ataques en producción.
Esta ausencia no invalida la dirección del producto. Limita lo que puede concluirse a partir del lanzamiento. La integración debe considerarse una arquitectura de seguridad ampliada, no una prueba de que los flujos de trabajo agénticos sean ahora seguros.
La inyección de prompts sigue siendo una prueba exigente. Los resultados de red teaming de NIST de marzo de 2026 describen la inyección indirecta de prompts como el secuestro de agentes. Los atacantes introducen instrucciones hostiles dentro de contenido externo que un agente procesa más adelante.
Estos ataques explotan una ambigüedad básica. Un modelo recibe tanto instrucciones legítimas como información no confiable en formas textuales similares. Debe distinguir los datos que debe analizar de los comandos que debe seguir, incluso cuando el contenido malicioso está diseñado para difuminar esa frontera.
Las políticas en tiempo de ejecución pueden reducir el daño. Una instrucción inyectada podría persuadir a un agente para solicitar registros confidenciales, pero una capa de autorización independiente aún puede denegar esa solicitud. El control no necesita determinar exactamente por qué el modelo tomó la mala decisión.
Esta separación es una de las ideas más sólidas de la alianza. Los límites deterministas sobre el acceso a datos y el uso de herramientas pueden contener fallos que las salvaguardas a nivel de modelo no detectan. Las credenciales de mínimo privilegio y las aprobaciones humanas pueden reducir aún más el impacto.
Sin embargo, el motor de políticas necesita un contexto preciso. Debe saber qué usuario autorizó la tarea, qué propósito cumple el agente y qué recursos son necesarios. Las políticas amplias o mal mantenidas pueden convertir una capa de control técnicamente avanzada en una puerta de acceso permisiva.
Los falsos positivos generan el fallo opuesto. Si un agente se detiene repetidamente para solicitar aprobaciones o pierde acceso a datos rutinarios, los empleados podrían evitar usarlo. Los administradores podrían relajar las políticas hasta que la aplicación deje de proporcionar una protección significativa.
La latencia también importa. Cada paso de inspección añade tiempo de procesamiento. El efecto puede ser moderado en una sola interacción, pero significativo en flujos de trabajo que contienen decenas de solicitudes al modelo y llamadas a herramientas. Las organizaciones necesitan mediciones de despliegues realistas con múltiples agentes.
El cifrado y la privacidad añaden otra tensión. Las herramientas de seguridad necesitan suficiente visibilidad para identificar información sensible e instrucciones maliciosas. Los clientes querrán explicaciones claras sobre qué contenido se inspecciona, dónde se procesa, cuánto tiempo se conserva y quién puede acceder a él.
El problema va más allá de un solo producto. Los riesgos de agentes de OWASP incluyen el secuestro de objetivos, el uso indebido de herramientas, el abuso de identidad, el envenenamiento de memoria, la comunicación insegura entre agentes y los fallos en cascada. Ningún filtro de tráfico individual resuelve todas las categorías.
El envenenamiento de memoria es un ejemplo útil. Un atacante podría introducir información falsa o maliciosa que un agente almacena para usarla posteriormente. Un control en tiempo de ejecución podría inspeccionar la entrada original, pero el efecto dañino puede aparecer días después en un flujo de trabajo diferente.
Los fallos en cascada son igual de difíciles. Un agente puede generar un resultado incorrecto que parece fiable para otro. Cada llamada individual a una herramienta puede cumplir la política, mientras que el flujo de trabajo general avanza hacia un resultado perjudicial.
Por lo tanto, las organizaciones necesitan defensa en profundidad. Deben combinar permisos restringidos, sandboxing, identidades firmadas, memoria protegida, herramientas validadas, supervisión continua y revisión humana. Las pruebas de seguridad deben cubrir flujos de trabajo completos, en lugar de respuestas aisladas del modelo.
La orientación gubernamental refuerza esa postura. La guía de adopción de agentes de Australia recomienda puntos de control humano, supervisión continua, permisos mínimos y múltiples defensas superpuestas. También aconseja aumentar gradualmente la autonomía.
Thales AI Security Fabric puede convertirse en una de esas defensas. El anuncio no justifica tratarlo como todo el programa de seguridad. Los compradores deberían preguntar cómo interactúa con los sistemas de identidad, los controles de desarrollo, la respuesta a incidentes y los procedimientos de aprobación ya establecidos.
Quién enfrenta presión a medida que la seguridad de los agentes entra en el flujo de trabajo
Los proveedores de seguridad, las plataformas en la nube y los compradores empresariales enfrentan ahora presión para convertir la gobernanza de agentes de una política escrita en software aplicable.
Los proveedores de nube enfrentan la expectativa más inmediata. Quieren que los clientes lleven los agentes de los experimentos a las operaciones empresariales, pero la adopción se estanca cuando los equipos jurídicos y de seguridad no pueden definir límites aceptables. Una plataforma que no puede responder preguntas básicas sobre identidad, acceso y auditabilidad tendrá dificultades con despliegues sensibles.
La respuesta de Google Cloud consiste en construir Agent Gateway como un punto común de aplicación y rodearlo de socios especializados. Thales refuerza esa estrategia al abarcar las interacciones de aplicaciones, API, modelos y herramientas mediante una única infraestructura de seguridad.
Thales debe demostrar que este alcance más amplio sigue siendo manejable. Su propuesta de valor depende de ofrecer a los clientes una visión coherente a través de varias capas técnicas. Las políticas fragmentadas o las alertas duplicadas debilitarían el beneficio de la integración.
Los proveedores de seguridad competidores enfrentan presión para demostrar una cobertura igual de amplia. Proteger únicamente los prompts ya no es suficiente. Los compradores necesitan controles para credenciales, ejecución de herramientas, movimiento de datos, memoria, mensajes entre agentes y acciones externas.
Los proveedores de identidad también enfrentan una nueva carga de trabajo. Los agentes necesitan identidades diferenciadas, permisos limitados, propiedad rastreable y ciclos de vida gestionables. Los agentes temporales no deberían dejar credenciales permanentes tras finalizar sus tareas.
Los responsables de aplicaciones cargan con otra responsabilidad. Deben definir qué acciones puede realizar un agente y bajo qué condiciones. Los equipos de seguridad no pueden crear políticas útiles sin aportes operativos de quienes entienden el flujo de trabajo.
Los desarrolladores tendrán que exponer más contexto estructurado. Una capa de seguridad puede tomar mejores decisiones cuando las llamadas a herramientas declaran la tarea, el usuario, el recurso solicitado y el efecto previsto. Los prompts no estructurados por sí solos proporcionan una base débil para la autorización.
Los compradores empresariales deberían resistir la tentación de tratar la adquisición como el final de la gobernanza. Instalar una infraestructura de seguridad no determina una autonomía aceptable. Las organizaciones aún deben clasificar los casos de uso, asignar responsables, definir puntos de escalamiento y probar escenarios de fallo.
Los casos de uso de bajo riesgo ofrecen un punto de partida sensato. Un agente que redacta un informe a partir de documentos internos aprobados tiene un radio de impacto menor que uno que envía mensajes o modifica cuentas de clientes. Los permisos deberían ampliarse solo después de que la evaluación demuestre que el flujo de trabajo sigue controlado.
Las acciones de alto impacto merecen aprobación explícita. Las transferencias financieras, los cambios en producción, las comunicaciones legales, las decisiones de personal y la divulgación de datos sensibles no deberían depender únicamente de la confianza de un modelo. La revisión humana puede ralentizar el flujo de trabajo, pero esa fricción refleja la consecuencia del error.
Los trabajadores del conocimiento deberían prestar atención porque estos controles determinan qué pueden ver y hacer los agentes en el lugar de trabajo. Una mejor seguridad puede permitir que los agentes accedan a información interna útil. Los controles mal diseñados pueden exponer demasiados datos o bloquear el contexto necesario para un trabajo preciso.
Los empleados también necesitarán transparencia. Deben saber cuándo un agente actúa bajo su identidad, a qué registros accedió y si sus resultados desencadenan cambios externos. La automatización oculta dificulta la rendición de cuentas cuando ocurre un incidente.
El cambio más amplio es organizativo. La seguridad de la IA está pasando de ser una tarea de evaluación de modelos a formar parte de la gestión cotidiana de identidades y aplicaciones. Esto incorpora a los agentes en las mismas disciplinas operativas utilizadas para empleados, servicios, proveedores y despliegues de software.
La alianza de seguridad de IA entre Thales y Google Cloud es importante porque hace explícita esa transición. Su éxito dependerá menos del anuncio que de si las empresas pueden aplicar los controles sin crear otra capa de gobernanza desconectada.
Tres señales mostrarán si los controles funcionan
La siguiente prueba será evidencia medible de despliegues, seguida de una identidad interoperable y una evaluación adversaria creíble.
La primera señal es la adopción en producción con resultados divulgados. Thales o Google Cloud deberían publicar ejemplos de clientes que expliquen el flujo de trabajo, los permisos, el comportamiento bloqueado y la sobrecarga operativa. La evidencia útil incluiría precisión de detección, frecuencia de aprobaciones, latencia y resultados de respuesta a incidentes.
Una afirmación vaga de que un cliente desplegó agentes seguros revelará poco. El estudio de caso más sólido mostraría cómo un control detuvo una inyección de prompts realista o una llamada a herramienta no autorizada. También debería explicar con qué frecuencia se interrumpió la actividad legítima.
Si aparece esta evidencia, reforzará la afirmación de que la aplicación de políticas en tiempo de ejecución puede respaldar despliegues prácticos de agentes. Si los clientes siguen sin identificarse y las mediciones permanecen privadas, los compradores deberían considerar la integración prometedora, pero no probada.
La segunda señal es una identidad y autorización más sólidas entre plataformas. NIST ya ha destacado cuestiones relacionadas con la identificación de agentes, la delegación, la auditoría y el no repudio. El mercado necesita formas coherentes de demostrar qué agente está actuando, para quién y con qué autoridad.
La interoperabilidad será importante porque los flujos de trabajo empresariales rara vez permanecen dentro del entorno de un único proveedor. Un agente podría utilizar un modelo de Google, consultar una base de datos de terceros, llamar a una aplicación de Microsoft e invocar una herramienta desarrollada internamente.
Las políticas deben acompañar ese flujo de trabajo sin conceder a una credencial reutilizable un acceso amplio. Una autorización de corta duración vinculada a una tarea específica reduciría el riesgo. Los registros verificables deberían vincular cada acción consecuente tanto con el agente como con la persona o el servicio responsable.
Los avances en los estándares abiertos de identidad reforzarían la estrategia de socios de Google Cloud. La fragmentación continua favorecería a las plataformas estrechamente integradas que controlan una mayor parte de la infraestructura técnica.
La tercera señal son las pruebas adversariales independientes. Thales y Google Cloud deberían probar el sistema combinado frente a la inyección indirecta de prompts, resultados maliciosos de herramientas, abuso de credenciales, envenenamiento de memoria y agentes comprometidos. Las evaluaciones deberían medir la contención, no solo si se detectó un ataque.
Una prueba útil asumiría que el modelo falla. Luego preguntaría si los controles externos evitan la exfiltración de datos o un cambio no autorizado en el sistema. Esto separa las afirmaciones sobre la seguridad del modelo del valor práctico de seguridad de la arquitectura circundante.
Los investigadores independientes también deberían examinar las vías de elusión creadas por los flujos de trabajo multiagente. Una política puede detener una solicitud directa, pero permitir varias acciones aceptables de forma individual que produzcan el mismo resultado prohibido.
El lanzamiento llega en el momento adecuado. Las empresas quieren que los agentes hagan más que resumir información, mientras que los reguladores y los equipos de seguridad exigen una rendición de cuentas más clara. Estas presiones convierten el control en tiempo de ejecución en un requisito, en lugar de una función opcional.
Aun así, la carga de la prueba aumenta con la autonomía. Cuanta más autoridad reciba un agente, más evidencias necesitan los compradores de que las identidades, los permisos, las políticas y los registros de auditoría funcionan conjuntamente bajo ataque.
Las organizaciones que evalúen la integración de seguridad de IA de Thales y Google Cloud deberían comenzar con un flujo de trabajo acotado y un presupuesto de fallos definido. Deben mapear cada herramienta, credencial, fuente de datos y acción irreversible. Después, deberían comprobar si los controles detienen el uso indebido sin abrumar a los usuarios con aprobaciones.
La pregunta decisiva es práctica: ¿puede la alianza convertir la amplia capacidad de un agente en una acción con autorización limitada cada vez que cambia el flujo de trabajo? Las mediciones en producción, las identidades interoperables y las pruebas independientes darán la respuesta.
