1

Boa pergunta — você tocou num ponto real.

Hoje o Snitch já diferencia na atribuição: a aba de processos mostra a linha de comando completa e a cadeia de pais, então node /…/mcp-server.js aparece distinto de outro node qualquer.

Mas as regras de bloqueio casam por executável — é a mesma limitação do WFP ALE_APP_ID no Windows e do owner match do iptables: a camada de kernel filtra por identidade do binário, não por argv. Ou seja, liberar node hoje libera tudo que roda nele — exatamente o problema que você descreveu com npx/uvx.

O caminho honesto que eu vejo:

  • Regras de alerta por cmdline (regex): viável já — cada spawn do npx gera um PID novo com argv distinto, resolvemos PID→cmdline no momento do evento e cacheamos
  • Bloqueio por cmdline: aplicável no caminho de veredito em userspace (NFQUEUE/ask-mode no Linux); no Windows o WFP não expõe argv, seria resolução por PID — mais frágil mas possível
  • Parent process matching: a cadeia já é coletada, falta expor como campo de regra

Ressalva honesta: argv é controlável pelo próprio processo, então é heurística boa pra distinguir agentes/MCPs, não fronteira de segurança rígida. Pra isso o ideal seria eBPF/cgroup no Linux — já temos eBPF no roadmap.

Abri a issue #61 pra trackear: github.com/aixisstudio/Snitch/issues/61 — valeu pelo olhar afiado, é exatamente o tipo de feedback técnico que a gente precisa.

Carregando publicação patrocinada...
1

valeu por abrir a issue. no Linux tem um meio-termo antes do eBPF que talvez ajude: subir cada servidor MCP no próprio scope com systemd-run --user --scope e casar a regra pelo cgroup (o iptables tem -m cgroup --path no cgroup v2, e o nftables tem socket cgroupv2). aí o node de um MCP e o node do outro ficam separados sem depender do argv, que o próprio processo consegue mudar. o lado chato é que depende de como o cliente sobe o processo, então ia precisar de um wrapper no comando do MCP.