Como proteger a empresa agêntica no Google Cloud

As principais preocupações citadas pelas empresas são a exposição de dados sensíveis (52%) e a conformidade regulatória (50%) (Fonte: Cloud Security Alliance, dezembro de 2025). No entanto, a transição empresarial para a IA agêntica autônoma introduz novos vetores críticos:

• O tempo médio para explorar vulnerabilidades caiu para menos sete dias, o que significa que as vulnerabilidades de dia zero são exploradas rotineiramente antes que os patches de software sejam publicados (Fonte: Relatório M-Trends da Mandiant)
• As identidades de cargas de trabalho não humanas agora superam as identidades humanas em 82 vezes em ambientes de nuvem modernos (Fonte: Google Cloud NEXT 2026)
• 42% dos agentes de IA corporativos ativos têm privilégios sensíveis e excessivamente permissivos (Fonte: Google Cloud NEXT 2026)
• Para se defender contra esses ataques na velocidade da máquina, é preciso proteger todo o conjunto de soluções de IA (infraestrutura, dados, modelos e agentes autônomos) ao mesmo tempo

A IA sombra acontece quando desenvolvedores ou unidades de negócios implantam modelos não autorizados, APIs externas ou habilidades de agentes de terceiros sem a revisão da TI:

• Mais de 15% das habilidades de agentes disponíveis em marketplaces públicos são mal-intencionadas (Fonte: Google Cloud NEXT 2026).
• 68% das organizações executam modelos auto-hospedados integrados a softwares de terceiros, muitas vezes sem perceber (Fonte: Wiz, State of AI in the Cloud 2026)
• Para detectar a IA sombra, as organizações usam o Wiz AI-APP, que se conecta via API em 15 minutos para gerar uma lista de materiais de IA (AI-BOM) dinâmica, combinada com o Gemini, que oferece um Agent Registry centralizado para catalogar e controlar todos os agentes ativos, servidores MCP personalizados e ferramentas externas

Não. Embora a falta de habilidades seja um desafio reconhecido, as organizações com governança formal de IA têm 3 vezes mais chances de treinar a equipe em ferramentas de segurança de IA(Fonte: Cloud Security Alliance, dezembro de 2025), e as equipes de segurança agora lideram a proteção de IA em 53% das organizações (Fonte: Cloud Security Alliance, dezembro de 2025). O Google Cloud transfere a segurança diretamente para a estrutura da plataforma: as configurações básicas são automatizadas pelo Enterprise Foundations Blueprint, as interações de ambiente de execução são governadas nativamente pelo Model Armor e os agentes autônomos de localização e correção, como o CodeMender e o Wiz Green Agent, testam e geram patches de código idiomáticos diretamente nos fluxos de trabalho dos desenvolvedores.

Para proteger agentes autônomos, é preciso ir além das contas de serviço estáticas. Como as identidades não humanas superam as humanas em 82 vezes e 42% dos agentes ativos têm privilégios excessivos (Fonte: Google Cloud NEXT 2026), o Google Cloud estabelece uma pilha de segurança que prioriza a identidade:

• Identidade do Agente: um tipo de principal dedicado e de primeira classe, diferente dos usuários humanos, que fornece credenciais de ambiente de execução criptográficas, fortemente atestadas e vinculadas ao ciclo de vida
• Controles de privilégio mínimo: os recursos são restritos usando o Privileged Access Manager (PAM) para acesso Just-In-Time (JIT), eliminando privilégios permanentes
• Limite de acesso de principal (PAB, na sigla em inglês): impõe limites de recursos rígidos e protetores para restringir o raio de impacto máximo das identidades de agentes em execução

O framework de IA segura (SAIF, na sigla em inglês) é a arquitetura conceitual do Google para a implantação segura e responsável da IA. Ele traduz os princípios de segurança de confiança zero em sistemas de IA, exigindo a procedência do build do SLSA nível 3 validada pela autorização binária, verificações automatizadas de política como código (PaC) no Cloud Build e detecção contínua de ameaças. Em ambientes agênticos, o SAIF é operacionalizado pelo ciclo de vida de 4 estágios: arquitetar, inventariar, interceptar e defender (Fonte: e-book Secure AI Innovation, Capítulo 6)

O Protocolo de Contexto de Modelo (MCP, na sigla em inglês) é um padrão aberto que permite que agentes de IA autônomos se conectem a fontes de dados externas, ferramentas corporativas e APIs de negócios. No entanto, integrações personalizadas de MCP não gerenciadas introduzem endpoints arriscados e não verificados na produção. O Google Cloud protege as ferramentas agênticas com os servidores MCP gerenciados do Google Cloud (como o servidor MCP para BigQuery). Isso padroniza a forma como os agentes interagem com os bancos de dados corporativos, aplicando permissões do IAM estritamente definidas e auditáveis e substituindo wrappers de API personalizados por conexões reforçadas e gerenciadas pela empresa (Fonte: Google Cloud NEXT 2026).

O vazamento de sessão ocorre em ambientes multilocatários ou multiagentes quando o contexto de conversa particular, os tokens de usuário ou os dados corporativos sensíveis da sessão de um usuário vazam acidentalmente para a sessão de outro. O Google Cloud elimina o vazamento de sessões com o Kit de Desenvolvimento de Agente (ADK) (Fonte: eBook Secure AI Innovation, Capítulo 2):

• Isolamento de locatários: o ADK aplica limites rígidos de usuários e isolamento de execução usando primitivos nativos session_id e user_id
• Segregação de credenciais: os tokens de autenticação downstream são isolados para que um agente não possa transferir credenciais ou o estado da conversa entre diferentes sessões de usuário

Sim. As organizações adotam estratégias multimodelo, executando em média 2,6 modelos diferentes(Fonte: Cloud Security Alliance, dezembro de 2025). O Google Cloud oferece suporte à governança de vários modelos usando o Gemini como um plano de controle de execução centralizado. As proteções unificadas de ambiente de execução, incluindo o Model Armor para higienização de comandos e as Políticas de governança semântica, são aplicadas de forma consistente em modelos próprios do Gemini, modelos de código aberto e modelos de terceiros. Para espaços multicloud (incluindo AWS Bedrock, Databricks e código aberto não gerenciado), o gráfico de segurança Wiz mapeia vulnerabilidades e caminhos de ataque em todos os provedores de nuvem (Fonte: Google Cloud NEXT 2026).

Não. O CodeMender foi desenvolvido com uma arquitetura de execução local com foco em privacidade (Fonte: eBook Secure AI Innovation, Capítulo 4):

• Processamento de CLI local: o mecanismo de verificação do CodeMender opera por uma interface de linha de comando local diretamente no ambiente seguro do desenvolvedor
• Sandbox isolado: os builds de aplicativos e as verificações de explorações ativas são executadas em um sandbox isolado na sua própria infraestrutura
• Zero treinamento de modelos: seu código-fonte proprietário e sua propriedade intelectual permanecem estritamente protegidos e nunca são usados para treinar modelos de fundação do Google. Os desenvolvedores mantêm supervisão completa com fluxos de trabalho padrão de IDE/CLI e portões de aprovação human-in-the-loop (HITL) antes que qualquer patch de código seja mesclado

Para executar uma lógica de negócios de alto risco sem expor a infraestrutura principal, as empresas usam a arquitetura de referência Traga seu próprio contêiner (BYOC):

• Sandbox de contêineres: agentes autônomos de alto risco (como contatos de inventário ou logística) são implantados em contêineres isolados no Cloud Run
• Separação estrita de permissões: as permissões de infraestrutura no momento da implantação são estritamente separadas das permissões de execução no ambiente de execução
• Portões de human-in-the-loop (HITL): o Kit de Desenvolvimento de Agente (ADK) introduz pontos de pausa programados em que ações de alto risco (como iniciar APIs de fulfillment ou desembolsos financeiros) exigem aprovação humana explícita antes da execução

O Google Cloud aplica uma solução de ambiente de execução com proteção dupla para limpar payloads sem adicionar latência:

1. Controle de acesso (limites do IAM): aplicado de forma nativa no Gateway de Agente usando o Identity-Aware Proxy (IAP) para verificar criptograficamente os IDs digitais do autor da chamada antes de rotear as conexões
2. Controle de intenção (limites semânticos): o Model Armor opera como um proxy inline que analisa as interações de usuários, agentes e modelos em tempo real para neutralizar injeções de comandos, evitar jailbreaks e ocultar PIIs sensíveis Na camada do aplicativo, o Kit de Desenvolvimento de Agente (ADK) aplica a validação de entrada (como BeforeToolCallback) para impedir injeções de SQL indiretas em tabelas do BigQuery

Para evitar o vazamento de dados, é preciso ter uma defesa em profundidade nas camadas de rede, aplicativo e modelo:

• Topologias privadas: as cargas de trabalho de IA são executadas em VPCs compartilhadas gerenciadas centralmente e isoladas pelo VPC Service Controls (VPC-SC), criando um macroperímetro em todo o ecossistema de agentes
• Sanitização inline: o Model Armor limpa e oculta automaticamente dados do cliente sensíveis e PII de entradas de comandos e saídas do modelo
• Autenticação sem token: o gerenciador de autenticação de Identidade do Agente lida com handshakes OAuth downstream complexos em nome dos usuários, transmitindo tokens com segurança sem expor credenciais brutas ao agente
• Computação confidencial: protege os dados em uso criptografando a memória durante o processamento ativo do modelo