Saltar para o conteúdo principal
Quando uma chave vaza, um contratante sai ou um token simplesmente envelhece, você precisa trocar a credencial em um servidor MCP registrado sem desmontar o registro do servidor, recriar suas regras de firewall ou interromper os agentes já conectados através do gateway. É isso que a rotação é: atualize a auth em um servidor existente, e o gateway MCP começa a injetar o novo segredo no próprio próximo tools/call que despacha. A auth de cada servidor é criptografada em repouso e mascarada na leitura, de modo que o token em texto puro nunca faz round-trip de volta para seu console, seus agentes ou o modelo. A rotação é uma atualização de um único campo através do console do workspace.

​
1. Por que a rotação de segredos MCP é sua própria ação

Um servidor MCP registrado detém três coisas que você não quer perder quando uma credencial muda: um name único de workspace (o namespace <server>.<tool> contra o qual suas regras fazem glob), um endpoint e seu conjunto de ferramentas descobertas. Deletar e recriar o servidor para mudar um token órfãoaria cada regra com escopo em <server>.* e forçaria um probe novo. A rotação contorna tudo isso. Você faz PUT do mesmo registro de servidor com novo auth_json; tudo o mais — nome, regras, ferramentas descobertas — permanece no lugar.
O gateway injeta credenciais no momento do dispatch, descriptografando-as apenas para fazer a chamada upstream. Um segredo girado entra em vigor na próxima conexão — o OrcaRouter invalida o cache de ferramentas por workspace a cada mudança de servidor, então não há TTL para esperar.

​
2. Uma rotação concreta

Digamos que você registrou um servidor MCP chamado github com um bearer token, e esse token precisa rolar. Leia o registro atual primeiro — a resposta mascara o segredo, então você nunca está manipulando o texto puro antigo: 
# Configure a partir da sessão de console (UserAuth), não com uma chave de relay.
curl https://api.orcarouter.ai/api/workspace/firewall/mcp_servers/42 \
  -H "Authorization: Bearer <your console access token>"
Depois faça PUT do mesmo registro com apenas a nova credencial. Envie o id no corpo e o auth_json novo; o gateway o re-criptografa antes de tocar o banco de dados: 
curl -X PUT https://api.orcarouter.ai/api/workspace/firewall/mcp_servers \
  -H "Authorization: Bearer <your console access token>" \
  -H "Content-Type: application/json" \
  -d '{
    "id": 42,
    "auth_json": "{\"token\":\"ghp_NEW_token\"}"
  }'
Os campos que você omite são deixados intactos — name, endpoint, auth_mode e enabled todos mantêm seus valores armazenados. O novo token está ativo no próximo tools/call.
Ecoe a máscara para manter um segredo; envie um valor real para mudá-lo. Se você lê o registro e faz PUT dele de volta verbatim, o placeholder mascarado em auth_json é reconhecido como “manter o que está armazenado” — o segredo não é sobrescrito com a máscara. Apenas um auth_json genuinamente novo gira a credencial.

​
3. Mudar o modo de auth, não apenas o segredo

A rotação também cobre mover um servidor entre esquemas de auth. O conjunto fechado de valores de auth_mode é:
Sem credencial. auth_json está vazio. Use para servidores MCP públicos ou confiados por rede.
{ "token": "…" } — enviado como um header Authorization: Bearer.
{ "client_id": "…", "client_secret": "…", "token_url": "…" }. Se você armazenar um access_token estático no JSON, o gateway o envia como um bearer token; a própria troca de client-credentials ainda não é executada, então um servidor que precisa de uma troca ativa falhará até você fornecer um token.
{ "username": "…", "password": "…" } — HTTP basic auth.
Alternar entre dois modos com credencial (ex.: bearer → basic) exige enviar um auth_json novo na mesma requisição. O ciphertext armazenado é vinculado ao seu modo original, então o segredo antigo não pode ser reinterpretado sob o novo formato — forneça a nova credencial, ou a atualização é rejeitada.

​
4. Depois de girar: re-probe

Uma credencial girada muda quais ferramentas você pode alcançar se o token antigo tiver sido revogado. Faça probe do servidor para confirmar que a nova auth funciona e atualizar seu status de alcançabilidade: 
curl -X POST \
  https://api.orcarouter.ai/api/workspace/firewall/mcp_servers/42/probe \
  -H "Authorization: Bearer <your console access token>"
O probe roda um handshake MCP com a credencial nova descriptografada e reporta ok, degraded ou down. Uma falha de auth aparece aqui em vez de como um erro de ferramenta confuso no meio de uma run.

​
5. Papéis e o que permanece mascarado

Cada ação nesta página é uma chamada de console com escopo de workspace (/api/workspace/firewall/mcp_servers, UserAuth) e é gated por papel:
AçãoPapel mínimo
Ler um servidor (segredo mascarado)Member
Girar / atualizar / registrarDeveloper+
DeletarDeveloper+
O texto puro nunca é retornado ao seu console. As leituras mascaram o segredo e redigem o endpoint; o gateway é a única coisa que descriptografa uma credencial, e apenas no momento em que disca o servidor upstream. O modelo e seus agentes não veem nem o token antigo nem o novo.

​
6. Onde isso se encaixa

A rotação é uma operação na superfície de confiança de MCP mais ampla. Uma vez que seus servidores estejam conectados e autenticados, o mesmo gateway avalia cada tools/call contra sua política de firewall antes que ele rode, aplica quarentena de skill por cima e governa o alcance outbound.

Conectar um servidor

Registre um servidor MCP e faça probe de suas ferramentas.

Autenticar

Escolha o modo de auth certo para cada servidor.

Lista de permissão de ferramentas MCP

Escope quais ferramentas cada servidor pode expor.

Limites de egress

Governe onde as chamadas de ferramenta podem alcançar.
Veja Firewall: Servidores MCP para o ciclo de vida completo do servidor e o checklist de confiança MCP para a passagem de hardening de ponta a ponta. A rotação também é um item permanente contra envenenamento de ferramentas MCP e exfiltração de dados: uma credencial que você pode rolar rápido é uma credencial sobre a qual um vazamento não pode ficar sentado.

​
FAQ

Não. A rotação muda apenas a credencial. O servidor mantém seu name, então cada regra com escopo em <server>.* — e qualquer lista de permissão — permanece anexada.
O novo segredo é injetado no próximo tools/call despachado. Não há TTL de cache para esperar — o OrcaRouter invalida o cache de ferramentas do workspace a cada mudança de servidor.
Não — e esse é o ponto. As leituras retornam um segredo mascarado; o texto puro só é descriptografado pelo gateway no dispatch. Gire enviando um novo valor, depois faça probe para confirmar que funciona.