GuardBee MCP Security Scanners

guardbee-mcp

🇬🇧 Inglês | 🇹🇷 Turco

guardbee.ai — Copiloto de Segurança de IA para sites.

A família de servidores MCP (Model Context Protocol) da GuardBee — um único monorepo, pacotes npm independentes.

Pacotes

Pacote	npm	Descrição
packages/ai-code-scanner	@guardbee/mcp-ai-code-scanner	Escaneia um código-fonte em busca de padrões inseguros de integração LLM/IA (chaves expostas ao cliente, tratamento inseguro de saída, agência excessiva, PII→prompt, injeção de prompt)
packages/compliance-checker	@guardbee/mcp-compliance-checker	Verificações de conformidade com KVKK/GDPR/CCPA
packages/dependency-auditor	@guardbee/mcp-dependency-auditor	Varredura de CVEs para dependências npm/pip/cargo (OSV)
packages/dns-intelligence	@guardbee/mcp-dns-intelligence	Enumeração de registros DNS, detecção de configuração incorreta e subdomínios pendentes
packages/db-gateway	@guardbee/mcp-db-gateway	Gateway em conformidade com KVKK/GDPR entre um LLM e um banco de dados (mascaramento de PII, RBAC, limite de taxa, log de auditoria consultável; adaptadores Prisma/Postgres/MySQL/SQLite/MongoDB; suporte opcional a inserir/atualizar/excluir)
packages/mcp-server-auditor	@guardbee/mcp-server-auditor	Escaneia definições de ferramentas de outros servidores MCP em busca de padrões inseguros (agência excessiva, sinks shell/eval/SQL/SSRF, esquemas flexíveis, segredos codificados, CORS curinga)
packages/prompt-injection-scanner	@guardbee/mcp-prompt-injection-scanner	Escaneia conteúdo RAG/páginas raspadas em busca de injeção indireta de prompt (substituição de instrução, tokens falsificados de função/modelo de chat, texto oculto, endereçamento direto "Caro IA", instruções de exfiltração de dados)
packages/llm-redteam	@guardbee/mcp-llm-redteam	Realiza red-team ativo em um endpoint/chatbot LLM ao vivo com sondas de jailbreak/extração/ofuscação baseadas em canário (alvos OpenAI/Anthropic/webhook)
packages/model-scanner	@guardbee/mcp-model-scanner	Escaneia arquivos de modelos de ML (PyTorch, pickle, safetensors, Keras/H5, ONNX) em busca de riscos na cadeia de suprimentos — globals perigosos de desserialização pickle, cabeçalhos safetensors disfarçados/malformados, RCE em camada Lambda do Keras, path traversal em dados externos ONNX
packages/vector-store-scanner	@guardbee/mcp-vector-store-scanner	Sonda endpoints de banco de dados vetoriais (Weaviate, Qdrant, Chroma, Elasticsearch/OpenSearch, Redis, Postgres/pgvector) em busca de exposição não autenticada de embeddings e dados RAG
packages/prompt-leak-scanner	@guardbee/mcp-prompt-leak-scanner	Captura credenciais vazadas e PII (chaves de API, TC Kimlik No, cartões de crédito, IBANs) em prompts LLM de saída — como ferramentas de varredura MCP e como um proxy reverso ao vivo na frente de uma API LLM real
packages/agent-graph-auditor	@guardbee/mcp-agent-graph-auditor	Constrói um grafo de alcançabilidade em configurações de orquestração multiagente (LangGraph, CrewAI, AutoGen/ag2) para encontrar agência excessiva transitiva — um agente que alcança uma ferramenta perigosa apenas por delegação a outro agente
packages/tool-poisoning-scanner	@guardbee/mcp-tool-poisoning-scanner	Escaneia definições de ferramentas de servidores MCP em busca de envenenamento de ferramentas (instruções ocultas incorporadas na descrição de uma ferramenta) e incompatibilidades de deputy confuso (uma ferramenta com nome de somente leitura cujo handler tem um sink shell/eval/gravação de arquivo/despejo de env)
packages/rug-pull-detector	@guardbee/mcp-rug-pull-detector	Conecta-se ao vivo a outro servidor MCP (stdio/HTTP), estabelece a linha de base da resposta tools/list e detecta um "puxão de tapete MCP" — a descrição/esquema/anotações de uma ferramenta mudando silenciosamente após já ter sido aprovada
packages/memory-poisoning-scanner	@guardbee/mcp-memory-poisoning-scanner	Escaneia código de agente em busca de envenenamento de memória — entrada não confiável gravada em memória persistente entre sessões (memória arquivada/núcleo estilo MemGPT ou um armazenamento vetorial de longo prazo) que depois é recuperada e confiada como contexto
packages/oauth-auditor	@guardbee/mcp-oauth-auditor	Escaneia o próprio código de autorização de um servidor MCP em busca de antipadrões OAuth 2.1 nomeados nas Considerações de Segurança da especificação MCP — passagem de token, validação de audiência ausente, SSRF de descoberta OAuth/OIDC, PKCE ausente, validação flexível de redirect_uri, segredos de cliente codificados
packages/a2a-auditor	@guardbee/mcp-a2a-auditor	Escaneia a implementação do protocolo Agent2Agent (A2A) de um agente (TypeScript e Python) em busca de antipadrões encontrados no próprio código-fonte dos SDKs de referência — buscas de webhook de notificação push não autenticadas (SSRF), Agent Cards sem requisito de autenticação, credenciais incorporadas em metadados de Agent Card servidos publicamente
packages/slopsquat-scanner	@guardbee/mcp-slopsquat-scanner	Verifica cada dependência declarada no manifesto do próprio projeto (package.json, requirements.txt, pyproject.toml) em relação ao registro real npm/PyPI — sinaliza nomes que não existem (provavelmente alucinados por LLM, ou seja, slopsquatting) e nomes que existem mas foram publicados apenas muito recentemente
packages/unbounded-consumption-auditor	@guardbee/mcp-unbounded-consumption-auditor	Escaneia código de aplicativos LLM/agente em busca de Consumo Ilimitado ("negação de carteira", OWASP LLM Top 10 2026 #6) — limites de tokens de saída ausentes, timeouts ausentes em chamadas HTTP LLM feitas à mão, loops ilimitados de chamada de ferramenta/repetição de agente, limites de segurança de framework explicitamente desabilitados (LangChain max_iterations, openai-agents max_turns) e handlers de ferramentas MCP sem limite de taxa visível
packages/secret-scanner	@guardbee/mcp-secret-scanner	Escaneia arquivos em busca de segredos vazados e chaves de API
packages/security-proxy	@guardbee/mcp-security-proxy	Proxy de segurança entre um cliente e servidor MCP
packages/security-suite	@guardbee/security-suite	Pacote de scanner de segredos + auditor de dependências + inspetor SSL + inteligência DNS
packages/ssl-inspector	@guardbee/mcp-ssl-inspector	Inspeção de certificado/cifra/protocolo TLS
packages/vulnerability-scanner	@guardbee/mcp-vulnerability-scanner	Aciona varreduras GuardBee, consulta descobertas, orientação de remediação assistida por IA
packages/telemetry	@guardbee/mcp-telemetry	(interno) Cliente compartilhado de telemetria de uso — não é um servidor MCP por conta própria

Mudanças Recentes (2026-09-27)

Trabalho concluído e enviado encontrado não commitado em ai-code-scanner de uma sessão anterior: pacotes de regras personalizadas (0.2.2 → 0.3.0, menor — nova capacidade, sem mudança de quebra). Padrões integrados cobrem erros comuns de integração IA/LLM, mas nomes de campos e convenções internas (por exemplo, qual prop carrega dados regulados por KVKK) são específicos do projeto — em vez de fazer fork do pacote por cliente, um projeto agora pode colocar arquivos de regras JSON em .guardbee/rules/ (configurável por meio de uma nova chave rules-dir em guardbee.yml) que são mesclados com os integrados no momento da varredura, tanto para o CLI quanto para o servidor MCP (list_patterns marca regras personalizadas carregadas como (custom)). Um id de regra que colide com uma regra integrada ou outra personalizada é rejeitado — relatado no stderr, a varredura continua em vez de travar. 8 novos testes (36 no total): arquivos válidos de regra única e múltipla, uma regra que realmente corresponde e quatro caminhos de rejeição (colisão de id, campo ausente, regex inválido, JSON inválido) além de um caso de diretório de regras ausente. Verificado além dos testes de unidade com uma execução real de ponta a ponta: um arquivo .guardbee/rules/kvkk.json genuíno escaneado contra um arquivo alvo real por meio do binário CLI real, confirmando que a regra personalizada dispara junto com os padrões integrados na mesma execução. tsc --noEmit e npm run build ambos limpos.

Mudanças Recentes (2026-09-26, cont. 4)

Acompanhamento da passada de dogfooding abaixo: fui mais longe no ruído de doc/placeholder de secret-scanner, já que apenas a correção do comentário de supressão reduziu as descobertas em 28% (1.623 → 1.162) contra IBM/mcp-context-forge — o relatório do próprio fork sinalizou isso como ainda ruidoso, e amostrar as descobertas restantes reais revelou três padrões concretos e corrigíveis adicionais em vez de "ruído" vago:

• bearer_token não exigia comprimento mínimo algum, então fixtures de teste como "Bearer alpha" e "Bearer test-token" (da própria suíte de testes Rust desse repositório) correspondiam tão facilmente quanto um token OAuth real — e acabaram sendo quase todo o problema: 1.008 de 1.149 descobertas restantes, de um punhado de strings de teste literais reutilizadas em centenas de pontos de chamada. Tokens bearer reais (JWTs, tokens opacos OAuth2) praticamente nunca têm menos de 20 caracteres; adicionei esse piso ao padrão.
• Adicionei um filtro de placeholder de formato de valor, aplicado a todos os padrões exceto strings de conexão (que têm sua própria allowlist e podem legitimamente conter "example" em um hostname, por exemplo, example.com): uma sequência de 8+ de um caractere repetido, uma sequência sequencial ascendente de 8+ (abcdefgh, 01234567 — o formato exato que as próprias fixtures de teste deste pacote usavam como preenchimento, que precisaram ser reescritas para valores pseudoaleatórios realistas como resultado), ou uma palavra de placeholder de dicionário incorporada no valor (EXAMPLE, PLACEHOLDER, CHANGEME, etc. — é exatamente por isso que a chave de exemplo oficialmente publicada pela AWS, AKIAIOSFODNN7EXAMPLE, é um famoso falso positivo universal em todos os scanners de segredos; agora também é corretamente reconhecida aqui).
• Ampliei a allowlist existente de placeholder entre colchetes <UPPER_CASE> (já presente nos padrões de string de conexão e segredo genérico) para qualquer texto entre colchetes, já que documentações reais escrevem placeholders descritivos como <admin login password>, não apenas tokens <UPPER_CASE>.
• Dividi os padrões de chave secreta/restrita do Stripe em ativa (crítica, inalterada) e modo de teste (nova, severidade baixa) — a própria documentação do Stripe afirma que chaves de modo de teste são seguras para incorporar em exemplos de código, então tratar cada exemplo sk_test_... em um repositório com muita documentação como crítico era em si uma fonte de falso alarme, não um real.

Efeito líquido no mesmo repositório alvo: 1.623 → 173 descobertas (89%). 9 testes novos/atualizados (33 no total), cobrindo tanto as novas supressões quanto casos explícitos de "deve ainda detectar um segredo de aparência realista" para que a correção não regrida a engolir positivos reais. Verificado contra o repositório alvo real, além de um teste de fumaça em todo o monorepo (21 descobertas, todas correspondências pré-existentes de fixtures de teste próprias). secret-scanner 0.2.3 → 0.2.4.

Mudanças Recentes (2026-09-26, cont. 3)

Passada de dogfooding: executei toda a família de scanners contra 5 projetos MCP open-source reais e populares (modelcontextprotocol/servers, IBM/mcp-context-forge, cisco-ai-defense/mcp-scanner, semgrep/mcp, invariantlabs-ai/mcp-injection-experiments) para validar contra código que não controlamos. Nenhuma vulnerabilidade real apareceu — toda descoberta média+ era um falso positivo — mas o exercício encontrou dois bugs reais em nossos próprios padrões, ambos corrigidos aqui com testes de regressão:

• A detecção de mcp-server-auditor (0.1.2 → 0.1.3) correspondia à sintaxe de chamada de método JS de .delete(/.select(/.update(/.insert( de sql_injection_via_tool_input como se fosse DML SQL, sem diferenciar maiúsculas de minúsculas — um params.delete(prefix + "tags") ao lado de um template literal ${params.toString()} não relacionado era suficiente para acioná-la (o admin_ui/search.js de IBM/mcp-context-forge, um auxiliar simples de URLSearchParams de navegador, sem SQL por perto). Foi ajustado para exigir uma palavra-chave real de cláusula SQL (FROM/INTO/SET/WHERE/VALUES) entre a palavra-chave DML e a interpolação, e adicionado um lookbehind negativo para que uma palavra-chave precedida por . (uma chamada de método) nunca corresponda. Verificado isoladamente antes/depois tanto contra o falso positivo real quanto contra todos os fixtures positivos existentes; re-escaneado o repositório alvo (0 achados, era 1) e todo o monorepo (0 falsos positivos em 247 arquivos).
• O scanner de secret-scanner não tinha suporte a comentários de supressão, então uma base de código madura que já anota correspondências conhecidas como seguras (# pragma: allowlist secret, gitleaks:allow, nosec, etc. — 464 arquivos só em IBM/mcp-context-forge) era sinalizada mesmo assim. Foi adicionado o reconhecimento das convenções comuns (detect-secrets, gitleaks, trufflehog, além de um par guardbee:allow/guardbee-ignore) verificadas na mesma linha da correspondência. Re-escaneando o repositório alvo, os achados caíram de 1.623 para 1.162 (28%) só com isso; ainda há ruído de conteúdo não relacionado de documentação/placeholders, que é uma correção separada e maior, não tentada aqui. 4 novos testes (3 casos positivos de supressão + 1 negativo — uma anotação em uma linha próxima não relacionada não deve suprimir um segredo real). secret-scanner 0.2.2 → 0.2.3.

Também surgiu, ainda não tratado: toda a família é orientada a padrões JS/TS, então 3 dos 5 repositórios alvo (todos em Python, incluindo a lógica real de OAuth/gateway de IBM/mcp-context-forge — exatamente o que oauth-auditor visa) não receberam cobertura de padrões significativa.

Mudanças Recentes (2026-09-26, cont. 2)

Adicionado um 21º pacote, a última das três adições complementares de uma pesquisa sobre o cenário atual de segurança MCP/IA: @guardbee/mcp-oauth-auditor — escaneia o próprio código de autorização de um servidor MCP em busca dos anti-padrões exatos que a seção Considerações de Segurança da especificação MCP nomeia como os riscos centrais de autorização. Passagem de token: o token de um cliente encaminhado sem alterações para uma API downstream em vez de ser trocado/re-especificado — o token foi destinado a este servidor, não a qualquer lugar para onde seja encaminhado. Validação de audiência ausente: uma chamada jwt.verify() que verifica a assinatura de um token, mas nunca sua declaração aud, então um token cunhado para um servidor de recursos completamente diferente também verifica com sucesso aqui — a mesma substituição de deputado confuso na outra direção. Três padrões adjacentes completam: uma URL de descoberta OAuth/OIDC construída a partir de entrada fornecida pelo cliente (a forma por trás de um CVE real divulgado), redirect_uri validado com startsWith/includes em vez de correspondência exata (bypass de redirecionamento aberto) e um client_secret codificado. Duas das seis verificações (audiência, PKCE) procuram uma ausência perto de um local de chamada em vez de um regex fixo, extraindo primeiro a construção completa da chamada/URL. 18 testes; encontrado e corrigido um bug real de regex durante o desenvolvimento (um \b final após um caractere ] nunca pode corresponder, já que ] não é um caractere de palavra — silenciosamente perdia a forma de notação de colchetes de acesso a cabeçalho, req.headers['authorization']). Verificado de ponta a ponta contra um fixture com todos os 6 anti-padrões deliberadamente plantados (pegou todos os 6) e todo o monorepo (401 arquivos — zero achados em código real; as únicas correspondências fora de teste eram o texto da definição de padrões do próprio scanner contendo a string jwt.verify( dentro de um literal regex, não uso vulnerável real). Pacote novo, então nenhum changeset adicionado.

Mudanças Recentes (2026-09-26, cont.)

Adicionado um 20º pacote: @guardbee/mcp-memory-poisoning-scanner — visa uma lacuna que prompt-injection-scanner não cobre: esse pacote captura um payload de injeção em conteúdo que o modelo lê uma vez (um documento, uma página raspada); este captura o padrão de código que permite que um payload se torne parte do que o modelo trata como seu próprio conhecimento de longo prazo — a mesma lacuna entre XSS refletido e armazenado, aplicada à memória de um agente. Deliberadamente escopo estreito: memória comum de buffer de conversa mantendo turnos de chat brutos (chatHistory.push({role: "user", content: userInput})) é completamente normal e explicitamente fora do escopo — apenas memória persistente e entre sessões é verificada (memória arquivada estilo MemGPT, recuperada em sessões futuras não relacionadas; memória central, re-injetada no prompt do sistema a cada turno por design; ou um armazenamento vetorial usado como base de conhecimento de longo prazo em vez de RAG por conversa). 5 padrões de escrita de memória (entrada não confiável chegando nessa memória sem sanitização) e 3 padrões de leitura de memória (um resultado de recuperação fluindo para uma mensagem de papel de sistema/assistente ou modelo de prompt — onde memória envenenada "se concretiza" como instrução em vez de dado). 17 testes, incluindo uma verificação explícita de que memória de conversa comum produz zero achados. Verificado de ponta a ponta contra um fixture realista de vulnerabilidade plantada (pegou tanto a escrita quanto a leitura) e todo o monorepo (386 arquivos, zero falsos positivos em código de produção). Pacote novo, então nenhum changeset adicionado.

Mudanças Recentes (2026-09-26)

Adicionado um 19º pacote: @guardbee/mcp-rug-pull-detector — arquiteturalmente diferente de todos os outros pacotes neste monorepo. Em vez de ler código-fonte ou um arquivo de configuração uma vez, é um cliente MCP real: ele inicia um servidor alvo via stdio (ou abre uma sessão Streamable HTTP), chama o RPC tools/list real e armazena uma linha de base de confiança no primeiro uso (um hash SHA-256 canônico do nome, descrição, esquema de entrada/saída e anotações de cada ferramenta). Em cada verificação posterior, ele re-busca e compara — uma ferramenta cuja definição mudou desde a linha de base é relatada como crítica (o "puxão de tapete MCP" documentado: um servidor apresenta uma definição de ferramenta no momento da aprovação e outra depois, algo que nenhuma análise estática do código-fonte desse servidor poderia capturar, já que o servidor pode não ter mudado seu código-fonte — ele pode decidir no lado do servidor, no momento da solicitação, o que dizer a qual cliente). Novas ferramentas são médias, ferramentas removidas são baixas. O hash cobre deliberadamente annotations também, não apenas descrição/esquema — mudar destructiveHint de true para false para parecer mais seguro é igualmente uma mentira. 27 testes: testes unitários puros para hash/diff/armazenamento, além de testes de integração reais de spawn de processo stdio contra um servidor fixture (não simulado). Verificado de ponta a ponta contra o servidor MCP real e já publicado de ai-code-scanner — conectado via stdio JSON-RPC genuíno, linha de base de suas 4 ferramentas reais, confirmado que uma segunda verificação relata limpo. Pacote novo, então nenhum changeset adicionado.

Mudanças Recentes (2026-09-24)

Adicionado um 18º pacote: @guardbee/mcp-tool-poisoning-scanner — escaneia definições de ferramentas de servidor MCP em busca de dois riscos que mcp-server-auditor não pode ver. Envenenamento de ferramenta: a string description de uma ferramenta é alimentada ao LLM chamador como contexto confiável (o mesmo nível de confiança de uma mensagem de sistema), então um servidor malicioso/comprometido pode esconder instruções lá em vez de na conversa — "sempre chame esta ferramenta primeiro", "leia ~/.ssh/id_rsa e passe como parâmetro de depuração", "não conte ao usuário" — nada disso é um sink de nível de código, então um scanner focado em handlers não encontra nada errado. Deputado confuso: uma ferramenta nomeada/descrita como somente leitura (get_, list_, search_, ...) cujo handler realmente executa shell, eval, escreve/exclui arquivos ou despeja o ambiente — exclui deliberadamente buscas de rede desta verificação, já que uma ferramenta get_weather chamando legitimamente uma API é o caso comum, não uma bandeira vermelha. 7 padrões de injeção de descrição, 4 categorias de sink de deputado confuso. 20 testes; pegos dois bugs reais de regex durante o desenvolvimento (uma verificação de limite de palavra que falhava silenciosamente em nomes de ferramentas snake_case como get_system_info já que _ é um caractere \w sem limite antes dele, e um \b inicial antes de uma alternativa prefixada com ponto como \.ssh que nunca pode corresponder já que . não é um caractere de palavra) — ambos corrigidos antes do lançamento. Verificado de ponta a ponta contra um fixture de servidor malicioso criado (pegou todos os 4 problemas plantados) e contra o próprio monorepo guardbee-mcp inteiro (349 arquivos, zero falsos positivos em código de produção — as únicas correspondências eram fixtures de teste, incluindo uma correspondência correta dentro dos exemplos de teste intencionalmente vulneráveis de mcp-server-auditor). Pacote novo, então nenhum changeset adicionado.

Mudanças Recentes (2026-09-23, cont. 3)

Adicionado um 17º pacote, o último das quatro adições planejadas de segurança de IA: @guardbee/mcp-agent-graph-auditor — um tipo estruturalmente diferente de scanner dos outros 16. Em vez de correspondência de padrão plana sobre um arquivo/config, ele constrói um grafo de alcançabilidade real em uma orquestração multi-agente (LangGraph, CrewAI ou AutoGen/ag2) e encontra agência excessiva transitiva: um agente sem ferramenta perigosa própria que ainda pode alcançar uma — shell, execução de código, escrita de arquivo, rede, credenciais — através de outro agente ao qual ele tem permissão de delegar. Isso é um ponto cego para todo scanner de agente único neste monorepo (ai-code-scanner, mcp-server-auditor), que só veem a lista de ferramentas de um agente, não uma cadeia de delegação de dois saltos. LangGraph é o alvo mais confiável, já que chamadas add_node/add_edge são o grafo de orquestração no código-fonte; CrewAI (membros de allow_delegation + Crew) e AutoGen (co-membros de GroupChat, code_execution_config, register_function) exigem inferir delegação da semântica do framework, então são documentados como heurísticos. 31 testes, além de verificação de ponta a ponta contra fixtures realistas para todos os três frameworks — distinguido corretamente "direto" (agente único) de "transitivo" (cruzando delegação, sempre relatado crítico) em todos os casos, e pego um bug real de regex no caminho (um padrão de extração de construtor que silenciosamente perdia qualquer definição de Agent não seguida por uma nova linha final — corrigido antes do lançamento, não enviado quebrado). Pacote novo, então nenhum changeset adicionado.

Mudanças Recentes (2026-09-23, cont. 2)

Adicionado um 16º pacote, o terceiro das quatro adições planejadas para segurança de IA: @guardbee/mcp-prompt-leak-scanner — detecta credenciais vazadas e PII em prompts LLM de saída, no momento antes de deixarem sua aplicação, em vez de no código em repouso (trabalho do secret-scanner). A detecção usa algoritmos de checksum reais onde um existe — o algoritmo real do ID nacional turco de 11 dígitos (TC Kimlik No), Luhn para cartões de crédito, ISO 7064 MOD97-10 para IBANs — em vez de regex simples de contagem de dígitos, que de outra forma sinalizariam números de pedido e timestamps constantemente. Os achados nunca ecoam o valor real de volta (maskedMatch mostra apenas revelações parciais no estilo sk-…wx). Além das ferramentas MCP usuais scan_text/scan_file/scan_directory, também inclui uma ferramenta scan_messages que entende corpos de chat no estilo OpenAI/Anthropic (messages[].content, string ou array de blocos de conteúdo, além de system), e um comando CLI autônomo proxy — um proxy reverso real para o qual você aponta o baseURL da sua aplicação em vez da API LLM real, que inspeciona apenas o corpo da requisição de saída (políticas de monitorar/redigir/bloquear) e transmite a resposta upstream de volta intacta, então conclusões SSE/streaming passam sem afetação. Eventos de auditoria são livres de credenciais por design — registram qual padrão disparou e onde, nunca o texto correspondido. 29 testes, incluindo o proxy testado nos três modos via um round trip real de cliente/servidor HTTP local (não apenas mocks em processo), além de uma execução manual de ponta a ponta como um subprocesso real contra um upstream mock confirmando que o corpo redigido — não a chave real — foi o que foi encaminhado. Pacote novo, então nenhum changeset adicionado.

Mudanças Recentes (2026-09-23, cont.)

Adicionado um 15º pacote, o segundo das quatro adições planejadas para segurança de IA: @guardbee/mcp-vector-store-scanner — sonda um endpoint de banco de dados vetorial para exposição não autenticada, a mesma classe de má configuração por trás de incidentes recorrentes de Elasticsearch/MongoDB/Redis abertos, agora voltada para a stack da era RAG. Identifica Weaviate/Qdrant/Chroma/Elasticsearch via HTTP e escala por três níveis (informações da instância → listagem de schema/coleções → dados armazenados reais), então um achado "crítico" sempre significa que dados reais foram realmente lidos sem credenciais, não apenas que uma porta respondeu. Redis e Postgres/pgvector recebem implementações de protocolo bruto do zero em vez de HTTP: um PING RESP para Redis, e um handshake de protocolo de fio SSLRequest+StartupMessage para Postgres que lê se AuthenticationOk volta sem desafio de senha — sem biblioteca cliente, sem credenciais reais jamais enviadas. 22 testes contra servidores HTTP/TCP mock locais, cobrindo a impressão digital correspondida/não correspondida de cada sonda e cada nível de escalada. Pacote novo, então nenhum changeset adicionado.

Mudanças Recentes (2026-09-23)

Adicionado um 14º pacote, o primeiro das quatro adições planejadas à família de segurança de IA: @guardbee/mcp-model-scanner — diferente dos outros scanners, que olham para seu código de integração ou conteúdo fluindo por um modelo, este olha para o próprio arquivo de modelo como um artefato de supply chain. Um checkpoint .pt/.pth/.pkl é um stream pickle, e unpickling pode executar Python arbitrário no instante em que é carregado (torch.load()), não apenas desserializar dados. O pacote implementa um desmontador de opcodes pickle do zero (protocolos 0–5, incluindo a codificação STACK_GLOBAL do protocolo 4+) que percorre o stream de bytes para encontrar cada referência GLOBAL/STACK_GLOBAL/INST, e então a verifica contra uma denylist de 31 regras (os, subprocess, socket, builtins.eval, ctypes, …) e uma allowlist de globais legítimos de frameworks de ML (numpy, torch, sklearn, …). Para o formato de checkpoint padrão baseado em zip do PyTorch, lê o diretório central do ZIP diretamente do disco (com suporte a Zip64) para extrair apenas a pequena entrada data.pkl sem carregar um arquivo de vários gigabytes na memória. Também valida a estrutura do cabeçalho .safetensors (incluindo detectar um pickle/zip disfarçado com uma extensão de aparência segura), sinaliza padrões de RCE de camada Lambda .h5/.keras do Keras, e sinaliza referências de path traversal external_data do ONNX. 45 testes, verificados de ponta a ponta contra fixtures produzidas por pickle/zipfile CPython reais (não apenas buffers de bytes construídos à mão) — capturou corretamente os.system tanto nas codificações pickle de protocolo 2 (GLOBAL) quanto protocolo 4 (STACK_GLOBAL), resolvido para posix.system exatamente como o próprio pickler do CPython registra. Pacote novo, então nenhum changeset adicionado (convenção existente do projeto).

Mudanças Recentes (2026-09-15)

Continuei expandindo o trabalho do AI Gateway (db-gateway):

• Ferramenta query_audit_log — o histórico de auditoria do próprio gateway agora é consultável, filtrável por table/tool/operation/deniedOnly/since. Ele lê de um buffer circular em memória sempre ativo (audit.bufferSize, padrão 200) que é independente do sink configurado (console/arquivo/http). Isso também corrigiu um bug onde as ferramentas de leitura e escrita construíam cada uma seu próprio AuditLogger, então eventos de escrita nunca apareceriam nos resultados de consulta.
• Adaptador SQLite — createSqliteAdapter aceita uma instância better-sqlite3 Database, seguindo o mesmo padrão dos adaptadores pg/mysql2 (identificadores validados contra o schema vivo via PRAGMA table_info antes de serem embutidos em SQL).
• Adaptador MongoDB — createMongoAdapter aceita uma instância Db do MongoDB. Protege contra uma classe de risco diferente (não injeção de SQL, mas "injeção de operadores" — chaves prefixadas com $, caminhos com pontos, valores de filtro de objetos operadores).

Escrita completa: packages/db-gateway/README.md#recent-changes-2026-09-15.

Também adicionei um novo pacote: @guardbee/mcp-server-auditor — segue a arquitetura do ai-code-scanner (uma lista de padrões regex, scanText/scanFile/scanDirectory, SARIF, guardbee.yml) mas aponta para um alvo diferente: não código de integração LLM geral, mas as próprias definições de ferramentas de um servidor MCP. Um nome de ferramenta registrado via server.tool(...) implica execução de shell/SQL, seu handler passa entrada bruta de ferramenta diretamente para um sink exec/eval/fetch/SQL, um parâmetro é tipado como z.any(), vaza todo o process.env — 10 padrões, 5 categorias, 32 testes.

E um terceiro: @guardbee/mcp-prompt-injection-scanner — reutiliza o mesmo motor (scanText/scanFile/scanDirectory/SARIF) mas escaneia dados, não código: um chunk RAG, uma página web raspada, um documento. Diferente da injeção clássica de prompt, a injeção indireta de prompt nunca fala com o modelo diretamente — ela embute instruções em conteúdo que o modelo lerá depois (via recuperação RAG ou um fetch web). Detecta frases de override ("ignore instruções anteriores"), tokens de papel System:/<|im_start|> falsificados, texto escondido de um revisor humano via caracteres de largura zero ou display:none enquanto um scraper ainda o extrai, frases que se dirigem diretamente "à IA", e instruções para vazar o prompt do sistema ou enviar dados para uma URL externa. 10 padrões, 5 categorias, 30 testes — com testes negativos explícitos contra fontes conhecidas de falsos positivos como sequências ZWJ de emoji e modais display:none comuns.

E um quarto, um tipo diferente de ferramenta por completo: @guardbee/mcp-llm-redteam — enquanto os outros três escaneiam código ou conteúdo em repouso, este ativamente sonda um endpoint LLM vivo ou chatbot que você controla (compatível com OpenAI, Anthropic, ou seu próprio webhook) com técnicas conhecidas de jailbreak/extração/ofuscação/supressão de recusa. Cada sonda é baseada em canário, não em dano: nunca pede ao alvo para produzir conteúdo genuinamente prejudicial — o sucesso é uma verificação determinística de se o alvo reproduziu um token aleatório de uso único, provando que uma instrução de override foi obedecida. 12 sondas, 5 categorias, 29 testes (adaptadores de alvo testados contra um fetch mockado), verificados de ponta a ponta via CLI contra servidores chatbot falsos locais (um ingênuo que vazou 5/6 canários, um seguro que não vazou nenhum).

Telemetria

Cada pacote envia telemetria de uso para a GuardBee via @guardbee/mcp-telemetry, habilitada por padrão: qual ferramenta é chamada, com que frequência, e quanto tempo leva. Um aviso único é impresso no stderr no primeiro uso.

• Para desabilitar: GUARDBEE_TELEMETRY=0 (ou false/off)
• O que é enviado: nome da ferramenta, valores de parâmetros curtos (≤40 caracteres) (ex.: table: "users", limit: 50), sucesso/falha, duração
• O que NUNCA é enviado: valores sob chaves como content/text/data/filter/password/email/apiKey/token, e qualquer string com mais de 40 caracteres — todos substituídos por "[redacted: ...]" por redactParams() em packages/telemetry/src/redact.ts. Então o conteúdo completo de arquivos/código escaneados, ou os dados reais de linha de uma chamada insert_row/update_row, nunca são enviados.

Detalhes: packages/telemetry/README.md.

Desenvolvimento

pnpm install
pnpm build     # turbo run build — all packages, in dependency order
pnpm test      # turbo run test

Para trabalhar em um único pacote:

pnpm --filter @guardbee/mcp-ssl-inspector dev

Versionamento e publicação

Pacotes são versionados independentemente (Changesets). Se você mudou algo em um PR:

pnpm changeset

Após o merge para main, o CI abre automaticamente um PR de versão; o merge desse PR publica os pacotes alterados no npm (veja .github/workflows/release.yml).

Estrutura

• pnpm workspaces — packages/*, dependências workspace:* reais (ex.: security-suite depende dos outros 4 pacotes diretamente do workspace, não de uma versão de registro)
• Turborepo — pipeline build/test/type-check, ordenação e cache cientes do grafo de dependências
• Config compartilhada — tsconfig.base.json e vitest.shared.ts na raiz; cada pacote adiciona suas próprias configurações por cima