Saltar para o conteúdo principal
Cada servidor MCP que você registra, cada skill que um agente instala e cada host que uma ferramenta alcança é uma dependência que você não escreveu. A cadeia de suprimentos de um agente é dinâmica — ela cresce em runtime, frequentemente sem um humano no loop — então o modelo clássico de “revise o lockfile no momento do build” não se sustenta. Uma skill da comunidade pode ser sequestrada depois que você confia nela; um servidor MCP remoto pode silenciosamente adicionar uma ferramenta; uma ferramenta de fetch pode ser direcionada para um host controlado pelo atacante. A resposta do OrcaRouter é governar a cadeia de suprimentos onde ela age — no gateway, no primeiro uso — em vez de tentar avaliar cada dependência no momento da instalação. Esta página é a landing de caso de uso para ai supply chain security; as referências do Firewall e de Skills carregam a mecânica completa.

​
1. Segurança de cadeia de suprimentos de ia para agentes, no gateway

O ponto de estrangulamento é o caminho de relay. Quer uma capacidade tenha sido registrada à mão, auto-instalada pelo agente ou puxada de um registry da comunidade, sua primeira chamada de ferramenta cruza api.orcarouter.ai — e é aí que o Firewall a avalia. Quatro controles compõem em uma única postura:

Gateway MCP, eval por chamada

Cada tools/call é avaliado contra sua política antes do dispatch — o manifesto nunca é a fonte da verdade.

Risk-bands e quarentena de skill

Capacidades instaladas são escaneadas, pontuadas e retidas para revisão até que um humano as aprove.

Credenciais MCP criptografadas

Segredos de auth de servidor são criptografados em repouso e injetados no dispatch — nunca expostos ao modelo, ao agente ou aos argumentos de chamada.

Allow-lists de egress

Fixe para onde chamadas de ferramenta podem enviar dados, para que uma dependência comprometida não possa exfiltrar para um host que você nunca aprovou.
A detecção é no gateway, no primeiro uso — não no seu gerenciador de pacotes ou sistema de arquivos. Isso é deliberado: é o único caminho que vê cada agente e cada chamada de ferramenta independentemente de como a capacidade chegou ali.

​
2. A ameaça: uma dependência que cresce depois que você confia nela

VetorO que acontece
Rug-pullUm servidor MCP registrado adiciona uma ferramenta (shell.exec, um novo fetch) que você nunca aprovou.
Skill creepUma skill instalada usa ferramentas ou hosts que seu manifesto nunca declarou.
Roubo de credencialA implementação de ferramenta de um servidor comprometido lê seu próprio segredo de auth para ligar para casa.
Exfiltração de egressUma cadeia retrieve→send envia seus dados para um host controlado pelo atacante.
A causa raiz comum: “eu confio neste servidor” é tratado como permanente, e o agente continua chamando ferramentas novas ou modificadas sem revisão adicional.

​
3. Um exemplo concreto — registrando e fixando um servidor MCP

Você registra um servidor MCP de terceiros a partir do console (Settings → Firewall → MCP servers; escritas precisam de Developer+). O segredo de auth do servidor é armazenado criptografado — você o fornece uma vez, o gateway o injeta no dispatch, e ele é mascarado em cada leitura depois disso. Um registro de servidor MCP carrega:
CampoValores
auth_modenone, bearer, oauth, basic
statusok, degraded, down (definido pela sonda de saúde)
credentialscriptografadas em repouso, nunca retornadas em texto plano
Após registrar, faça a sonda dele a partir do console para enumerar suas ferramentas atuais. A sonda é uma operação de sessão-de-workspace (/api/workspace/firewall/*) que precisa de Developer+, não uma chave de relay — registrar, sondar e escrever regras tudo acontece no plano de gerenciamento: 
# Console / management plane — workspace session, Developer+.
# (The relay sk-orca-... key is for /v1/* traffic only.)
curl -X POST https://api.orcarouter.ai/api/workspace/firewall/mcp_servers/<id>/probe \
  -H "Authorization: Bearer <workspace-session-token>"
A sonda persiste a alcançabilidade do servidor e tira um snapshot de um hash de baseline do seu conjunto de ferramentas anunciado (trust-on-first-use). Então dê escopo a uma regra de Firewall com tool_name_glob: <server>.* para pending_approval até você ter visto um histórico de chamadas limpo — cada chamada daquele servidor é retida para um humano antes de rodar. Assim que você confiar nele, relaxe a regra para audit ou allow. A partir desse ponto o gateway MCP avalia cada tools/call na superfície mcp antes do dispatch — então se um rug-pull mais tarde adicionar uma ferramenta não declarada, sua política, não o manifesto do servidor, decide se ela roda.
Re-sonde após qualquer bump de versão upstream (POST /api/workspace/firewall/mcp_servers/:id/probe, Developer+). Se o conjunto de ferramentas anunciado desviar da baseline aprovada, o schema_status do servidor muda para changed e o dispatch falha fechado até que um admin re-baselinize (approve_schema) ou o quarentene — o rug-pull não pode entrar em ação silenciosamente.

​
4. Risk-bands e quarentena de skill

Cada capacidade instalável — quer você a tenha registrado ou o gateway a tenha auto-detectado em runtime — passa pelo scanner de skills. Os achados se agregam em uma risk band e um modo de enforcement:
low · medium · high · critical. A band é derivada de passagens determinísticas do scanner sobre o manifesto e os escopos declarados (uso de ferramenta não declarado, egress de rede fora dos escopos aprovados, escritas de sistema de arquivos inseguras, texto de manifesto em formato de injeção).
allow (suas regras de política decidem), quarantine (qualquer veredito não-deny escala para pending_approval — um humano aprova cada chamada), block (força deny em todas as ferramentas desta skill independentemente das regras). Uma skill de band high quarentena automaticamente; critical bloqueia.
Uma capacidade que um agente auto-instala, ou uma ferramenta que um rug-pull adiciona, é retida em pending_approval independentemente de sua pontuação de scan até que um humano a revise. Um operador não pode adicionar silenciosamente uma ferramenta e fazer seus agentes começarem a usá-la.
O modo de enforcement só aperta, nunca relaxa — aprovar uma skill nunca afrouxa um block que um scan recente definiu.

​
5. Allow-lists de egress — contenha o “ligar para casa”

O resultado mais danoso de cadeia de suprimentos é uma dependência comprometida que exfiltra. A superfície egress do Firewall avalia o destino outbound (host / IP / CIDR) que uma ferramenta reporta, para que você possa fixar para onde dados têm permissão de ir. Você escreve uma regra de egress você mesmo: uma allow-list de host/CIDR com um predicado cidr_match nega tudo fora da lista. Combine-a com uma regra de sequência que quebra a cadeia retrieve→egress, e uma ferramenta envenenada que tenta enviar um documento recuperado para um host desconhecido é negada no gateway.
O nível de autonomia tight traz um preset SSRF, mas ele nega nomes de ferramenta em formato de fetch (http_fetch, web_search, fetch_url, request) — ele não é uma denylist de CIDR/cloud-metadata. Se você precisa de bloqueio de egress de RFC-1918 / metadata / CIDR específico, escreva a regra de deny de host/CIDR de egress você mesmo. Veja Firewall: Regras para o operador cidr_match e o escopo de egress.

​
6. Credenciais criptografadas — um servidor comprometido não pode ler suas chaves

Segredos de auth de servidor são criptografados em repouso e injetados pelo gateway no momento do dispatch. Eles nunca chegam ao modelo, ao agente ou aos argumentos de chamada de ferramenta — então um servidor comprometido ou malicioso não pode exfiltrar suas chaves de API lendo seu próprio blob de credencial. O console sempre retorna o segredo mascarado — mesmo para um Admin. O valor descriptografado é entregue em exatamente um caminho: uma requisição portando um token com escopo de firewall-gateway (um tipo de token dedicado que um Admin explicitamente cunha para o gateway/proxy), de modo que uma chave de relay vazada comum não pode enumerar suas credenciais MCP.

​
7. Agregando para uma auditoria

A governança de cadeia de suprimentos é também um artefato de auditoria. O OrcaRouter mapeia para o OWASP Top 10 para Aplicações de LLM — incluindo o controle LLM05 Supply Chain — como parte do motor de compliance, ao lado de frameworks como soc2, iso_27001, iso_42001, nist_ai_rmf e o eu_ai_act. Instalar um compliance pack (POST /api/compliance/packs/:key/install, Admin de workspace, plano pago) materializa os guardrails e políticas de firewall correspondentes e começa em uma postura observe-first. Relatórios de compliance incluem uma seção de evidência de cadeia-de-suprimentos-de-IA — os provedores upstream para os quais seu workspace realmente roteou, mais uma revisão de acesso-privilegiado e higiene-de-chave — e são assinados com Ed25519 e publicamente verificáveis. Navegar no catálogo e na prontidão é gratuito para qualquer Member; veja Compliance para o ciclo de vida completo.
A governança de MCP são duas camadas complementares: avaliação de firewall por chamada na superfície mcp (enforcement sobre o que uma dependência faz), mais uma baseline de integridade de tool-schema (hash trust-on-first-use do conjunto de ferramentas anunciado, re-checado em cada sonda — drift muda o schema_status do servidor para changed e faz o dispatch falhar fechado até que um admin re-baselinize ou o quarentene). Junto com risk-bands e quarentena de skill, isso é enforcement tanto sobre o que uma dependência faz quanto um registro verificável do que ela declarou.

​
8. Uma baseline de cadeia de suprimentos

Registre-o, sonde seu conjunto de ferramentas e dê escopo a uma regra <server>.* para pending_approval ou audit. Leia os achados do scan — qualquer achado de ferramenta-não-declarada ou egress-externo é uma razão para mantê-lo quarentenado. Verifique quem controla a URL do endpoint.
Mantenha uma allow-list de egress fixada para qualquer agente com ferramentas de fetch/search/export. Observe a view de Ferramentas descobertas para capacidades que apareceram sem uma regra, e o feed de anomalias para caminhos ferramenta-a-ferramenta inéditos.
Desabilite o servidor (PUT .../mcp_servers, "enabled": false) — suas credenciais nunca são descriptografadas enquanto desabilitado. Re-sonde para expor novas ferramentas, re-escaneie a skill e revise a fila pending_approval em vez de aprovar em massa.

​
9. Ameaças e conceitos relacionados

Firewall: Servidores MCP

Registre servidores MCP atrás do gateway, sonde suas ferramentas e aplique um veredito por chamada antes que qualquer chamada chegue ao servidor real.

Firewall: Skills

Escaneie e pontue por risco cada capacidade instalável. Quarentene ou bloqueie skills arriscadas antes que suas ferramentas rodem.