Uma skill é código, e código precisa de um ponto de verificação

Uma skill é código, e código precisa de um ponto de verificação

A NVIDIA abriu o código de uma ferramenta chamada SkillSpector esta semana. Sua função é estreita e já estava atrasada: escanear skills de agentes de IA em busca de problemas de segurança antes que um agente as carregue. O projeto vem com detecção de 64 padrões de vulnerabilidade, um número sobre o qual vale a pena parar, porque implica que alguém sentou e enumerou as formas pelas quais uma skill pode dar errado.

Em paralelo, a Cloudflare publicou uma skill de auditoria de segurança que executa auditorias em várias fases sobre uma base de código e emite achados legíveis por máquina, e o GitHub detalhou um classificador de detecção de segredos sensível ao contexto que elevou em 11,5 por cento a aceitação ponderada de achados reais e reduziu em 86 por cento o tempo mediano de varredura. Três equipes diferentes, três ângulos diferentes, mesma conclusão: a camada onde os agentes recebem suas instruções virou infraestrutura, e infraestrutura passa por auditoria.

O que uma skill realmente é

A palavra "skill" faz tudo soar mais suave do que é. Uma skill não é uma configuração. É um conjunto de instruções e, muito frequentemente, de scripts, modelos e definições de ferramentas que um agente vai ler e seguir com as permissões que lhe foram concedidas.

Essa última oração resume o modelo de segurança em uma frase. Uma skill não precisa de um exploit, porque não está arrombando nada. Ela é convidada a entrar, recebe as chaves e é solicitada a ajudar. Se suas instruções forem maliciosas ou apenas descuidadas, o agente agirá conforme elas como se fossem sua própria intenção, porque, até onde consegue perceber, são.

É o mesmo problema que os gerenciadores de pacotes enfrentaram décadas atrás, e foi resolvido da mesma forma: assumindo que a cadeia de suprimentos é hostil e construindo pontos de verificação nela. O ecossistema de agentes está no início desse processo, e é por isso que um projeto como o SkillSpector importa muito mais do que seu número de estrelas sugere.

Por que 64 padrões é o número interessante

Uma lista de 64 padrões de vulnerabilidade é uma taxonomia, e taxonomias são como um campo amadurece. Antes de ter uma, todo incidente é uma surpresa. Depois de ter uma, os incidentes se tornam instâncias de classes conhecidas, o que significa que podem ser testados, rastreados e, por fim, eliminados por projeto.

Algumas dessas classes são familiares no software comum: comandos de shell inseguros, entradas não validadas, credenciais gravadas em arquivos que nunca deveriam contê-las. Outras são específicas desta nova camada. Instruções que ampliam o escopo do agente sem dizer. Prompts que puxam conteúdo não confiável e o tratam como comando. Descrições de ferramentas que deturpam o que uma ferramenta faz, de modo que o agente a chama pelo motivo errado. Skills que encadeiam outras skills em um caminho que ninguém pretendia.

É na última categoria que mora a dificuldade. Uma skill é perigosa exatamente na proporção do quanto ela pode alcançar, e agentes modernos podem alcançar muito: o sistema de arquivos, a rede, outros agentes, as ferramentas que outra skill registrou. O raio de impacto de uma skill ruim não é a skill. É tudo o que o agente pode tocar, um alvo móvel que depende de quais outras skills foram carregadas primeiro.

O problema do contexto envenenado

A parte desconfortável da segurança de agentes é que a fronteira entre dados e instrução não é imposta por nada. Um modelo lê texto. Ele não sabe por natureza quais frases são fatos a considerar e quais são ordens a obedecer.

Assim, uma skill que busca uma página web, lê um rastreador de issues ou resume um e-mail está expondo o agente a texto que pode conter instruções. Se o modelo as seguir, não há exploit em nenhum sentido tradicional. Há apenas um sistema que fez o que lhe foi dito por algo em que não deveria ter confiado.

Por isso a varredura precisa acontecer no momento do carregamento e não no momento do incidente. Uma vez que uma skill está rodando dentro de um agente com permissões amplas, a pergunta interessante já foi mal respondida. O ponto de verificação tem de vir primeiro, e tem de ser automático, porque a revisão humana de cada skill de um repositório não escala e nunca vai escalar.

A auditoria está virando um produto

O lançamento da Cloudflare aponta para uma segunda tendência. Sua skill de auditoria produz achados legíveis por máquina em vez de uma lista que alguém precisa ler. Essa formulação faz um trabalho real. Achados que um humano precisa ler são achados que um humano vai passar os olhos. Achados que um pipeline pode consumir podem virar tickets, merges bloqueados ou implantações recusadas sem que ninguém precise lembrar de olhar.

O trabalho do GitHub em detecção de segredos se encaixa no mesmo padrão. O vazamento de segredos escala com quanto código é produzido, e a produção de código subiu bastante. A resposta não foi "contratar mais revisores". Foi um classificador sensível ao contexto que corta o ruído, para que os alertas que as pessoas de fato veem tenham mais chance de ser reais. A precisão, em ferramentas de segurança, é o que determina se alguém ainda lê os alertas depois do terceiro mês.

Ambos são o mesmo movimento feito em camadas diferentes. Em vez de pedir aos humanos mais vigilância, torna-se a verificação automática boa o bastante para que a atenção humana só seja gasta onde pode importar. É a única estratégia que sobrevive ao contato com o volume.

A questão de governança por baixo

Há aqui uma camada de políticas que avança mais rápido do que a maioria das equipes percebe. Os sistemas de controle de versão começam a carregar metadados de proveniência. Os repositórios de pacotes estão adicionando atestação. Órgãos de padronização trabalham em como rotular conteúdo sintético e como identificar um agente. A direção é para um mundo em que a origem e a integridade de um artefato precisam ser prováveis, não presumidas.

As skills ficam desconfortáveis nesse mundo, porque a mesma skill pode ser útil e perigosa conforme o contexto. Uma skill que pode modificar arquivos é essencial para um agente de programação e catastrófica para um agente que também lê e-mails não confiáveis. A decisão de confiança não é uma propriedade da skill sozinha. É uma propriedade da skill mais o ambiente mais as outras skills que ela pode alcançar.

O que sugere que os scanners acabarão precisando fazer mais do que casamento de padrões. A versão genuinamente difícil desta ferramenta verifica se uma combinação proposta de skills concede uma capacidade que ninguém pediu, e avisa antes de publicar em vez de depois.

O que as equipes devem fazer agora, sem exagerar

Pânico não é a resposta certa, e tratá-lo como problema de outra pessoa também não.

Os movimentos práticos não têm glamour. Trate skills de terceiros como dependências não confiáveis, porque é exatamente o que são. Fixe versões e revise os diffs quando mudarem. Rode agentes em ambientes onde o raio de impacto é limitado, para que uma skill ruim não alcance a rede ou o banco de dados de produção só porque o agente era conveniente. Registre quais skills foram carregadas e o que fizeram, porque a primeira pergunta difícil depois de qualquer incidente é o que foi autorizado a rodar.

A indústria já percorreu esse caminho. Os ecossistemas de pacotes eram inseguros, depois se tornaram penosos de atacar, e o penoso é o ponto. As skills de agentes estão indo para o mesmo equilíbrio, e os projetos lançados esta semana são a primeira tentativa séria de construir o ponto de verificação. Chegar lá antes do incidente é mais barato do que depois, e a única coisa necessária para chegar cedo é a disposição de ser entediante a respeito.