Mudanças no Modelo de Ameaças com Antigravity 2.0

Todos que estão lendo sobre Antigravidade 2.0 esta semana são desenvolvedores celebrando o que
podem agora construir. Eu li os mesmos anúncios de uma cadeira diferente: sou um
Engenheiro MSS em um Centro de Operações de Segurança na América Latina. Meu trabalho é detectar,
conter e responder a ameaças nas redes onde essas ferramentas eventualmente rodarão.

E o Google I/O 2026 me deu muito para pensar — não porque a tecnologia é
desagradável, mas porque ela introduz padrões de execução de agentes que a maioria das equipes de
segurança está completamente despreparada.

Esta é a conversa. A que a trilha de desenvolvedores não teve.

O Que Realmente Foi Lançado (As Partes Relevantes para Segurança)

Deixe-me ser específico sobre o que mudou, porque os detalhes importam.

Antigravidade 2.0 introduziu:

• Orquestração de subagentes — um agente gerando e direcionando outros
• Fluxos de trabalho cron em segundo plano — agentes rodando em horários sem iniciação humana
• Mascaramento nativo de credenciais e aplicação de políticas do Git em sandboxes
• Um sistema AGENTS.md / SKILL.md para definir o comportamento do agente em arquivos markdown

Agentes Gerenciados na API Gemini permite que qualquer desenvolvedor com uma chave de API provisiona
um sandbox Linux isolado onde um agente raciocina, executa ferramentas, executa código e
busca na web. Uma chamada de API.

WebMCP permite que sites exponham funções JavaScript estruturadas e formulários HTML
diretamente para agentes baseados em navegador.

Essas três coisas juntas descrevem um mundo onde agentes de execução de código autônomos
são uma mercadoria, rodando em horários, gerando filhos, interagindo diretamente com sites,
e sendo configurados através de arquivos de texto que podem ser armazenados em controle de versão.

Isso é uma superfície de ameaça significativamente diferente de "um chatbot que escreve sugestões de código."

As Novas Perguntas que um SOC Tem que Responder

Eu trabalho com CrowdStrike Falcon e SentinelOne diariamente. Neste momento, quando vejo
execução de processo suspeita, eu tenho um modelo mental: um humano fez algo,
ou malware fez algo. A cadeia de atribuição — mesmo quando complicada —
ultimamente remete a uma dessas duas categorias.

Agentes quebram esse modelo.

Quando a Antigravidade gera um subagente que escreve e executa código em um sandbox,
como isso se parece em um feed de telemetria EDR? É um processo pai → processo filho
de uma maneira que eu reconheço? Ou parece uma nova árvore de processos sem um
ancestral humano óbvio? Se minhas regras de detecção acionam em "processo incomum gerado por
browser," elas também acionam em fluxos de trabalho legítimos de agentes?

Eu ainda não sei. E a maioria da indústria de segurança também não, porque isso
es realmente um comportamento novo em escala.

Fluxos de trabalho cron em segundo plano significam agentes agindo sem sessões de usuário.
Análises comportamentais tradicionais dependem fortemente do contexto do usuário — este processo rodou
quando este usuário estava logado, fazendo essas outras coisas. Um agente rodando em um
horário às 3 da manhã não tem sessão de usuário. Ele parece anômalo por design. Ou ajustamos
a detecção para excluí-lo (criando um ponto cego) ou nos afogamos em falsos positivos.

AGENTS.md e SKILL.md arquivos são configuração-como-código para o comportamento do agente.
Isso é elegante para desenvolvedores. Para equipes de segurança, significa que o comportamento do agente pode ser
modificado por qualquer um com acesso de escrita a um repositório — e essa modificação
pode não passar por nenhum fluxo de aprovação, pode não acionar nenhum alerta,
e pode não ser revisada por ninguém que entenda as implicações de segurança.

A injeção de prompt já existe como uma classe de ataque. Agora imagine a injeção de prompt
via um arquivo markdown comprometido em um repositório que um desenvolvedor confiou.

O Que o Google Realmente Acertou (Edição de Segurança)

Quero deixar claro: não estou escrevendo um artigo de pânico. Várias das escolhas de design do Google
no I/O 2026 mostram uma real consciência de segurança.

Sandboxing de terminal multiplataforma na Antigravidade é um controle significativo.
Agentes rodando em VMs Linux isoladas com sistemas de arquivos novos por execução têm
um raio de explosão muito menor do que agentes rodando em ambientes compartilhados.
Se um agente for manipulado para fazer algo malicioso, a contenção é real — não teórica.

Mascaramento de credenciais como um recurso nativo é a decisão certa. Um dos
modos de falha mais comuns em sistemas de agentes iniciais era agentes registrando ou
produzindo credenciais que estavam em seu contexto. Construir o mascaramento na
estrutura em vez de deixá-lo para desenvolvedores individuais reduz
significativamente essa classe de incidentes.

Políticas do Git endurecidas significam que agentes não podem empurrar arbitrariamente para
branches protegidos. Novamente — essa é a restrição certa a ser construída na plataforma.

O Google claramente pensou sobre a superfície de ataque óbvia. A questão é
se eles pensaram sobre as não óbvias.

A Lacuna Que Ninguém Está Falando

A lacuna é observabilidade e auditabilidade para equipes de segurança.

Desenvolvedores têm novas ferramentas incríveis para construir e rodar agentes. O que as equipes de
segurança têm para monitorá-los?

Neste momento, a resposta parece ser: as mesmas ferramentas SIEM e EDR que já temos,
que foram projetadas para atividade gerada por humanos e vão produzir um ruído significativo
quando confrontadas com atividade gerada por agentes em escala.

Eu gostaria de ver — e argumentaria que a indústria precisa antes que isso se torne mainstream
nas empresas — algumas coisas que não estavam nos anúncios do I/O:

Logs de auditoria de agentes estruturados que são analisáveis por ferramentas de segurança. Não
logs de aplicação, mas algo análogo ao CloudTrail para ações de agentes:
o que este agente chamou, quais arquivos ele tocou, quais solicitações externas
ele fez, qual foi a cadeia de decisões que levou a cada ação?

Identidade do agente no contexto de segurança. Quando um agente Antigravidade faz uma
solicitação de rede, qual identidade ele carrega? É a chave de API do desenvolvedor?
Uma conta de serviço? Como uma equipe de IR, pós-incidente, determina qual agente
fez qual solicitação com que autorização?

Detecção de mudanças em AGENTS.md e alertas. Se este arquivo é onde o
comportamento do agente reside, as equipes de segurança precisam saber quando ele muda — não como uma
notificação do Git para um desenvolvedor, mas como um evento de segurança com contexto.

Por Que Isso Importa para a Comunidade de Desenvolvedores

Se você está construindo com Antigravidade, Agentes Gerenciados, ou qualquer uma das
novas ferramentas de agentes do Google — isso é com você também, não apenas com a equipe de segurança.

A segurança dos sistemas de agentes de IA não vive apenas nos controles da plataforma
que o Google constrói. Ela vive em como os desenvolvedores projetam os escopos dos agentes
(permissões mínimas, sempre), como eles lidam com credenciais em arquivos AGENTS.md
(elas não deveriam estar lá), como eles pensam sobre o que acontece quando um agente
ecebe entrada inesperada de uma fonte externa com a qual foi instruído a interagir.

O WebMCP sendo uma interface estruturada em vez de captura de tela é
a verdade uma melhoria de segurança — reduz a superfície de ataque de
"agente recebe conteúdo malicioso de uma página web e o executa."
Mas não elimina a injeção de prompt. Um endpoint WebMCP ainda pode
retornar instruções elaboradas para manipular a próxima ação do agente.

As comunidades de desenvolvedores e segurança precisam ter essa conversa
juntas, agora, antes que a atividade gerada por agentes se normalize em ambientes
de empresas e a janela de detecção de anomalias se feche.

O Google I/O 2026 construiu um remarkabl