AIR Security Levanta $50M: O que a Verificação Automatizada Resolve — e o que Ainda Não Consegue

Ontem, a AIR Security saiu do modo stealth com $50M em duas rodadas de investimento seed — $10M liderados pela Sequoia e $40M liderados pela Greenoaks — para construir ferramentas de segurança para as habilidades, plugins e servidores MCP que os agentes de IA instalam. Trabalhamos no mesmo setor: somos a equipe Correctover, construindo as ferramentas de verificação de código aberto em github.com/Correctover. Portanto, nossas menções aumentaram. Aqui está nossa análise — o que aconteceu, por que os números importam, o que a filtragem automatizada realmente resolve e onde ela estruturalmente para.

Uma cadeia de suprimentos que ninguém está observando

Quando os agentes de codificação começaram a buscar componentes de terceiros por iniciativa própria, uma nova cadeia de suprimentos de software se formou — uma montada em tempo de execução. Como o post de anúncio da Sequoia coloca, um agente consome "habilidades, plugins, servidores MCP, sub-agentes, hooks, comandos e regras — cada um rodando com as próprias permissões do agente, dentro do ambiente do usuário, contra os dados do usuário," geralmente "instalados com o cuidado que a maioria de nós daria a uma extensão de navegador."

Os números de exposição relatados esta semana merecem ser analisados:

• Mais de 17.800 add-ons públicos de IA, contabilizando 6,7 milhões de instalações, receberam instruções de fontes externas que ninguém havia verificado, de acordo com a SiliconAngle.
• A AIR diz que sua plataforma atualmente filtra cerca de 27% dos add-ons e habilidades que encontra online, segundo o relatório da TechCrunch.
• A própria pesquisa da AIR, resumida no post da Sequoia, encontrou 925 habilidades ativas puxando dependências e prompts de links mortos; registrar esses links expirados colocou cerca de 134.000 agentes instalados sob controle externo. Em um experimento separado, uma habilidade maliciosa construída por um pesquisador alcançou mais de 26.000 agentes através de um marketplace confiável e redes sociais — e todos os scanners pelos quais passou a aprovaram.

O modelo mental que o CEO da AIR, Yair Saban, oferece é a assinatura de drivers: no início dos anos 2000, os drivers não precisavam de assinaturas; hoje, cada driver informa quem o assinou, porque carrega código no kernel. Habilidades e servidores MCP carregam instruções em um agente que detém suas credenciais — e ainda não há um equivalente à verificação de assinatura, como relata a TechCrunch.

É por isso que a categoria está atraindo capital. Dezenas de milhares de componentes, milhões de instalações, e os componentes continuam mudando após a instalação.

O que a camada automatizada realmente resolve

O manual que está emergindo nesta categoria — descoberta, análise estática, verificações de dependência, detonação em sandbox, interceptação em tempo de execução, listas de permissão — acompanha de perto o que a AIR descreve em sua linha de produtos (Sequoia). Vale a pena ser preciso sobre o que essa maquinaria é boa, porque é muito:

• Análise estática captura credenciais codificadas, chamadas de rede inexplicadas e permissões declaradas que não correspondem ao que o componente afirma fazer.
• Verificações de dependência capturam as famílias de links mortos e typosquatting — o padrão SkillJacking acima é fundamentalmente uma falha de integridade de dependência.
• Detonação em sandbox observa o que um componente realmente faz quando executado: domínios de callback, acesso a arquivos, processos filhos.
• Interceptação em tempo de execução bloqueia instalações ou chamadas que falham na política no momento, em vez de confiar em uma revisão única.
• Reverificação contínua lida com a deriva. Uma habilidade que passou pela revisão em março pode ser reescrita em junho por seu mantenedor — ou por quem assumiu a conta do mantenedor. Bogomil Balkansky da Sequoia disse à TechCrunch: "Este não é um problema de escaneamento, é um problema de reverificação contínua."

Com mais de 17.800 componentes e crescendo, nada disso pode ser em escala humana. A automação não é um recurso opcional aqui. É a única coisa que pode cobrir a superfície.

Onde a automação para estruturalmente

Aqui está a parte em que passamos nossos dias, e onde empurraríamos a conversa mais adiante. A filtragem automatizada produz veredictos em escala, mas três classes de problemas resistem estruturalmente — não porque a implementação de qualquer fornecedor seja fraca, mas por causa do que as perguntas em si exigem.

1. Intenção semântica em código minificado ou ofuscado. Heurísticas e execuções em sandbox dependem de sinais. Um payload minificado ou deliberadamente ofuscado os remove: o código pode ser um artefato de build empacotado inofensivo, ou um dropper que só se ativa sob condições que a sandbox nunca reproduz — uma data específica, um inquilino específico, um prompt específico. Determinar a intenção significa ler o código em contexto, da maneira que um revisor humano faz. A detonação responde "o que ele fez no laboratório?" Não pode responder completamente "o que ele faria na minha máquina, na terça-feira, com meus dados?"

2. Abuso de ferramentas em nível de lógica de negócios. As decisões mais difíceis não são componentes maliciosos — são componentes legítimos usados de maneiras ilegítimas. Um plugin de CRM com um recurso de exportação em massa documentado está fazendo exatamente o que diz quando um agente exporta 40.000 contatos para um e-mail pessoal. Cada chamada de ferramenta individual é bem formada, permitida e parece benigna. "Este agente pode ler contas, mas nunca exportar em massa" não é uma assinatura universal. É a política da sua organização, e julgá-la requer entender seu contexto de negócios, não apenas os bytes em trânsito.

3. Evidência para aquisição e conformidade. Um sinal de aprovação/reprovação é um sinal, não um registro. Quando um questionário de segurança pergunta "o que foi verificado, quando, em qual versão exata, sob qual conjunto de regras, e quem assinou o veredicto?" você precisa de um artefato arquivável — um recibo que vincula o veredicto aos bytes de entrada exatos, à prova de adulteração e re-verificável meses depois. Esta é a mesma lacuna que a segurança de aplicativos preencheu ao passar de "o scanner disse que estava tudo bem" para atestações assinadas e SBOMs. Sinais protegem o momento; evidências sobrevivem à auditoria.

Nada disso é uma crítica às plataformas automatizadas. Você precisa do filtro antes de poder arcar com a revisão. É a mesma divisão de trabalho que SAST/DAST versus revisão manual de código versus atestação: camadas, não substitutos.

Torne seu componente barato de auditar

Se você publica habilidades ou servidores MCP, a lição prática é que a verificação está se movendo de "alguém pode dar uma olhada nisso" para "um pipeline decidirá se as empresas podem instalar isso." Seu trabalho é facilitar o trabalho do pipeline:

• Menor privilégio, declarado explicitamente. Envie um manifesto de permissões. Somente leitura por padrão, tokens escopados, sem variáveis de ambiente herdadas que você não usa realmente. Um componente que pede tudo é bloqueado; um componente que