O que está provado, e o que não está.
Uma afirmação de segurança que não dá para refutar não é uma afirmação, é publicidade. Esta página declara o nível de evidência de cada perfil com as mesmas palavras que o plano interno usa, para que alguém de fora possa confrontá-lo com o que foi publicado.
Os quatro níveis
Cada pacote de trabalho fecha declarando um deles, ao lado de PASS, FAIL ou SKIP e dos denominadores. Não há um quinto nível nem um meio-termo confortável.
projetoEspecificado e revisado. Nada foi executado. Descrever como algo funcionaria nunca vale um PASS.
simuladoExecutado contra fixtures, com o provedor e as aprovações identificados como fixtures. Não é uma integração e nunca é descrito como tal.
integração realExecutado contra um provedor real, numa conta autorizada, para o perfil exato que foi testado — e só para ele.
não avaliadoNenhuma probe rodou. É o valor padrão, não um esquecimento, e nunca conta como aprovado.
Provado hoje
As regras acima existem para manter esta lista honesta, não para não ter nenhuma. Cada ponto é uma propriedade do código, conferível sem perguntar para a gente.
Uma autorização se consome uma única vez
O uso único é um literal de tipo no esquema do grant, e qualquer outro valor é rejeitado na validação. Não é um contador que alguém lembrou de decrementar.
Os receipts verificam sem rede
Não há nenhuma chamada de rede em todo o caminho de verificação. Um receipt conferido daqui a cinco anos não depende de a gente estar no ar, nem de um registry mutável.
Um adaptador não pode redefinir o que foi concedido
O cliente do provedor recebe o efeito e uma chave de idempotência. Nunca recebe o grant nem a autoridade, então não tem nada para ampliar.
Uma mutação nunca é repetida às cegas
A reconciliação é a única segunda chamada a um provedor. Se a própria reconciliação falha, o resultado é registrado como indeterminado em vez de presumido.
A nuvem não pode ampliar o teto local
A checagem de política local é deny-only e fixa tenant, gateway, provedor, digest do adaptador, autoridade, versões de política aceitas, regras de recursos e limites monetários. Exige que haja uma política local assinada instalada, sem a qual o modo produtivo se recusa a iniciar.
Duas dessas dependem do deployment: o teto local precisa de uma política assinada instalada — em sandbox sem política não há teto — e o isolamento de credenciais depende do conector e do modo de deployment escolhidos.
As regras que a tornam refutável
- SKIP e não avaliado nunca contam como PASS.
- Uma rota sem probe fica não avaliada. Não herda a cobertura de outra rota.
- O manifesto de cobertura é uma afirmação que o harness de teste precisa poder refutar: se um bypass consegue um efeito, a cobertura declarada vira contradita e o gate falha, mesmo onde o arquivo diga protegido.
- A aplicabilidade é fixada antes de o runtime existir. Nada pode ser marcado como não aplicável depois de falhar.
- Testar um conector com MFA ou quórum não credita um perfil delegado de vários passos. Cada afirmação nomeia a cadeia e as versões que testou.
- Fixtures de aprovação não são MFA nem quórum reais, e uma aprovação simulada nunca é apresentada como humana.
O que um receipt estabelece
Um Action Receipt prova o que passou por um Guardian inscrito e o resultado que esse Guardian conseguiu estabelecer. Um timeout é reconciliado relendo do provedor, nunca repetido às cegas, e um resultado ambíguo fica indeterminado em vez de ser arredondado para sucesso.
Ameaças nomeadas
As que mitigamos, com as brechas ainda abertas.
Tool poisoning
Um host altera as descrições das tools para que o modelo as chame com argumentos manipulados. O catálogo de tools é autoritativo do servidor — o servidor serve uma lista fixa e não aceita definições de tools vindas do cliente — e uma allowlist limita o que cada cliente pode invocar. Brecha aberta: o manifesto servido ainda não é assinado, então sua integridade depende do transporte.
Host ou cliente hostil
O processo que orquestra o agente é ele mesmo hostil. Scopes e a allowlist de tools limitam o dano, cada chamada é auditada e as chaves se revogam de imediato. Brecha aberta: uma API key é uma credencial ao portador, então um host hostil que tenha uma age como o tenant até ser revogada. Tokens delegados de vida curta existem para estreitar isso.
Prompt injection pelo conteúdo analisado
Uma mensagem tenta injetar instruções através do conteúdo que está sendo analisado. O guard classifica e analisa; não executa o que lê, e a resposta carrega fatos extraídos em vez de instruções. Um efeito fora do contrato é recusado, tenha algum detector visto a injeção ou não.
Mudança de catálogo depois da revisão
O que você aprovou não é o que sobe depois. Um snapshot fixado é comparado com o catálogo atual e uma mudança material pede revisão em vez de se aplicar sozinha.
Falsificação num diretório
Um terceiro publica um anúncio falso. O endpoint canônico e o manifesto são servidos pelo próprio serviço. Brecha aberta: ainda não há assinatura de manifesto publicada nem verificação de domínio.
Fora da garantia
Nomeado, não insinuado.
- O administrador do host. Quem controla a máquina controla o que roda nela.
- Um Guardian ou uma chave de assinatura comprometidos.
- As ações tomadas fora do caminho de execução inscrito. Sobre elas o receipt silencia por construção.
- Um canal lateral que ninguém observou.
- O dano que o mandato aprovado já permitia. Autorizar não prova verdade, benignidade nem correção.
- A propriedade legal da conta do provedor, que nenhum receipt estabelece.
Não há observação universal
Não existe visão do contexto inteiro de um host, do seu e-mail, da sua memória ou do tráfego de outros servidores MCP. O que se conhece é o catálogo próprio do bridge, as chamadas que passam por ele e os snapshots importados explicitamente. Um hash de configuração descreve um perfil; não é uma atestação criptográfica do host. Um contêiner sozinho, sem demonstrar sua rede e seus mounts, não prova isolamento.
Sobre assinaturas
A assinatura de um manifesto atesta integridade e procedência. Não atesta benignidade, e nenhum selo — incluindo o nosso — torna seguro um servidor MCP.
Como muda uma afirmação desta página
Não é editando. Uma nova afirmação de capacidade é verificada contra o código e datada antes de aparecer, e a tabela de verificação vive no repositório ao lado do texto. Uma página que falhou numa checagem mantém a falha à vista em vez de ser reescrita em silêncio — uma rodada posterior cria uma nova versão em vez de substituir o resultado anterior. Não há bug bounty financiado nem auditoria independente de terceiros, e nenhuma das duas será anunciada antes de existir.
Estado desta página
Os níveis de evidência e as regras acima valem hoje. A tabela por perfil vai publicar os resultados observados de cada pacote de trabalho conforme forem fechando, com denominadores, versões e configuração. Até um perfil ter um resultado próprio contra um provedor real, ele figura como simulado ou não avaliado — nunca extrapolado de um mock nem de outro conector.