Engenheiro de segurança montou em 7 dias um servidor MCP que assusta o agente de IA com vulnerabilidades

Um especialista em segurança da informação montou para si um assistente de IA com uma leve paranoia: o AppSecGate, um servidor MCP local que roda scanners, mantém uma base de findings e obriga o agente a lidar com as vulnerabilidades em vez de dispensá-las. A primeira versão consumiu 7 dias, cerca de 210 milhões de tokens e aproximadamente 3000 rublos, ou seja, cerca de 14 rublos por milhão de tokens. A última execução no OWASP Juice Shop levou cerca de 50 minutos e custou por volta de 15 rublos. O agente, rodando o deepseek-v4-flash, processou 200 achados e corrigiu 56, entre eles 8 critical e 45 high.

Por que o AppSec está virando gargalo

O SSDLC clássico funciona assim: o desenvolvedor escreve o código na IDE, o código vai para o Git, o CI/CD roda SAST, SCA e DAST, e os relatórios seguem para o ASOC/ASPM, onde são deduplicados e enriquecidos. Depois, um profissional de segurança tria os findings e abre tarefas no tracker. O principal ponto fraco desse arranjo é a velocidade imprevisível das correções. Se o scanner quebra, não há como substituir uma biblioteca vulnerável ou o AppSec sai de férias, a correção pode esperar muito tempo. O principal ponto forte é a divisão clara de responsabilidades, e é fácil explicar ao negócio que segurança precisa ser paga.

Os LLMs sobrecarregam esse arranjo. Os desenvolvedores primeiro apertavam TAB, depois passaram a pedir ao agente que escrevesse um método, e agora entregam a ele uma especificação técnica que o próprio modelo redigiu a partir de uma tarefa também escrita por um modelo. O código cresce e fica mais confuso, o volume de triagem aumenta e o teste manual se complica. Soma-se a isso os vibe coders, que tocam projetos sozinhos e acreditam que o modelo não confunde dev com produção.

Se simplesmente colocarmos um agente em cada papel, o resultado é um loop longo em que tudo fica fechado e os tokens são gastos, mas o processo está longe de ser ótimo. Deixar os agentes conversarem diretamente entre si também é arriscado. O autor ironiza: a primeira coisa que eles podem descobrir é que chegar a um acordo por prompt injection é mais rápido. A questão é só se o orçamento de tokens não acaba antes.

Menos agentes, mais estrutura

A alternativa sistêmica proposta pelo autor é mais simples:

• O TaskTracker sai do processamento de findings, porque é melhor os agentes trocarem dados estruturados. Para controle de tempo e baixa de tokens, o tracker pode ser mantido.
• No CI/CD, fica um único agente autônomo, que recebe do ASOC o contexto dos achados. Ele não é obrigatório: pode ser substituído por um agente disparado pelo profissional de segurança.
• O ASOC/ASPM deixa de ser um sistema para pessoas e passa a ser um sistema para agentes.
• O scan se desloca para a esquerda (shift-left): o próprio agente roda os scanners enquanto escreve o código, como faria com um formatter ou testes unitários. O push não é bloqueado, e o problema é escalado para o AppSec ou o Lead. Escanear apenas o diff economiza tokens, porque o agente já está trabalhando naquele arquivo. A triagem local é registrada no servidor central, e a eficácia da abordagem pode ser demonstrada à gestão.

Como funciona o AppSecGate

O MVP é um servidor MCP local em um Docker isolado, com um conjunto de scanners e uma base SQLite; a arquitetura deixa espaço para um servidor central. O agente trabalha pelo Cline: o autor migrou do Continue para ele e escreveu um AGENTS.md. O conjunto de ferramentas que o agente usa:

• get_config — verificação da configuração;
• scan_project — execução do scan e resultado agregado;
• query_findings_db — acesso SQL à base de findings (o agente, por algum motivo, prefere justamente essa ferramenta, embora haja alternativas);
• get_fix_context_batch — contexto dos alertas para a correção;
• verify_fix_batch — verificação da correção ou supressão do achado como FALSE_POSITIVE.

Ao receber o pedido «Verificar a segurança do projeto» no modo de planejamento, o agente percorreu essa cadeia e concluiu: não é preciso corrigir nada, porque o Juice Shop é vulnerável de propósito. Foi necessário explicar que o que estava em teste eram as ferramentas. Depois de passar para o modo Act, ele iniciou a triagem, consultou a base periodicamente e, no fim, montou o relatório.

O autor avaliou modelos locais com um benchmark de sete variantes em uma única RTX 4060 Ti 16GB. Não houve um vencedor claro, mas ele tirou suas conclusões.

Para as equipes, a conclusão prática é a seguinte. Uma camada MCP estruturada entre os scanners e o agente transforma a segurança em mais uma etapa comum do ciclo de desenvolvimento. O custo de uma execução de 15 rublos em um modelo de nuvem barato é bem menor que uma hora de trabalho de um engenheiro de AppSec em triagem de rotina.

Os detalhes também ajudam: um AGENTS.md com regras claras, a separação entre Plan e Act, a marcação explícita de FALSE_POSITIVE com verificação. Essa combinação não substitui o AppSec.

A rotina passa para o agente, e as pessoas ficam com a arquitetura segura e a busca por vulnerabilidades de lógica. Como efeito colateral, surge uma ferramenta pronta para vibe coders solo, que precisam de TimeToMarket e não querem acabar como ilustração de falhas de IA nas notícias.