Saltar para o conteúdo principal
Um “rug-pull” é um servidor MCP que muda suas definições de ferramenta depois que você o aprovou — redefinindo uma ferramenta confiada para fazer algo novo, ou silenciosamente adicionando uma. O OrcaRouter pega isso na camada de schema: ele baselina o conjunto de ferramentas anunciado de cada servidor e o re-checa em cada carregamento, de modo que o drift falha fechado em vez de servir silenciosamente as ferramentas alteradas. Esta página é a referência para o status de schema por servidor e o que cada estado significa para o tráfego.

​
1. O fingerprint da baseline

No primeiro contato o gateway computa um hash canônico do conjunto de ferramentas anunciado do servidor e o armazena como a baseline aprovada:
  • O hash cobre o nome, a descrição e o JSON schema de input de cada ferramenta — exatamente a superfície que um rug-pull alteraria (uma ferramenta ganhando um argumento de exfiltração, ou uma descrição weaponizada para injeção de prompt vira o hash).
  • Ele é independente de ordem: um servidor re-ordenando sua lista de ferramentas, ou re-ordenando chaves dentro de um schema, não parece uma mudança. Apenas uma mudança real de definição move o hash.
Em cada probe posterior o gateway re-faz hash das ferramentas ativas e as compara à baseline armazenada. Esta é uma checagem por servidor — ela não depende de nenhuma regra que você crie.

​
2. O ciclo de vida do status de schema

Cada servidor registrado carrega um schema_status. Os estados e como eles afetam se as ferramentas do servidor são servidas:
StatusSignificadoFerramentas servidas?
(não baselined)Primeiro uso — nenhuma baseline registrada ainda.Postura de descoberta: Sim (trust-on-first-use — o schema atual é capturado como a baseline). Postura estrita: Não — veja pending abaixo.
verifiedO schema ativo corresponde à baseline aprovada.Sim
changedDrift detectado — o schema ativo difere da baseline.Não — falha fechado
pendingUm servidor não baselined sob uma postura estrita (sem trust-on-first-use) — aguardando aprovação.Não — falha fechado
quarantinedUm admin reteve o servidor.Não — falha fechado
Os três estados fechados — changed, pending, quarantined — todos impedem que as ferramentas do servidor sejam servidas através do gateway. verified sempre serve; um servidor não baselined serve apenas sob a postura de descoberta (trust-on-first-use) e é retido como pending sob a postura estrita. O drift nunca passa silenciosamente.

​
3. O que acontece no drift

Quando uma re-checagem descobre que o schema ativo não corresponde mais à baseline:
1

O status vira changed

O schema_status do servidor torna-se changed e o timestamp do drift é registrado.
2

As ferramentas deixam de ser servidas

O gateway falha fechado: as ferramentas desse servidor são retidas da superfície MCP unificada, de modo que um agente não pode chamar as definições alteradas.
3

O console o expõe

O drift aparece para revisão de modo que um admin possa comparar o novo conjunto de ferramentas com o aprovado.
4

Re-baselinar ou colocar em quarentena

Um admin aprova o novo schema (re-baselina — o conjunto de ferramentas atual torna-se a nova baseline verified) ou coloca em quarentena o servidor. Até que uma dessas coisas aconteça, o servidor permanece fechado.

​
4. Re-aprovando um servidor com drift

O re-baseline é uma única chamada (ou a ação de console): 
POST /api/workspace/firewall/mcp_servers/:id/approve_schema
Exige o papel de Developer. Ele registra o conjunto de ferramentas ativo como a nova baseline aprovada e retorna o servidor a verified. (Colocar um servidor em quarentena é uma ação separada, para quando você decide que a mudança é hostil — approve_schema apenas re-baselina para verified.) A ação é escrita na trilha de auditoria.
Re-aprove apenas depois de ter revisado o diff. Aprovar um schema com drift sem checá-lo derrota o controle — diz ao OrcaRouter que as novas (possivelmente maliciosas) definições de ferramenta são confiadas.

​
5. Onde isso se encaixa

A detecção de drift de schema é a metade da camada de schema da defesa contra rug-pull; a outra metade é a avaliação por chamada na superfície mcp (cada tools/call é checado contra sua política no dispatch). Juntas elas cobrem tanto “as definições mudaram” quanto “esta chamada específica é perigosa”.

Defesa contra rug-pull

O panorama completo do rug-pull — baseline de schema mais avaliação por chamada.

Visão geral de segurança MCP

O gateway MCP, as skills e as credenciais.

Envenenamento de ferramentas MCP

A ameaça contra a qual esta máquina de estados defende.

Eventos de auditoria MCP

Monitorando mudanças de schema e decisões do gateway.