Feedback da Comunidade sobre Segurança da Arquitetura do MarketNow
Esta é uma resposta consolidada a 11 comentários da comunidade em 6 artigos. Todos vocês levantaram pontos técnicos substanciais sobre a arquitetura de segurança do MarketNow. Aqui estão respostas diretas.
1. @mads_hansen — "cuidado ao chamá-lo de firewall até que a qualidade da detecção seja medida" (#4210477)
Você está certo. L1.9 não é um firewall — é um filtro de injeção de prompt. O nome "firewall" foi uma linguagem de marketing que eu não deveria ter usado. Aqui está a formulação honesta:
- L1.9 tem 32 regras de detecção em 10 categorias (jailbreak, substituição de função, exfiltração de dados, injeção de comandos, etc.)
- Cada regra é um padrão regex correspondido aos parâmetros de entrada da ferramenta MCP
- Taxa de falsos positivos: Eu ainda não tenho uma FPR medida. Esta é uma lacuna real — publicarei um benchmark com um corpus rotulado (limpo + adversarial) antes de chamá-lo de algo mais forte do que "filtro"
-
Linguagem de ferramenta de segurança legítima: várias regras correspondem a padrões que aparecem em ferramentas de segurança legítimas (por exemplo, "executar comandos do sistema" corresponde à documentação do
nmap). Isso é intencional — L1.9 é uma camada de aviso, não uma camada de bloqueio. O interceptador em tempo de execução (L3) toma a decisão real de bloqueio
Renomeando: L1.9 agora é "Filtragem de Injeção de Prompt" (não "firewall") na especificação.
2. @mads_hansen — "distinguir reavaliação periódica de monitoramento em tempo de execução" (#4192373)
Exatamente a distinção que estou construindo. A arquitetura:
- Reavaliação periódica (replay de sandbox L2.5, semanal via cron do GitHub Actions): detecta desvio de artefato, desvio de dependência, mudanças de catálogo, mudanças de permissão. Não pode detectar ataques em tempo de execução.
- Monitoramento em tempo de execução (interceptador L3, por chamada): vê cada chamada de ferramenta, bloqueia em tempo real. Pode detectar ataques em tempo de execução, mas não mudanças de metadados.
A lacuna que você identificou — "um ataque que ocorre entre as varreduras" — é exatamente o que o L3 fecha. O L3 roda em cada chamada da ferramenta MCP, não semanalmente. As 5 regras de política (bloquear .env, bloquear rm -rf, bloquear criação de processos, bloquear gravações no sistema, avisar sobre rede não permitida) executam em ~1ms por chamada.
O que o L3 NÃO faz ainda: detecção de desvio comportamental (detecção de anomalias estatísticas em padrões de chamadas). Isso é ATC-010 Runtime Trust, opcional na v1.0, planejado para v1.1.
3. @mayank609 — "certificação é necessária, mas sistemas de produção continuam mudando" (#4192373)
Concordo. A solução é a combinação de:
- ATC (certificado pontual, expira em 90 dias)
- L3 (interceptador em tempo de execução, cada chamada)
- Reauditoria contínua (cron semanal, reemite ATC se a habilidade passar)
O ATC NÃO é um certificado estático — ele expira. Se as dependências de uma habilidade mudarem entre as auditorias, a próxima auditoria a captura e o ATC é renovado (se limpo) ou revogado (se não). O TTL de 90 dias é uma salvaguarda — mesmo que a auditoria semanal falhe silenciosamente, o ATC expira.
4. @bogumi_jankiewicz — "eu construo gate.cat, um veto determinístico fail-closed na fronteira de execução" (#4192373)
Seu viés está correto — a camada mais interna é a que realmente para a execução. O L3 é exatamente isso: um interceptador determinístico fail-closed que roda antes de cada chamada da ferramenta MCP. Se o L3 disser "bloquear", a chamada nunca é executada.
A questão chave: o L3 deve estar em processo (interceptando a chamada JSON-RPC antes de chegar à ferramenta) ou na fronteira de execução (interceptando a chamada de sistema real)? Atualmente, o L3 está em processo (camada JSON-RPC). Para uma aplicação verdadeira na fronteira de execução, você precisa de:
- sandbox gVisor (L2.5 faz isso —
--network none,--read-only,--cap-drop ALL) - seccomp + AppArmor (camada do kernel Linux)
- veto de execução estilo gate.cat (se você quiser integrar, me envie um e-mail)
5. @mads_hansen — "assinar o registro de chaves" (#4181753)
Você sugeriu assinar o registro de chaves para que um verificador com um registro em cache possa detectar a rotação de chaves. Concordo — este é o campo ca_key_id que acabei de adicionar (veja o artigo sobre a correção de barra). Cada cartão agora carrega ca_key_id (primeiros 16 caracteres da chave pública CA). O verificador pode:
- Buscar a chave CA atual em
/api/atc?action=ca-key - Comparar
ca_key_idno cartão com o ID da chave atual - Se diferirem, o cartão foi assinado sob uma chave anterior — buscar a chave antiga no registro de chaves (planejado para v1.1)
O registro de chaves assinado está no roadmap da v1.1.
6. @mads_hansen — "verificações de proveniência antes da importação" (#4162091)
O MarketNow já faz isso no L1.5 (análise de metadados) — comparamos a URL do repositório com a fonte canônica do GitHub. Se um pacote for enviado de um fork que difere do original, o L1.5 sinaliza.
O que ainda não fazemos: geração de SBOM (Software Bill of Materials). Você está certo que comparar a fonte do pacote com o artefato de construção canônico é a abordagem correta. Vou adicionar a geração de SBOM à camada L1.6 (Semgrep + varredura de dependências OSV já está em execução, mas não produz um SBOM CycloneDX). Planejado para v5.1.
7. @neelagiri65 — "pacotes assinados mais um sandbox em tempo de execução, não apenas um postmortem" (#4162091)
Concordo. O MarketNow tem ambos:
- Pacotes assinados: ATC (Agent Trust Card) com assinaturas Ed25519
-
Sandbox em tempo de execução: L2.5 (gVisor —
--network none,--read-only,--cap-drop ALL) - Interceptador em tempo de execução: L3 (5 regras de política, fail-closed, ~1ms por chamada)
O artigo postmortem foi sobre o trojan que passou antes de eu construir essas camadas. Desde então: 80 habilidades em quarentena, 1.030 ameaças detectadas, 1,2M verificações realizadas. As camadas em tempo de execução são as que realmente capturam coisas — as camadas estáticas (L1.5-L1.9) são a triagem.
8. @nazar_boyko — "camadas 3 e 4 são correspondência de padrões, que é exatamente onde os atacantes evitam" (#4153510)
Correto. L1.7 (padrões de malware) e L1.8 (assinaturas de famílias de malware) são correspondência de padrões baseadas em regex. Eles capturam famílias de malware conhecidas, mas NÃO zero-days. Aqui está a resposta honesta sobre o que cada camada captura na prática:
| Camada | O que captura na prática | O que perde |
|---|---|---|
| L1.5 Metadados | README ausente, repositórios arquivados, sem licença | Repositórios maliciosos com bons metadados |
| L1.6 Semgrep + OSV | Vulnerabilidades conhecidas (correspondidas CVE), segredos hardcoded | Vulnerabilidades zero-day, segredos ofuscados |
| L1.7 Padrões de malware | Launchers binários, scripts de instalação suspeitos | Malware polimórfico, ataques sem arquivo |
| L1.8 Famílias de malware | 48 assinaturas equivalentes a YARA | Novas famílias de malware não no DB |
| L1.9 Injeção de prompt | 32 padrões de jailbreak conhecidos | Técnicas de injeção novas |
| L2.5 sandbox gVisor | Comportamento em tempo de execução (chamadas de rede, gravações de fs, criação de processos) | Ataques que não acionam comportamento observável |
| L3 Interceptador |
.env leituras, rm -rf, criação de processos |
Ataques via chamadas com aparência legítima |
As camadas que REALMENTE capturam coisas na prática (com base nas 80 habilidades em quarentena):
O artigo discute a segurança em sistemas que utilizam agentes de IA, um aspecto crucial para empresas que buscam proteger suas operações. A implementação de camadas de segurança pode impactar diretamente a confiança e a integridade dos serviços oferecidos.
