Notas do Cloud Next 2026: Identidade para Agentes de IA é o Problema Antigo de Chapéu Novo

Passei três dias em Las Vegas no Google Cloud Next 2026. Fui de propósito — de tempos em tempos é preciso entrar na mesma sala que todo mundo que está construindo o que você está construindo, só para confirmar que está apontado para a direção certa. Este é o primeiro de cinco posts sobre as palestras que assisti. Fui humilde. Esperava ouvir refinamentos, não revelações. Foi o que recebi, na maior parte. E é justamente esse o ponto.

A sessão que ancorou minha semana foi a palestra do William, do Emilio e do Felipe, do time Security Transformations do Google. O assunto: controles de identidade para agentes de IA. Quero ser honesto desde o começo — eles não disseram nada que eu já não tivesse visto, de alguma forma. O que fizeram foi colocar tudo em ordem. Para um problema dessa bagunça, articulação ordenada é, por si só, uma contribuição.

Três Eras, Cada Uma Herdando a Anterior

O enquadramento de abertura foi uma linha do tempo de identidade em três eras.

A primeira era foi a dos humanos. Identidade significava usuário e senha, depois diretório, depois SSO e MFA. RBAC amadureceu por cima. Resolvemos provisionamento, desprovisionamento, auditoria. Quando a maioria das empresas chegou ao fim dessa era, os controles eram genuinamente bons — para humanos.

A segunda era foi a da identidade programática. Contas de serviço, chaves de API, identidades de máquina. A história honesta é que estendemos controles humanos a atores não-humanos e descobrimos que o encaixe era ruim. Contas de serviço herdam roles pensadas para pessoas. Suas credenciais ficam em repositórios, em variáveis de CI, em laptops de desenvolvedores. Rotação, no melhor dos casos, é um ritual trimestral. RBAC funciona na forma, mas não no espírito, porque o princípio do menor privilégio depende de alguém escopá-lo de fato, e ninguém está lendo o código que usa a chave.

A terceira era é a dos agentes. O argumento da palestra — e acho que está certo — é que estamos prestes a repetir o erro. Vamos estender os controles de conta de serviço aos agentes e descobrir que o encaixe é ainda pior. Agentes não são determinísticos. Eles sintetizam chamadas. Raciocinam sobre o que invocar a seguir. Conseguem usar ferramentas que não foram antecipadas. Os controles que funcionavam para “este script chama está API a cada seis horas” não funcionam para “este agente decide qual API chamar com base na conversa que está acontecendo agora”.

As eras são úteis porque tornam a herança visível. Cada nova era reusou os controles da anterior e rapidamente os esgotou. O erro não é um problema de fornecedor. É um reflexo geracional. Reconhecer esse reflexo é o primeiro pedaço de trabalho.

Cinco Pilares de Governança de Identidade de Agentes

O meio da palestra foi um inventário de onde a maioria das empresas hoje não tem nada no lugar. Cinco pilares:

Visibilidade. Você sabe quais agentes existem? Onde rodam? A quais workloads pertencem? A maioria dos times com quem converso descobre o inventário de agentes do mesmo jeito que descobre shadow IT — por acidente, numa auditoria. O pilar é necessário porque tudo o que vem depois presume que você sabe quem é o elenco.

Autenticação e autorização. RBAC sozinho não basta; a palestra puxou ABAC ao lado. Controle de acesso baseado em atributos adiciona contexto — qual agente, qual tarefa, qual classificação de dado, qual horário, qual segmento de rede. O ponto não é que ABAC substitua RBAC. O ponto é que RBAC foi construído em torno de atribuições estáveis e de mudança lenta, e agentes precisam de decisões tomadas com atributos que mudam por chamada.

Proteção de dados do cliente. Este pilar colapsa duas coisas: o dado que o agente lê e o dado que o agente escreve de volta. A assimetria importa. Um agente que lê amplo e escreve estreito é risco de vazamento. Um agente que lê estreito e escreve amplo é risco de corrupção. Trate como controles separados, não como um só.

Fronteira de integração. Onde termina o agente e começa o resto do sistema? Na prática, a superfície de integração é onde a maioria dos incidentes acontece — não dentro do agente, mas nas bordas onde ele chama SaaS externo, APIs internas ou ferramentas de terceiros. A fronteira precisa do próprio portão.

Logging e monitoramento. Parece óbvio. Não está acontecendo. A maioria dos deploys de agentes registra o que o desenvolvedor pensou em registrar quando ligou a integração. A história de auditoria desmorona na primeira vez que alguém pergunta “quem disparou está chamada, em nome de quem, com qual contexto de prompt”. Logs precisam ser desenhados contra a pergunta que você fará no incidente, não contra a pergunta que coube quando você configurou o SDK.

Quero ser honesto — nenhuma dessas é uma categoria nova. Visibilidade, AuthN/AuthZ, proteção de dados, integrações e observabilidade são as mesmas cinco categorias que você desenharia para qualquer sistema. O que foi útil foi vê-las reprojetadas sobre agentes e observar como cada uma se estica em direções desconhecidas.

O Roteiro em Três Ondas

O terço final da sessão foi um rollout em fases.

Onda um é inventário e política. Encontre os agentes. Classifique. Escreva as políticas que governam o que cada classe pode e não pode fazer. A avaliação honesta é que a maioria das empresas trava aqui, porque o inventário muda enquanto a política está sendo escrita.

Onda dois é implementar controles. Escolha uma primitiva para cada pilar, conecte, instrumente. Ferramenta de visibilidade, camada de autorização que suporte ABAC, gate de classificação de dados, broker de integração, pipeline de observabilidade. A palestra mencionou BACI — Behavior Certificates for Agents — como framework proposto para validar origem do prompt, fronteiras de ferramentas e conformidade com política. É cedo. O formato da proposta está certo. As implementações ainda não estão em paridade.

Onda três é estender para integrações e SaaS. A onda mais dolorosa. Seu agente não vive sozinho. Ele chama Salesforce, Workday, GitHub, Jira, seu data warehouse. Cada um tem o próprio modelo de identidade. Federar entre eles é o trabalho que demora mais e produz o progresso menos visível.

O time também citou o AGRIM, projeto open-source da Cloudflare para governança, garantia e gestão de risco de IA agêntica em Kubernetes, como referência de como a indústria está começando a empacotar esses controles. Vale a leitura.

O Que Eu Acrescento: Autorização é Necessária, Não Suficiente

É aqui que coloco meu tijolo.

Tudo na palestra está correto. Nada disso é suficiente. O motivo é que autorização governa a chamada, mas não o alcance. Um agente devidamente autorizado a consultar um banco ainda pode emitir uma consulta que retorna as linhas erradas, porque a topologia do sistema ao redor lhe deu linha de visão para dados que não deveriam estar ao alcance.

Topologia de rede precisa fazer parte do trabalho que identidade não consegue fazer sozinha. Sabemos disso em arquitetura de nuvem há duas décadas. Zonas de disponibilidade, segmentação de VPC, sub-redes privadas, controles de egress. O motivo desses controles existirem é que controles de identidade falham em silêncio — uma role mal configurada não joga exceção, simplesmente responde. Controles de topologia falham com barulho. O pacote não chega. A conexão expira. Você nota.

Para agentes, o análogo é claro. Rode-os em zonas de rede segregadas. Limite o egress às integrações precisas que precisam. Coloque um service mesh entre eles e o plano de dados, com políticas que espelhem — e excedam — a camada de identidade. Se o portão de identidade for burlado por uma injeção de prompt, o portão de topologia é a segunda linha de defesa. Já escrevemos sobre estender zero-trust aos agentes e sobre o stack de contenção de agentes; o argumento de topologia é o piso por baixo desses textos.

Se você saiu da palestra achando que autorização é a resposta, saiu com metade do edifício.

Faça Isto Agora

Se você estiver na sala com os times de plataforma e segurança na próxima semana, está é a versão da palestra que custa zero rodar:

Liste seus agentes. Se não consegue, o pilar de visibilidade está faltando.
Para cada agente, escreva a role, os atributos e a classificação de dados que ele toca. Se RBAC é seu único controle, ABAC é a próxima conversa.
Identifique a fronteira de integração. Para onde o agente liga? Que portão fica ali?
Puxe os logs. Você consegue responder “quem, o quê, quando, em nome de quem, com qual contexto” para as últimas 100 chamadas do agente? Se não, observabilidade está faltando.
Olhe a rede. O agente está em zona segregada com egress explícito? Se não, identidade está fazendo um trabalho que topologia deveria estar dividindo.

Não é pitch de fornecedor. É lista de inventário. A contribuição do time do Google foi articular a lista de forma limpa. O trabalho é caminhar pelo seu próprio edifício e contar o que está no lugar.

Fui ao Cloud Next humilde. Saio mais convencido do que cheguei de que o problema de identidade de agentes não é exótico. É o problema antigo de chapéu novo. Os times que saem na frente são os que reconhecem o chapéu e param de se surpreender com ele.

Fontes

Google Cloud. “Google Cloud Next 2026.” Abril de 2026.
Google Cloud Blog. “Identity & Security on Google Cloud.” Abril de 2026.
Notas pessoais do autor, presencial em Las Vegas.

A Victorino ajuda empresas a estender governança de identidade aos agentes de IA antes que isso vire a próxima superfície de violação: contato@victorino.com.br | www.victorino.com.br