A Segurança de IA da Thales no Google Cloud Adiciona Controles, mas a Autonomia Eleva os Riscos

A Thales ampliou sua parceria com o Google Cloud em 28 de setembro, adicionando controles de segurança para agentes de IA apesar das dúvidas ainda não resolvidas sobre o quão confiavelmente as barreiras de proteção podem conter sistemas autônomos. A integração de segurança de IA da Thales no Google Cloud conecta o Thales AI Security Fabric ao Gemini Enterprise. Ela se concentra nas interações entre usuários, agentes, modelos, dados corporativos e ferramentas externas.

O anúncio reflete uma mudança mais ampla na IA empresarial. Assistentes geravam principalmente respostas para revisão humana. Agora, agentes podem selecionar ferramentas, recuperar registros sensíveis, chamar APIs e modificar sistemas de negócios. Portanto, uma instrução maliciosa ou uma permissão excessiva pode resultar em um incidente operacional, e não apenas em uma resposta inadequada.

O Google Cloud já apresenta o Agent Gateway como um ponto de controle para conexões entre agentes e ferramentas. A Thales está adicionando inspeção, aplicação de políticas e detecção de ameaças em torno dessas conexões. Isso coloca a parceria no mesmo campo de batalha estratégico que Microsoft, Zscaler, Palo Alto Networks e outros fornecedores que tentam definir a camada de segurança para agentes empresariais.

A questão central já não é se agentes de IA exigem proteção adicional. Diretrizes governamentais e pesquisas independentes de segurança já resolveram esse ponto. A verdadeira questão é se uma camada integrada em tempo de execução consegue restringir agentes de forma consistente sem torná-los lentos, caros ou limitados demais para justificar sua implantação.

O que muda com a integração de segurança de IA da Thales no Google Cloud

A parceria aproxima a segurança dos agentes do momento em que um sistema de IA lê dados, escolhe uma ferramenta ou tenta executar uma ação.

Segundo o anúncio de segurança, o Thales AI Security Fabric será integrado ao Google Cloud Gemini Enterprise. A Thales afirma que o sistema combinado pode aplicar visibilidade, governança e políticas de segurança às comunicações que envolvem usuários, agentes, modelos, ferramentas e informações corporativas.

A cobertura pretendida inclui várias etapas de um fluxo de trabalho agêntico. O sistema pode inspecionar o tráfego que entra em um agente, observar as trocas entre o agente e seu modelo e monitorar chamadas para ferramentas externas. Também busca impor limites às informações que um agente pode acessar e às ações que pode realizar.

Essas distinções importam porque um agente não é uma única sessão isolada de modelo. Ele é uma cadeia de decisões, credenciais, fontes de dados e interfaces de software. Cada transferência cria outro ponto em que um invasor, um erro de configuração ou uma decisão pouco confiável do modelo pode alterar o resultado.

A Thales identifica injeção de prompt, vazamento de dados, saída insegura, ação não autorizada e comunicação entre agentes como riscos fundamentais. A injeção de prompt ocorre quando instruções hostis incorporadas a conteúdos manipulam o comportamento de um modelo. Um e-mail, documento, site ou resposta de ferramenta pode conter essas instruções sem que o usuário perceba.

A resposta proposta pela parceria é uma camada unificada de aplicação. A Thales afirma que sua plataforma pode detectar ameaças específicas de IA, manter visibilidade sobre o comportamento dos agentes e bloquear ações que violem políticas organizacionais. A empresa também posiciona registros centralizados como suporte para revisões de conformidade e investigações de incidentes.

Considere o exemplo de seguros fornecido pela Thales. Um agente autorizado a ajudar na liquidação de sinistros pode recorrer a informações pessoais fora das fontes aprovadas. Mesmo que o cálculo de pagamento pareça razoável, o fluxo de trabalho pode criar problemas de privacidade, equidade e conformidade.

Um controle em tempo de execução poderia examinar a fonte de dados solicitada, a função atribuída ao agente e a ação proposta antes de permitir que o fluxo continue. Poderia negar a solicitação, registrar a tentativa de acesso ou exigir aprovação humana. Trata-se de um modelo de segurança diferente de filtrar apenas o prompt enviado por um usuário.

A integração também se baseia na arquitetura mais ampla de agentes do Google Cloud. Seu ecossistema de Agent Gateway oferece conectividade governada para o tráfego de usuário para agente, de agente para agente e de agente para ferramenta. O Google descreveu o gateway como um ponto de controle aberto que pode funcionar com diversos provedores de segurança.

Portanto, a Thales não está substituindo os controles nativos do Google Cloud. Ela fornece uma camada especializada de inspeção e aplicação dentro de uma arquitetura mais ampla. O valor depende de quanto contexto adicional ela pode analisar e de quão confiavelmente consegue intervir antes que uma atividade arriscada alcance um sistema de negócios.

Por que agentes de IA precisam de controles além das barreiras dos modelos

Uma resposta segura do modelo não garante um fluxo de trabalho seguro quando o sistema pode manter credenciais e agir sem revisão humana imediata.

A segurança tradicional de IA generativa geralmente se concentra no conteúdo. As organizações tentam evitar respostas nocivas, exposição de dados confidenciais ou prompts inadequados. Essas preocupações continuam importantes, mas os agentes introduzem outra categoria de risco: ações de software com consequências reais.

Um agente pode receber uma instrução, criar um plano, selecionar uma ferramenta e executar uma transação. Ele pode enviar uma mensagem, editar um registro de cliente, aprovar um reembolso, modificar código-fonte ou iniciar uma alteração de infraestrutura. Um erro pode se propagar antes que uma pessoa veja o raciocínio intermediário.

Essa diferença explica por que a autorização em tempo de execução está se tornando central. Uma política deve avaliar não apenas o que o agente diz, mas também qual identidade ele usa, qual recurso solicita e se essa ação corresponde à tarefa atribuída. A decisão pode precisar ser tomada novamente sempre que o fluxo de trabalho mudar de direção.

O problema se torna mais difícil quando agentes colaboram. Um agente pode coletar informações enquanto outro faz uma recomendação e um terceiro executa uma ação. Um componente comprometido pode transmitir contexto ou solicitações manipulados para o restante da cadeia.

A Thales afirma que seus controles abrangerão essas interações entre agentes. Essa promessa aborda uma lacuna importante, mas os detalhes de implementação determinarão seu valor. As equipes de segurança precisam saber como as identidades são verificadas, como permissões delegadas são representadas e como as políticas acompanham uma tarefa por vários agentes.

O NIST identificou o mesmo problema. Sua análise de segurança de agentes, de maio de 2026, constatou amplo consenso de que agentes introduzem novas ameaças. Os respondentes também disseram que práticas conhecidas de cibersegurança continuam úteis, mas exigem adaptação para sistemas de agentes.

A identidade ilustra essa adaptação. Um aplicativo convencional costuma operar por meio de uma conta de serviço estável, com funções previsíveis. Um agente pode montar um plano dinamicamente e escolher entre várias ferramentas com base em um contexto variável.

Conceder credenciais amplas a esse agente o torna útil, mas aumenta os danos causados por manipulação. Restringir antecipadamente todas as permissões reduz o risco, mas pode impedir o agente de concluir tarefas legítimas. As equipes de segurança precisam equilibrar autonomia útil com um raio de impacto rigidamente limitado.

Os registros de auditoria apresentam outro desafio. Registrar uma chamada de ferramenta não basta se os investigadores não conseguem determinar qual usuário iniciou a tarefa, quais informações influenciaram o agente ou por que uma ação recebeu autorização. Registros úteis precisam conectar a intenção humana, a identidade do agente, o acesso aos dados e a alteração resultante no sistema.

A abordagem de segurança de IA da Thales no Google Cloud enfrenta esse problema por meio da visibilidade em todo o fluxo de trabalho. Em princípio, uma camada compartilhada pode correlacionar atividades que, de outra forma, apareceriam em logs separados de modelos, identidade, APIs e aplicações.

Essa visibilidade pode ajudar as equipes de operações de segurança a reconhecer comportamentos incomuns. Um agente que normalmente lê dados regionais de vendas deve atrair atenção se de repente solicitar registros de funcionários ou um endpoint externo desconhecido. O contexto comportamental é valioso quando regras estáticas não conseguem antecipar todas as sequências válidas.

No entanto, visibilidade não é contenção. Um painel pode explicar um incidente depois que o dano ocorre. A afirmação mais forte é que as políticas podem interromper a ação insegura em tempo real, sem bloquear variações legítimas que tornam os agentes úteis.

A aplicação em tempo de execução se torna o principal campo de batalha competitivo

A disputa estratégica ocorre entre a segurança incorporada a uma plataforma de nuvem e controles independentes que prometem políticas consistentes entre modelos, agentes e ferramentas.

O Google Cloud está montando um ecossistema de parceiros em torno do Agent Gateway em vez de depender de um único fornecedor de segurança. Entre os participantes publicados estão Thales, Zscaler, Exabeam, Silverfort, Cisco, CrowdStrike, Palo Alto Networks e outros. Cada fornecedor aborda uma parte diferente do fluxo de trabalho dos agentes.

A Thales incorpora a segurança de aplicações e APIs da Imperva a essa estrutura. Sua cobertura declarada inclui tráfego de cliente para agente, trocas de agente para modelo e interações com ferramentas que usam interfaces como o Model Context Protocol. MCP é um protocolo que permite que aplicações de IA se conectem a dados externos e recursos de software.

Essa abordagem oferece flexibilidade aos compradores empresariais. Uma empresa pode usar a infraestrutura do Google e selecionar controles adicionais compatíveis com suas operações de segurança existentes. Também pode reduzir a pressão para depender inteiramente das proteções fornecidas por um provedor de modelos.

A contrapartida é a complexidade. Vários produtos podem inspecionar o mesmo fluxo de trabalho sob perspectivas diferentes. As equipes de segurança precisam decidir qual componente é responsável por identidade, proteção de dados, análise comportamental, autorização e resposta a incidentes.

Controles sobrepostos podem produzir lacunas com a mesma facilidade que profundidade. Um produto pode aprovar uma solicitação com base na identidade do agente, enquanto outro não tem o contexto da tarefa necessário para reconhecer o uso indevido. Um terceiro pode registrar a chamada de ferramenta sem compreender os dados sensíveis retornados.

A Microsoft segue uma rota mais verticalmente integrada. Sua estratégia de segurança de agentes conecta identidade, política de acesso, governança de dados e aplicações de produtividade. O Microsoft Entra pode atribuir identidades a agentes, enquanto as políticas do Purview governam informações sensíveis no ambiente Microsoft.

Esse modelo oferece um caminho administrativo mais claro para organizações já centradas nos serviços da Microsoft. Também levanta preocupações conhecidas sobre dependência de plataforma. Controles otimizados para as aplicações de um fornecedor podem oferecer cobertura menos consistente quando os fluxos de trabalho atravessam nuvens, modelos e ferramentas de terceiros.

A arquitetura baseada em parceiros do Google torna a abertura parte de sua proposta. No entanto, a abertura transfere o trabalho de integração para a plataforma e seus clientes. Uma política só é útil se sobreviver a cada transferência e produzir uma decisão com rapidez suficiente para o tráfego de produção.

Fornecedores independentes enfrentam um desafio relacionado. Eles precisam provar que sua camada adicional fornece mais do que outro console de monitoramento. Os compradores esperarão políticas aplicáveis, investigações utilizáveis e evidências de que os controles reduzem o risco sem interromper o trabalho rotineiro.

A Thales ocupa uma posição confiável porque a Imperva já atua em torno de aplicações web e APIs. Os fluxos de trabalho dos agentes usam muitas das mesmas interfaces. A inspeção de tráfego existente, a gestão de bots e a proteção de APIs podem fornecer uma base para reconhecer clientes e controlar solicitações.

O comportamento dos agentes ainda difere do tráfego convencional de aplicações. Um agente válido pode fazer uma solicitação de API tecnicamente válida com uma finalidade inaceitável. Detectar essa distinção exige contexto sobre a intenção do usuário, a autoridade delegada, a sensibilidade dos dados e a sequência de ações anteriores.

É nesse ponto que a pressão competitiva vai além da segurança web estabelecida. Os fornecedores precisam interpretar o contexto operacional de um agente sem depender da própria explicação do agente. Um modelo manipulado pode produzir uma justificativa convincente para uma chamada insegura.

Os provedores de nuvem também têm uma vantagem informacional. Eles operam o serviço de modelo, o plano de identidade, a rede e a plataforma de agentes. Um parceiro deve receber telemetria suficiente para tomar decisões precisas, respeitando ao mesmo tempo a privacidade do cliente e o desempenho do sistema.

A arquitetura mais robusta pode, portanto, ser em camadas. Os controles nativos da nuvem podem impor identidade e isolamento fundamentais, enquanto produtos especializados inspecionam o comportamento das aplicações e a movimentação de dados sensíveis. A aprovação humana continua apropriada para decisões irreversíveis ou de alto impacto.

Essa disputa não será decidida pela lista de recursos mais longa. As empresas avaliarão quão bem cada arquitetura lida com ambientes mistos, identidades delegadas e contexto incompleto. Elas também examinarão se as equipes de resposta a incidentes conseguem reconstruir um fluxo de trabalho sem ter de reunir vários logs incompatíveis.

A Promessa de Segurança Ainda Precisa de Evidências em Produção

Thales e Google Cloud descrevem os pontos de controle corretos, mas o anúncio não estabelece com que precisão ou consistência esses controles funcionam sob pressão adversarial.

As empresas não publicaram números de implantação, medições de latência, avaliações independentes ou taxas detalhadas de falsos positivos no anúncio. Também não identificam estudos de caso de clientes que demonstrem a malha integrada bloqueando ataques em produção.

Essa ausência não invalida a direção do produto. Ela limita o que pode ser concluído a partir do lançamento. A integração deve ser tratada como uma arquitetura de segurança ampliada, e não como prova de que os fluxos de trabalho agentivos agora são seguros.

A injeção de prompt continua sendo um teste exigente. Os resultados de red teaming do NIST de março de 2026 descrevem a injeção indireta de prompt como sequestro de agentes. Os invasores inserem instruções hostis em conteúdo externo que um agente processa posteriormente.

Esses ataques exploram uma ambiguidade básica. Um modelo recebe tanto instruções legítimas quanto informações não confiáveis em formatos textuais semelhantes. Ele precisa distinguir os dados que deve analisar dos comandos que deve seguir, mesmo quando o conteúdo malicioso é criado para tornar essa fronteira difusa.

Políticas em tempo de execução podem reduzir os danos. Uma instrução injetada pode persuadir um agente a solicitar registros confidenciais, mas uma camada de autorização separada ainda pode negar essa solicitação. O controle não precisa determinar exatamente por que o modelo tomou a decisão equivocada.

Essa separação é uma das ideias mais fortes da parceria. Limites determinísticos de acesso a dados e uso de ferramentas podem conter falhas que as proteções no nível do modelo não detectam. Credenciais de privilégio mínimo e aprovações humanas podem reduzir ainda mais o impacto.

Ainda assim, o mecanismo de políticas precisa de contexto preciso. Ele deve saber qual usuário autorizou a tarefa, qual finalidade o agente atende e quais recursos são necessários. Políticas amplas ou mal mantidas podem transformar uma camada de controle tecnicamente avançada em um gateway permissivo.

Os falsos positivos criam a falha oposta. Se um agente interrompe repetidamente o trabalho para pedir aprovações ou perde acesso a dados rotineiros, os funcionários podem evitá-lo. Administradores podem flexibilizar as políticas até que a aplicação deixe de oferecer proteção significativa.

A latência também importa. Cada etapa de inspeção adiciona tempo de processamento. O efeito pode ser modesto em uma única interação, mas significativo em fluxos de trabalho que contêm dezenas de solicitações ao modelo e chamadas de ferramentas. As organizações precisam de medições de implantações realistas com múltiplos agentes.

Criptografia e privacidade acrescentam outra tensão. As ferramentas de segurança precisam de visibilidade suficiente para identificar informações sensíveis e instruções maliciosas. Os clientes vão querer explicações claras sobre qual conteúdo é inspecionado, onde ele é processado, por quanto tempo é retido e quem pode acessá-lo.

O problema vai além de um único produto. Os riscos de agentes da OWASP incluem sequestro de objetivos, uso indevido de ferramentas, abuso de identidade, envenenamento de memória, comunicação insegura entre agentes e falhas em cascata. Nenhum filtro único de tráfego resolve todas as categorias.

O envenenamento de memória é um exemplo útil. Um invasor pode inserir informações falsas ou maliciosas que um agente armazena para uso posterior. Um controle em tempo de execução poderia inspecionar a entrada original, mas o efeito prejudicial pode surgir dias depois em um fluxo de trabalho diferente.

As falhas em cascata são igualmente difíceis. Um agente pode gerar um resultado incorreto que parece confiável para outro. Cada chamada individual de ferramenta pode atender à política, enquanto o fluxo de trabalho geral avança rumo a um resultado prejudicial.

Portanto, as organizações precisam de defesa em profundidade. Elas devem combinar permissões restritas, sandboxing, identidades assinadas, memória protegida, ferramentas validadas, monitoramento contínuo e revisão humana. Os testes de segurança precisam abranger fluxos de trabalho completos, em vez de respostas isoladas de modelos.

As orientações governamentais reforçam essa posição. A orientação australiana sobre adoção de agentes recomenda pontos de controle humanos, monitoramento contínuo, permissões mínimas e múltiplas defesas sobrepostas. Ela também aconselha aumentos graduais de autonomia.

O Thales AI Security Fabric pode se tornar uma dessas defesas. O anúncio não justifica tratá-lo como todo o programa de segurança. Os compradores devem perguntar como ele interage com os sistemas de identidade, controles de desenvolvimento, resposta a incidentes e procedimentos de aprovação já existentes.

Quem Enfrenta Pressão à Medida que a Segurança de Agentes Entra no Fluxo de Trabalho

Fornecedores de segurança, plataformas de nuvem e compradores empresariais agora enfrentam pressão para transformar a governança de agentes de uma política escrita em software aplicável.

Os provedores de nuvem enfrentam a expectativa mais imediata. Eles querem que os clientes levem agentes de experimentos para operações de negócios, mas a adoção para quando as equipes jurídicas e de segurança não conseguem definir limites aceitáveis. Uma plataforma que não consegue responder a perguntas básicas sobre identidade, acesso e auditabilidade terá dificuldades em implantações sensíveis.

A resposta do Google Cloud é construir o Agent Gateway como um ponto comum de aplicação e cercá-lo de parceiros especializados. A Thales fortalece essa estratégia ao cobrir interações de aplicações, APIs, modelos e ferramentas por meio de uma única malha de segurança.

A Thales precisa mostrar que esse escopo mais amplo continua administrável. Sua proposta de valor depende de oferecer aos clientes uma visão coerente de várias camadas técnicas. Políticas fragmentadas ou alertas duplicados enfraqueceriam o benefício da integração.

Fornecedores concorrentes de segurança enfrentam pressão para demonstrar cobertura igualmente ampla. Proteger apenas prompts já não é suficiente. Os compradores precisam de controles para credenciais, execução de ferramentas, movimentação de dados, memória, mensagens entre agentes e ações externas.

Os provedores de identidade também enfrentam uma nova carga de trabalho. Os agentes precisam de identidades distintas, permissões limitadas, propriedade rastreável e ciclos de vida administráveis. Agentes temporários não devem deixar credenciais permanentes após o fim de suas tarefas.

Os responsáveis pelas aplicações carregam outro ônus. Eles devem definir quais ações um agente pode executar e em quais condições. As equipes de segurança não podem criar políticas úteis sem a contribuição operacional das pessoas que entendem o fluxo de trabalho.

Os desenvolvedores precisarão expor mais contexto estruturado. Uma camada de segurança pode tomar decisões melhores quando as chamadas de ferramentas declaram a tarefa, o usuário, o recurso solicitado e o efeito pretendido. Prompts não estruturados, por si só, fornecem uma base fraca para autorização.

Os compradores empresariais devem resistir à tentação de tratar a aquisição como o fim da governança. Instalar uma malha de segurança não determina uma autonomia aceitável. As organizações ainda precisam classificar casos de uso, designar responsáveis, definir pontos de escalonamento e testar cenários de falha.

Casos de uso de baixo risco oferecem um ponto de partida sensato. Um agente que redige um relatório a partir de documentos internos aprovados tem um raio de impacto menor do que outro que envia mensagens ou modifica contas de clientes. As permissões devem se expandir apenas depois que a avaliação mostrar que o fluxo de trabalho permanece controlado.

Ações de alto impacto merecem aprovação explícita. Transferências financeiras, mudanças em produção, comunicações jurídicas, decisões de pessoal e divulgação de dados sensíveis não devem depender apenas da confiança de um modelo. A revisão humana pode tornar o fluxo de trabalho mais lento, mas essa fricção reflete a consequência do erro.

Profissionais do conhecimento devem se importar porque esses controles moldam o que os agentes no ambiente de trabalho podem ver e fazer. Uma segurança melhor pode permitir que agentes acessem informações internas úteis. Controles mal projetados podem expor dados demais ou bloquear o contexto necessário para um trabalho preciso.

Os funcionários também precisarão de transparência. Eles devem saber quando um agente atua sob sua identidade, quais registros acessou e se seus resultados desencadeiam mudanças externas. A automação oculta dificulta a responsabilização quando ocorre um incidente.

A mudança maior é organizacional. A segurança de IA está passando de uma tarefa de avaliação de modelos para a gestão cotidiana de identidades e aplicações. Isso submete os agentes às mesmas disciplinas operacionais usadas para funcionários, serviços, fornecedores e implantações de software.

A parceria de segurança de IA entre Thales e Google Cloud é importante porque torna essa transição explícita. Seu sucesso dependerá menos do anúncio do que de a capacidade das empresas de aplicar os controles sem criar outra camada desconectada de governança.

Três Sinais Mostrarão se os Controles Funcionam

O próximo teste é evidência mensurável de implantação, seguida de identidade interoperável e avaliação adversarial confiável.

O primeiro sinal é a adoção em produção com resultados divulgados. A Thales ou o Google Cloud devem publicar exemplos de clientes que expliquem o fluxo de trabalho, as permissões, o comportamento bloqueado e a sobrecarga operacional. Evidências úteis incluiriam precisão de detecção, frequência de aprovações, latência e resultados de resposta a incidentes.

Uma declaração vaga de que um cliente implantou agentes seguros revelará pouco. O estudo de caso mais forte mostraria como um controle bloqueou uma injeção de prompt realista ou uma chamada de ferramenta não autorizada. Ele também deveria explicar com que frequência a atividade legítima foi interrompida.

Se essas evidências surgirem, elas fortalecerão a alegação de que a aplicação de controles em tempo de execução pode apoiar implantações práticas de agentes. Se os clientes continuarem sem identificação e as medições permanecerem privadas, os compradores devem tratar a integração como promissora, mas não comprovada.

O segundo sinal é uma identidade e autorização mais fortes entre plataformas. O NIST já destacou questões envolvendo identificação de agentes, delegação, auditoria e não repúdio. O mercado precisa de formas consistentes de provar qual agente está agindo, em nome de quem e com qual autoridade.

A interoperabilidade será importante porque os fluxos de trabalho empresariais raramente permanecem dentro do ambiente de um único fornecedor. Um agente pode usar um modelo do Google, consultar um banco de dados de terceiros, chamar uma aplicação da Microsoft e invocar uma ferramenta desenvolvida internamente.

As políticas precisam acompanhar esse fluxo de trabalho sem conceder a uma credencial reutilizável acesso amplo. Uma autorização de curta duração vinculada a uma tarefa específica reduziria o risco. Registros verificáveis devem conectar cada ação consequente tanto ao agente quanto ao humano ou serviço responsável.

O progresso em padrões abertos de identidade fortaleceria a estratégia de parceiros do Google Cloud. A fragmentação contínua favoreceria plataformas fortemente integradas que controlam uma parcela maior da pilha tecnológica.

O terceiro sinal é a realização de testes adversariais independentes. Thales e Google Cloud devem testar o sistema combinado contra injeção indireta de prompts, saída maliciosa de ferramentas, abuso de credenciais, envenenamento de memória e agentes comprometidos. As avaliações devem medir a contenção, e não apenas se um ataque foi detectado.

Um teste útil partiria do pressuposto de que o modelo falha. Em seguida, verificaria se controles externos impedem a exfiltração de dados ou uma alteração não autorizada no sistema. Isso separa as alegações de segurança do modelo do valor prático de segurança da arquitetura ao redor.

Pesquisadores independentes também devem examinar formas de contornar controles criadas por fluxos de trabalho com múltiplos agentes. Uma política pode bloquear uma solicitação direta, mas permitir várias ações individualmente aceitáveis que produzem o mesmo resultado proibido.

O lançamento chega no momento certo. As empresas querem que os agentes façam mais do que resumir informações, enquanto reguladores e equipes de segurança exigem uma responsabilização mais clara. Essas pressões tornam o controle em tempo de execução um requisito, e não um recurso opcional.

Ainda assim, o ônus da prova aumenta com a autonomia. Quanto mais autoridade um agente recebe, mais evidências os compradores precisam de que identidades, permissões, políticas e registros de auditoria funcionam em conjunto sob ataque.

Organizações que avaliam a integração de segurança de IA entre Thales e Google Cloud devem começar com um fluxo de trabalho limitado e um orçamento de falhas definido. Mapeie todas as ferramentas, credenciais, fontes de dados e ações irreversíveis. Em seguida, teste se os controles impedem o uso indevido sem sobrecarregar os usuários com aprovações.

A questão decisiva é prática: a parceria consegue transformar a ampla capacidade de um agente em uma ação estritamente autorizada, sempre que o fluxo de trabalho muda? Métricas de produção, identidades interoperáveis e testes independentes fornecerão a resposta.