Restringir o MCP por origem de rede

Por padrão, a superfície MCP é protegida só por posse do token: qualquer origem na internet que apresente um PAT válido abre sessão e executa as tools da sua organização. Um token vazado — num .mcp.json commitado, num log de CI, num backup de laptop — é acesso de leitura à sua infraestrutura, de qualquer lugar do mundo.

A allowlist de origem não substitui o token. Ela soma um segundo fator: além de ter a credencial, é preciso estar na sua rede. Um token vazado deixa de bastar.

Como funciona

Você declara blocos CIDR (IPv4 e IPv6) autorizados a falar com o servidor MCP, em Governança → Acesso por origem de rede.

Lista não-vazia é default-deny

Sem nenhum bloco configurado, o recurso está desligado e o comportamento é o de sempre. Ao configurar o primeiro bloco, a política inteira vira deny all + allow from <seus blocos>. Uma lista que apenas acrescentasse permissão a um default aberto não protegeria de nada.

A verificação acontece a cada requisição, não só na abertura da sessão. A sessão MCP é longa e stateful, mas a autorização de origem não é: um token que muda de rede no meio de uma investigação passa a ser recusado a partir dali.

Antes de ligar: comece pelas origens observadas

O modo de falha desta funcionalidade é o lockout — configurar a lista errada e trancar o time inteiro do lado de fora. NAT de escritório, egress de cluster e saída de VPN raramente são o endereço que as pessoas imaginam, e adivinhar o bloco é a forma mais rápida de se trancar.

Por isso a tela mostra as origens observadas: o último endereço de onde cada um dos seus tokens chegou até nós. Comece por ali. É o endereço real, medido do nosso lado, e não o que alguém supõe — basta conectar uma vez com o cliente MCP antes de configurar a lista.

Nem sempre foi assim

Até setembro de 2026 a origem só era registrada enquanto já havia uma allowlist ativa — então a tela nascia vazia exatamente para quem ia configurar a primeira lista, que é o único momento em que ela serve. Se você leu essa ressalva aqui antes, ela não vale mais: hoje o registro acontece em qualquer conexão autorizada, com ou sem lista.

Ela vale também para outra coisa, e essa sempre foi real: confirma que a leitura de IP está certa ponta a ponta (contagem de hops errada aparece ali como um valor obviamente errado) e mostra um uso vindo de onde ninguém esperava.

E se você se trancar mesmo assim, o caminho de volta não depende dela: a recusa ecoa o IP do próprio chamador e vira linha de audit, então o bloco que faltava é legível na própria recusa.

O que guardamos dessa origem, e por quanto tempo

Registrar o endereço de toda conexão autorizada é o que faz a tela acima existir para quem ainda não tem lista — e é coleta, então ela vem declarada e com interruptor.

• Um endereço por token, o último. Não há histórico: cada conexão sobrescreve a anterior. Não guardamos rota, geolocalização, nem o endereço de cada requisição.
• Ele não sai da sua organização. É lido por owner e admin da sua organização, e por mais ninguém: não alimenta nenhum agregado entre clientes nem é enviado a provedor de modelo.
• Vive enquanto o token viver. Revogar o token apaga o endereço no mesmo ato; deletar a organização apaga tudo; e uma origem que não se repete em 90 dias é apagada sozinha — de onde o seu time chegava há três meses não é evidência do egress de hoje, e oferecer isso como ponto de partida seria lockout com um passo a mais.
• O endereço de uma conexão RECUSADA continua no audit, independente disso: é assim que um token vazado sendo usado de fora aparece para você, e um controle de acesso que não registra a recusa não é verificável.

Para desligar: Governança → Origem das conexões MCP, no interruptor “Registrar a origem de cada conexão”. Desligar apaga também o que já foi observado na sua organização, e a mudança fica no seu audit log. O custo é o da primeira seção: a lista de origens fica vazia, e configurar a allowlist volta a depender de você descobrir o próprio egress por fora.

Quando uma requisição é recusada

A resposta é 403 com error: "origin_not_allowed", e ela não ecoa a lista — quem está de fora não aprende o que seria aceito. Ela ecoa o IP observado daquela requisição, que é do próprio chamador, e é o que permite a alguém legítimo pedir a inclusão do seu bloco.

Toda recusa vira linha de audit com o endereço observado. É assim que um token vazado sendo usado de fora aparece para você — uma allowlist que bloqueia em silêncio esconderia exatamente o evento que interessa.

O que acontece se não conseguirmos ler a política

A requisição é recusada (503), não aceita.

Falhar ao ler a política é ambíguo entre “não há lista” e “não sei se há”, e num controle de acesso essas duas coisas não podem ter o mesmo efeito. Recusar é visível e reversível; aceitar em silêncio transformaria uma indisponibilidade nossa num buraco no seu controle.

Quem enforça, e o que isso significa para você

Este controle é aplicado por nós

Diferente da denylist de tools — que o Agent enforça dentro da sua infraestrutura —, o servidor MCP é nosso, então esta verificação roda do nosso lado. O que a torna verificável para você é o audit: toda decisão de origem deixa registro com o endereço observado.

O que ela não cobre

• A conexão do Agent (runner) não passa por aqui. Ele conecta por mTLS com certificado por organização, que é uma prova mais forte que endereço de rede — restringir por IP ali somaria fragilidade operacional (a frota é efêmera e o egress muda) sem somar garantia.
• Não substitui a rotação de token. Se você suspeita de vazamento, revogue o PAT; a allowlist reduz a janela, não a fecha.
• Não é isolamento de rede. Ela filtra quem fala com o servidor MCP, não o que acontece depois — para o que pode ser lido, veja a denylist de tools.