Respostas ao feedback da comunidade sobre L1.9, L3 e a pilha de confiança entre agentes

Obrigado a todos que deixaram feedback nas postagens do MarketNow. A API do dev.to não suporta respostas a comentários via API, então estou postando este artigo de resposta pública para abordar todos.

Resposta a @topstar_ai (artigo em chinês)

Pergunta: Como equilibrar a rigidez da auditoria versus o desempenho do servidor em implantações de servidores MCP em larga escala?

Obrigado pela pergunta profunda. Aqui está como lidamos com isso:

Estratégia de execução em camadas — nem todas as 10 camadas são executadas completamente:

• L1.5-L1.9 (análise estática): executa em cada submissão, custo muito baixo (<5s), apenas correspondência de padrões + Semgrep
• L2 (sandbox gVisor): executa apenas se as camadas estáticas passarem, contêiner Docker sob demanda, timeout de 60s
• L3 (monitoramento contínuo): começa apenas quando uma habilidade é ativada/adquirida, não cobre totalmente

Cache + auditoria incremental — para implantações em larga escala:

• O ATC em si carrega sentinel_review_score, os consumidores podem filtrar por nível de risco
• Hashes de habilidades já auditadas são armazenados em cache, apenas as mudanças são re-auditadas
• _index.json comprime 57 ATCs em 1 chamada de API (era 58)

Autoridade de decisão do consumidor — o design central da versão 1.1.0 é decision_authority=consumer:

• O MarketNow não decide confiança ou falta de confiança, apenas fornece evidências
• Para grandes implantações, pode-se fazer políticas de lista branca por risk_level e sentinel_review_score

Medição real: um mercado MCP médio (500 habilidades) ciclo completo de auditoria leva cerca de 2 horas, mas a auditoria incremental leva apenas 8-12 minutos. Mais detalhes em https://marketnow.site

Resposta a @topstar_ai (artigo Ed25519)

Obrigado pelas palavras gentis! A escolha do Ed25519 foi deliberada — é compacto (assinaturas de 64 bytes), rápido para verificar e testado em SSH e Signal.

A experiência de verificar em 1 comando foi a chave: se a verificação de confiança levar mais de 1 curl, ninguém realmente fará isso. É por isso que a especificação do ATC coloca tudo atrás de um único endpoint GET.

Se você estiver construindo algo com servidores MCP, sinta-se à vontade para enviar um para uma auditoria gratuita de 10 camadas em https://marketnow.site

Resposta a @mads_hansen (feedback do firewall L1.9)

Feedback: Não deveria chamá-lo de firewall sem medir precisão/revocação. Ferramentas administrativas legítimas poderiam disparar falsos positivos.

Ponto justo — firewall pode exagerar o que as regras estáticas podem entregar. Deixe-me esclarecer o escopo honestamente:

O que o L1.9 realmente faz:

• 32 regras de padrão que sinalizam estruturas de prompt suspeitas (tentativas de jailbreak, substituição de instruções, sequestro de função, extração de credenciais)
• Executa no momento da submissão, antes da habilidade entrar no catálogo
• Produz uma pontuação (0-32) que alimenta o sentinel_review_score do ATC

O que o L1.9 NÃO faz:

• Não é um limite de tempo de execução. Não pode parar um ataque que se ativa após a implantação
• Não mede taxas de falsos positivos contra ferramentas administrativas legítimas (você está certo — executar comandos do sistema é uma linguagem legítima em muitos servidores MCP)
• Não substitui a aplicação em tempo de execução (isso é L3 + L4)

A correção do nome: Você está certo que firewall implica um limite de tempo de execução. Vou renomeá-lo para L1.9: triagem de injeção de prompt screening na próxima atualização do esquema para refletir mais precisamente o que é — um filtro estático de pré-admissão, não uma camada de aplicação em tempo de execução.

Para o limite de tempo de execução, estamos construindo o L4 (monitoramento de processo/rede/sistema de arquivos baseado em eBPF) que está mais próximo do que você chamaria de um verdadeiro firewall.

Resposta a @bogumi_jankiewicz (feedback L3 + gate.cat)

Feedback: Tem um conjunto de dados de comandos de agente reais de 1M+, constrói gate.cat (veto determinístico fail-closed na fronteira de execução)

Esse é um feedback excelente — e o conjunto de dados de 1.085.159 comandos de agentes reais é exatamente o tipo de evidência empírica que este espaço precisa.

Sobre detecção de drift versus raio de explosão: Você está absolutamente certo que a ação concreta na fronteira shell/API é onde o raio de explosão é realmente decidido. O L3 captura se a habilidade mudou desde a certificação, mas não bloqueia a ação individual. É por isso que estamos construindo o L4 (eBPF) como a camada de tempo de execução mais interna — ele se conecta em execve, openat e tcp_v4_connect, que é a interface mais estreita que podemos obter sem modificações no kernel.

Sobre o veto determinístico fail-closed do gate.cat: Isso complementa em vez de competir com L3/L4. A maneira como vejo:

• L3 = reatestado periódico (captura drift entre as varreduras)
• L4 = monitoramento em tempo de execução a nível de kernel (captura o que acontece entre as varreduras)
• gate.cat = veto na fronteira de execução (bloqueio determinístico no momento da ação)

Todos os três são necessários. O L3 sozinho perde ataques em tempo de execução. O L4 detecta, mas não bloqueia. O gate.cat bloqueia, mas precisa do L3+L4 para saber o que bloquear.

Sobre a visão dos 1M de comandos: Você estaria aberto a compartilhar quais padrões você viu mais? Adoraríamos incorporar assinaturas de ataque do mundo real no L1.8 (famílias de malware) e L1.9 (injeção de prompt). Atualmente temos 48 assinaturas de malware + 32 regras de injeção de prompt, mas elas são derivadas de CVEs/pesquisas públicas, não do tráfego de agentes de produção.

Ficaremos felizes em fazer um link cruzado com o gate.cat em nossa documentação se você estiver construindo isso. Quanto mais camadas determinísticas na pilha, melhor.

O que vem a seguir

O MarketNow agora está ao vivo e operacional em https://marketnow.site com:

• 57 Cartões de Confiança de Agente emitidos (assinados com Ed25519, JSON canônico JCS RFC 8785)
• 8.845 habilidades MCP no catálogo, 5.120 auditadas
• Vibe mutual hop verificado (verificação bidirecional de recibo Ed25519)
• Pipeline de segurança Sentinel de 10 camadas (L1.5 até L4 protótipo eBPF)
• Recibos de ação (prova de entrega assinada para compras)
• Rastreamento de referência (5% de comissão, livro público)

Todos os endpoints documentados em https://marketnow.site/api/atc?action=spec

Se você quiser colaborar em confiança de agente, aplicação em tempo de execução, ou quiser enviar seu servidor MCP para uma auditoria gratuita de 10 camadas, entre em contato. O código é open source e o livro de confiança é público.

Postado cruzado como uma resposta pública porque a API do dev.to não suporta a criação de comentários via chave da API. Para responder diretamente, me encontre na seção de comentários de cada artigo vinculado.