Por que parei de deixar Claude executar varreduras de segurança

Um fundador que conheço passou a noite da última terça-feira depurando o que ele achava ser um bug do Claude. Ele havia conectado o Claude Code ao seu repositório com a ferramenta de shell padrão, pediu para "escanear este código em busca de segredos e injeção SQL", e assistiu enquanto ele produzia um relatório limpo com confiança. Zero descobertas. Ele enviou para a staging. Doze horas depois, seu alerta do Datadog disparou em um rastreamento de erro do Postgres que expôs uma chave de conta de serviço hardcoded em um arquivo de configuração que o Claude supostamente havia escaneado.

Ele me ligou às 23h. Fizemos uma tela compartilhada. O problema era quase engraçado uma vez que o vimos. O Claude havia executado cyscan — corretamente, com as bandeiras certas — contra o diretório errado. Ele havia cd para uma subpasta mais cedo na conversa para ler um arquivo, nunca cd de volta, e então executou o escaneamento a partir de lá. O escaneamento foi concluído em 400ms porque havia seis arquivos em escopo. O Claude escreveu um resumo confiante desses seis arquivos, chamou de auditoria de código e seguiu em frente.

Isso não é uma falha do Claude. Isso é uma falha de design da ferramenta. Shell é uma interface terrível para um scanner de segurança quando o chamador é um agente probabilístico sem modelo de estado do diretório de trabalho, sem esquema do que "concluído" parece, e sem como saber se a ferramenta que acabou de invocar realmente entendeu o pedido. Toda a troca foi baseada em vibrações. O agente produziu uma saída confiante porque as ferramentas de shell produzem stdout e stdout parece uma resposta.

Eu venho construindo a Cybrium há dois anos, e a decisão arquitetônica mais importante que tomamos nos últimos seis meses foi parar de dizer às pessoas para invocar nossos scanners via shell. Hoje, tudo passa por um servidor MCP. Dez ferramentas. Entradas tipadas. Saídas estruturadas. Sem deriva do diretório de trabalho. Deixe-me explicar por que isso é importante e o que aprendemos ao longo do caminho.

A tese

Se seu agente se comunica com ferramentas de segurança através de um shell, você construiu um sistema onde a confiança do agente está desacoplada da cobertura real do scanner. O MCP corrige isso tornando o contrato entre o agente e a ferramenta explícito, verificável por máquina e inspecionável após o fato. Isso não é uma atualização de UX. É a diferença entre um pipeline de segurança que você pode auditar e um que você não pode.

O que a "ferramenta de shell padrão" realmente te dá

Quando o Claude Code, Cursor ou qualquer agente executa cyscan --path . --format json através de uma ferramenta bash, aqui está o que realmente está acontecendo. O agente constrói uma string. A string vai para um shell. O shell mantém seu próprio estado — diretório de trabalho, variáveis de ambiente, códigos de saída anteriores — que o agente observa apenas parcialmente. O scanner é executado, escreve no stdout, talvez também no stderr, sai com um código, e o agente lê tudo de volta como um único bloco de texto que ele então tem que analisar.

Cada passo ali é um lugar onde as coisas quebram de maneiras que o agente não consegue ver.

O agente não sabe se cyscan era o binário que ele pensava que era, ou algum alias, ou uma versão diferente no PATH. Ele não sabe se o caminho que passou era um symlink, foi expandido pelo glob do shell, ou foi truncado. Ele não sabe se o stderr continha avisos que mudam materialmente o significado do stdout. Ele não sabe se o código de saída mapeia para "escaneamento limpo" ou "scanner falhou após execução parcial." Ele apenas vê texto.

E aqui está a parte que me assombra como alguém que está enviando um produto de segurança: o agente não sabe quantas regras foram executadas. Se cyscan executou 1.815 regras em 75+ linguagens em um monorepo de 200 engenheiros, esse é um resultado. Se ele executou 12 regras porque só encontrou dois tipos de arquivo na subpasta que realmente estava apontando, esse é um resultado completamente diferente. O stdout parece semelhante em ambos os casos — um array JSON de descobertas, possivelmente vazio. O agente resume "sem descobertas." O CISO dorme mal.

As ferramentas de shell otimizam para flexibilidade humana. Humanos fazem referências cruzadas, notam anomalias, ficam suspeitos quando um escaneamento termina muito rápido. Agentes não fazem isso, pelo menos não de forma confiável, e certamente não sob pressão quando estão quatro turnos profundos em uma conversa sobre outra coisa.

O que o MCP muda estruturalmente

O Model Context Protocol é, em sua essência, uma camada RPC tipada entre agentes e ferramentas. Isso soa seco. As implicações não são.

Quando o Claude chama cyscan_repository através do nosso servidor MCP, ele não está escrevendo uma string de shell. Ele está chamando uma função com um esquema tipado. O esquema declara que path é obrigatório, que deve ser um caminho absoluto, que language_filter é um enum opcional, que rule_packs tem como padrão "todas as 1.815." O servidor MCP valida a chamada antes que nosso scanner seja executado. Se o agente esquecer um argumento obrigatório, a chamada falha com um erro estruturado que o agente pode realmente raciocinar — não um erro bash que diz "argumento ausente" em algum formato que o agente tem que combinar com texto.

A resposta também é estruturada. Não stdout. Um objeto JSON com campos fixos: scan_id, files_scanned, rules_executed, findings, coverage_metadata, duration_ms. O agente não precisa analisar nada. Ele apenas lê files_scanned. Se esse número for 6 quando o repositório tem 4.000 arquivos, o agente tem uma chance de notar, porque files_scanned é um campo de primeira classe que o prompt do sistema do agente pode ser instruído a verificar.

Isso é o que quero dizer com tornar o contrato verificável por máquina. Com shell, "o escaneamento realmente escaneou a coisa" é uma questão de vibrações. Com MCP, é um campo.

As dez ferramentas e por que dez

Nosso servidor MCP expõe exatamente dez ferramentas agora. Às vezes me perguntam por que tão poucas — certamente uma plataforma de segurança tem mais área de superfície do que isso. A resposta é que dez é o resultado de muitas discussões sobre granularidade.

Poucas ferramentas e cada ferramenta se torna uma função de deus com vinte parâmetros e o agente tem que aprender uma sub-linguagem para operá-la. Muitas ferramentas e a janela de contexto do agente se enche com descrições de ferramentas antes que ele tenha feito uma única coisa útil. Dez foi onde chegamos depois de observar agentes realmente usarem o servidor por três meses.

As ferramentas se dividem grosso modo em três famílias. A análise de código e repositório vive em ferramentas apoiadas por cyscan que lidam com análise estática em mais de 75 linguagens. A análise específica de IA vive em ferramentas apoiadas por cyradar que sondam pontos de inferência locais — Ollama, vLLM, TGI, LocalAI, Triton, LM Studio, llama.cpp — para os tipos de configurações incorretas que não aparecem em nenhum scanner de vulnerabilidades convencional. A fuzzing de Web e API vive em ferramentas apoiadas por cyweb que dirigem nossas 22 categorias de fuzzing com 95% de fidelidade de conversão de template contra assinaturas da comunidade upstream.

Cada ferramenta faz uma coisa. O agente as compõe. Essa composição é onde o verdadeiro poder reside, e é também o que as ferramentas de shell fundamentalmente não podem fazer, porque a composição de shell acontece através de pipes e análise de strings em vez de através de dados estruturados que o agente realmente entende.

Um exemplo concreto

Aqui está o tipo de fluxo de trabalho que é trivial com o MCP e miserável com o shell. Suponha que eu queira que meu agente faça uma verificação de segurança completa em um novo microserviço: escanear a fonte em busca de vulnerabilidades e segredos, então, se alguma das descobertas tocar um caminho de inferência de IA, sondar o ponto de inferência em execução para esses problemas específicos, então, se alguma das descobertas tocar uma rota HTTP, fuzz essa rota com templates relevantes.

Com shell, isso é um pequeno programa. O agente tem que invocar cyscan, analisar a saída, construir um comando de acompanhamento, invocar isso, analisar, construir outro. Cada passo de análise é um lugar onde o agente pode alucinar nomes de campos, perder descobertas ou se atrapalhar com mudanças de formatação entre versões. Eu já vi agentes perderem descobertas porque esperavam severity e