Sandbox MCP: Servidores MCP Isolados com Controles de Sistema de Arquivos, Segredos e Rede

Servidores MCP devem ser executados com montagens de sistema de arquivos limitadas, segredos com privilégios mínimos, política de rede explícita, limites de espaço de trabalho por agente e logs, para que o acesso a ferramentas não expanda silenciosamente o limite de confiança do agente. Um sandbox é útil quando um servidor MCP pode ler arquivos, criar subprocessos, instalar pacotes, chamar APIs internas ou manter estado para uma sessão de agente de longa duração. A parte difícil não é decidir que o MCP precisa de isolamento; é decidir qual limite pertence a cada ferramenta, quais dados cruzam esse limite e quais ações ainda precisam de revisão humana.

Por que o MCP altera o limite de confiança do agente

O Model Context Protocol fornece aos aplicativos de IA uma maneira comum de conectar modelos a ferramentas, prompts e recursos. Isso torna a integração mais limpa, mas também transforma cada servidor MCP em um limite de política. Se um servidor expõe read_file, run_command, query_database ou deploy_preview, o agente agora pode solicitar ações que vão além da janela de contexto do modelo.

Se você está conectando essas ferramentas a um fluxo de trabalho mais amplo, comece com Como Automatizar Tarefas com IA e depois decida se o loop externo precisa de um agente de codificação ou de um interpretador mais leve.

A especificação MCP descreve várias expectativas de segurança que são importantes para o design do sandbox: os usuários devem entender e consentir com as ferramentas expostas, os hosts devem exigir consentimento antes da invocação da ferramenta, as descrições das ferramentas não são confiáveis a menos que verificadas, e dados sensíveis devem ser protegidos por controles de acesso apropriados. Essas regras são controles no nível do aplicativo. Um sandbox adiciona controles de tempo de execução abaixo delas, limitando o que o processo do servidor MCP pode tocar, mesmo que o agente, a descrição da ferramenta ou a cadeia de prompts faça uma solicitação inadequada.

Pense no limite de confiança em três camadas:

Camada	O que controla	Modo de falha comum
Host ou cliente MCP	Quais servidores estão conectados e quais chamadas de ferramenta são aprovadas	Uma ferramenta ampla é aprovada uma vez e reutilizada em um contexto mais sensível
Servidor MCP	Implementação da ferramenta, autenticação, validação de entrada, acesso a recursos	Uma ferramenta lê mais arquivos, envia mais dados ou executa mais comandos do que o esperado
Tempo de execução do sandbox	Sistema de arquivos, processos, rede, segredos, ciclo de vida e logs	O processo do servidor herda acesso do host porque está sendo executado muito próximo dos recursos de produção

O objetivo não é tornar cada servidor MCP não confiável da mesma forma. Uma ferramenta de consulta de calendário, uma ferramenta de execução de código local e uma ferramenta de implantação têm perfis de risco diferentes. O objetivo é manter o acesso de tempo de execução de cada servidor não mais amplo do que o trabalho que ele realiza.

O que isolar primeiro

Comece com os servidores MCP que podem alterar o estado externo, tocar em dados sensíveis ou executar código. Esses são os servidores com maior probabilidade de transformar um erro comum de prompt em um incidente maior.

Candidatos de alta prioridade para isolamento em sandbox incluem:

• Ferramentas de execução de código que executam comandos shell, Python, Node.js, compiladores, testes ou notebooks.
• Ferramentas de sistema de arquivos que leem ou escrevem em um repositório, upload de usuário, conjunto de dados montado, arquivo de credenciais ou artefato gerado.
• Ferramentas de navegador e uso de computador que mantêm cookies, estado de sessão, arquivos baixados ou capturas de tela.
• Conectores de dados que podem consultar registros de clientes, exportações de análises, tickets ou documentos privados.
• Ferramentas de implantação e CI que podem criar branches, publicar previews, girar configurações ou modificar infraestrutura.
• Ferramentas de pacotes e dependências que podem buscar código de registries, remotos Git ou URLs arbitrários.

Servidores MCP de menor risco ainda podem merecer controles. Um servidor de busca de documentação pública somente leitura pode não precisar de uma microVM por solicitação, mas ainda deve ter um caminho de rede na lista de permissões, logs e limites de taxa. O isolamento deve seguir o raio de explosão prático da ferramenta, não o rótulo “servidor MCP”.

Onde o servidor MCP deve ser executado

Existem três padrões comuns de posicionamento. Nenhum é universalmente correto.

Posicionamento	Use quando	Cuidado com
Mesmo sandbox que o espaço de trabalho do agente	O servidor está fortemente acoplado aos arquivos atuais, comandos shell, sessão do navegador ou artefatos gerados do agente	O servidor e o agente compartilham estado, então uma ferramenta comprometida pode ver o mesmo espaço de trabalho, a menos que montagens e segredos sejam limitados
Sandbox separado por servidor MCP ou grupo de ferramentas	A ferramenta precisa de isolamento mais forte do espaço de trabalho do agente, lida com credenciais diferentes ou executa ações de maior risco	Transferência de arquivos entre sandboxes e latência tornam-se parte do design do produto
Fora do sandbox por trás de uma API limitada	A ferramenta é um serviço de produção estável com sua própria autenticação, autorização, logging e limites de taxa	A API deve ser estreita; não exponha uma superfície administrativa interna ampla apenas porque está fora do sandbox

Executar um servidor no mesmo sandbox é conveniente para agentes de codificação. O servidor MCP pode ver o repositório, executar testes, inspecionar artefatos e retornar resultados sem mover arquivos entre ambientes. Isso funciona melhor quando o próprio espaço de trabalho já é descartável e contém apenas os arquivos que o agente deve usar.

Um sandbox separado é melhor quando a ferramenta merece uma política diferente. Por exemplo, um servidor MCP de análise de pacotes pode precisar de acesso à internet a registries públicos, enquanto o agente de codificação principal não deve. Um servidor MCP de navegador pode precisar de cookies para uma conta de teste, enquanto um servidor de execução de código nunca deve ver esses cookies.

Um serviço externo se adapta a ferramentas que não são realmente “ferramentas de tempo de execução”. Uma consulta de faturamento, leitura de feature-flag ou busca de issue tracker pode ser mais segura como uma API backend normal com autorização no lado do servidor do que como um servidor de formato livre dentro do ambiente de computação do agente.

Montagens do sistema de arquivos e espaços de trabalho por agente

O acesso ao sistema de arquivos é onde a conveniência do MCP muitas vezes se transforma em privilégio acidental. Um servidor que precisa ler ./src não deve herdar o diretório home de um desenvolvedor. Uma ferramenta que escreve gráficos gerados não deve ser capaz de sobrescrever a configuração de implantação.

Use limites explícitos de espaço de trabalho:

• Dê a cada execução do agente seu próprio diretório de espaço de traballho.
• Monte apenas o repositório, pasta de upload, conjunto de dados ou diretório de artefatos necessário para a tarefa.
• Prefira montagens somente leitura para material de origem e montagens leitura-escrita apenas para saídas.
• Separe as saídas geradas dos arquivos de origem confiáveis.
• Evite montar pastas de credenciais como .ssh, diretórios de configuração de nuvem, perfilis de navegador ou arquivos de autenticação do gerenciador de pacotes local.
• Redefina ou faça snapshot do espaço de trabalho entre usuários, inquilinos ou jobs não relacionados.

As raízes MCP podem ajudar os clientes a comunicar os locais do sistema de arquivos em que um servidor deve operar, mas as raízes não são um limite de segurança completo por si mesmas. Trate-as como um mecanismo de coordenação entre cliente e servidor. O tempo de execução ainda precisa de limites no nível do sistema de arquivos, e o servidor deve validar caminhos para que as solicitações não possam escapar do espaço de trabalho pretendido com links simbólicos, caminhos relativos ou truques de extração de arquivos.

Um padão prático é dividir o acesso ao espaço de trabalho por função:

Diretório	Acesso	Propósito
/workspace/input	Somente leitura	Uploads do usuário, repositório seemente, fixture de benchmark ou dados de teste
/workspace/output	Leitura-escrita	Arquivos gerados, relatórios, patches, gráficos ou capturas de tela
/workspace/tmp	Leitura-escrita, descartável	Cache de build, cache de instalação de pacotes, arquivos temporários
/workspace/secrets	Evite montagens de arquivos onde possível	Se inevitável, monte um arquivo de segredo limitado com vida curta e redação rigorosa
Os caminhos exatos não importam. O princípio sim.

Segredos e variáveis de ambiente

Segredos são geralmente mais fáceis de vazar do que arquivos porque viajam através de variáveis de ambiente, logs, traços de pilha, scripts de pacotes, hisórico de shell, sessões de navegador e respostas de feramentas. Quando um servidor MCP preisa de uma credencial, dê a credencial mais estrita que pode completar a ação da feramenta.

Use credenciais separadas para servidores MCP separados. Um servidor de busca de issues do GitHub pode precisar de acesso somente leitura a issues. Um servidor de autoria de PR pode preisar de acesso de escrita a branches. Um servidor de implantação não deve compartilhar nenhum dos dois tokens, a menos que o modelo de permissão realmente exija.

Bom manuseio de segrêdos para servidores MCP se parece com isso:

• Injeja segredos no inicio do sandbox ou do procésso, não através de prompts.
• Use tokens de curta duração ou revogáveis quando o provedor suportar.
• Limite as credenciais por ferramenta, inquilino, ambiente e ação.
• Redacione segredos de stdout, stderr, respostas estruturadas de ferramentas e logs de rastreamento.
• Não retorne variáveis de ambiente brutas para o modelo.
• Não deixe o agete decidir qual segredo carregar.
• Rotacione credenciais usadas por servidores de alto risco e após suspeita de exposição por injeção de prompt.

Evite um antipadrão comum: um arquivo de ambiente para todos os fins montado em cada ssão do agente. Torna o desenvovimento local mais fácil e a revião de produção mais difícil. Se uma ferramenta não preisa de um segredo, ela não deve ser capaz de lê-lo.

Egresso de rede e esolhas de transorte

O MCP suporta padrões de transorte local e remoto. A especificação descreve stdio para comunicação de processo local e Streamable HTTP para comunicação servidor-cliente sobre HTTP. Desigens mais antigas baseadas em SSE ainda aparecem no ecosistema, mas novas integrações devem verificar a documentação atual do MCP e o SDK escolhido antes de depender de um transorte específico.

A escolha de transorte e a política de rede do sandbox resolvem problemas diferentes:

| Pergunta | Transorte responde | Política de rede responde | |—|—| | Como o cliente MCP fala com o servidor? | stdio, transorte baseado em HTTP ou outro padrão suportado | Não aplicável | | Quais hosts externos o servidor pode chamar? | Não é suficiente por si só | Lista de permissões, lista de negações, proxy, política de DNS ou nenhum egresso | | O servidor pode buscar pacotes ou páginas da web? | Não suficiente por si só | Listas de permissões de registry, listas de permissões de URL, cache e logging | | Outro processo pode alcançar o servidor? | Detalhes de binding e autenticação | Firewall de entrada e limite de rede do sandbox |

Para servidores stdio locais, o risco é muitas vezes o acesso herdado ao host. O servidor pode ser executado como um processo filho do aplicativo host e ver arquivos locais, variáveis de ambiente e rotas de rede. Se esse servidor executar código ou ler arquivos sensíveis, mova-o para um processo em sandbox ou execute todo o par host-worker dentro de um espaço de trabalho descartável.

Para servidores MCP baseados em HTTP, o risco se desloca para autenticação, exposição de rede e separação entre inquilinos. Use autorização no lado do servidor, TLS, verificações de origem quando relevante e credenciais por cliente. Não exponha um servidor MCP remoto em uma rede interna ampla sem uma política clara sobre quem pode invocar quais ferramentas.

Para egresso de rede, negar por padrão é mais fácil de raciocinar do que permitir por padrão. Se uma ferramenta precisar de instalações de pacotes, permita o registry de pacotes ou um cache de pull-through. Se precisar de pesquisa na web, roteie através de um proxy que registre os domínios solicitados e bloqueie endpoints internos de metadados. Se precisar de APIs internas, exponha uma API estreita em vez de toda a rede privada.

Instalações de pacotes, subprocessos e estado de longa duração

Muitas ferramentas MCP úteis precisam de subprocessos. Agentes de codificação executam testes. Agentes de dados instalam bibliotecas. Agentes de navegador iniciam navegadores. Agentes de build chamam compiladores. O suporte a subprocessos não é o problema; o suporte invisível a subprocessos é.

Antes de permitir instalações de pacotes ou execução de shell, defina:

• Quais comandos são permitidos, negados ou sujeitos a aprovação.
• Se os gerenciadores de pacotes podem alcançar a internet pública.
• Se as versões das dependências devem ser fixadas ou baseadas em lockfile.
• Onde vivem os caches de build e os pacotes instalados.
• Por quanto tempo os processos em segundo plano podem ser executados.
• Quais arquivos de saída são retidos após a limpeza.
• Se o agente pode iniciar listeners de rede.

Servidores MCP de longa duração introduzem um segundo problema: deriva de estado. Um servidor que vive por horas pode acumular arquivos, credenciais, cookies de navegador, histórico de shell, mudanças de dependências e trabalhos em segundo plano. Esse estado pode ser útil para fluxos de trabalho de várias etapas, mas deve pertencer ao agente, usuário e tarefa corretos.

Use controles de ciclo de vida:

Controle	Por que é importante
IDs de sandbox por agente	Impede que o estado da ferramenta de um agente se torne o contexto de outro agente
Timeout de inatividade	Limpa sessões de ferramentas abandonadas
Política de pausa e retomada	Suporta trabalhos longos sem manter computação desnecessária ativa
Política de snapshot ou template	Inicia ambientes reproduzíveis a partir de uma linha de base conhecida
Desmontagem explícita	Remove arquivos, mata processos e libera credenciais após o trabalho

Se uma ferramenta produz artefatos duráveis, copie apenas esses artefatos para fora do sandbox. Não preserve todo o espaço de trabalho, a menos que o produto exija explicitamente a reprodução completa da sessão.

Logging, limpeza e revisão humana

Os logs de ferramentas MCP devem responder a perguntas de segurança e depuração sem se transformar em um novo armazenamento de segredos. Logs úteis incluem nome da ferramenta, identidade do chamador, ID do sandbox, ID do espaço de trabalho, categoria do comando, arquivos lidos ou escritos, domínios externos contatados, nomes de pacotes instalados, status de saída e caminhos de artefatos.

Não registre prompts brutos, dados brutos do cliente, tokens, conteúdo completo de arquivos ou saída completa de comandos por padrão. Mantenha rastros sensíveis atrás de controles de acesso e políticas de retenção mais rigorosos.

Algumas ações do MCP devem permanecer sob revisão humana mesmo dentro de um sandbox:

• Publicar ou implantar em produção.
• Enviar e-mail, chat, tickets, faturas ou mensagens voltadas ao cliente.
• Modificar controle de acesso, faturamento, dados do usuário ou configuração de infraestrutura.
• Exfiltrar arquivos grandes, repositórios privados, exportações de banco de dados ou strings semelhantes a credenciais.
• Executar comandos fora da política do espaço de trabalho.
• Chamar APIs internas com permissões de escrita.

O sandbox deve reduzir o raio de explosão. Não deve se tornar uma razão para remover a revisão de ações comerciais sensíveis.

Como o Novita Agent Sandbox se encaixa

O Novita Agent Sandbox é projetado para cargas de trabalho de agente que precisam de um tempo de execução isolado para execução de código, arquivos, processos, fluxos de trabalho no estilo navegador e sessões de longa duração. Ele pode se encaixar em arquiteturas MCP onde um servidor de ferramentas precisa de um espaço de trabalho descartável em vez de acesso direto a um laptop de desenvolvedor, host de produção ou máquina de CI compartilhada.

Use-o como o limite de tempo de execução para servidores que precisam:

• Executar código ou comandos gerados.
• Trabalhar com arquivos temporários e artefatos gerados.
• Manter estado de espaço de trabalho por agente em tarefas de várias etapas.
• Executar trabalho em segundo plano que o agente pode verificar mais tarde.
• Separar a experimentação do agente do host do aplicativo.

Mantenha o limite do produto claro: um servidor MCP ainda é seu código de aplicativo. Você ainda projeta as permissões da ferramenta, escopos de credenciais, política de rede, fluxo de aprovação, esquema de logging e comportamento de limpeza. O sandbox fornece o ambiente isolado onde essas decisões são aplicadas.

Para a configuração específica do produto, use a documentação atual da Novita em vez de copiar trechos desatualizados de tutoriais mais antigos. Conceitualmente, a forma é:

para cada tarefa do agente:
  criar sandbox a partir do template aprovado
  montar apenas o espaço de trabalho da tarefa
  injetar apenas segredos específicos da ferramenta
  iniciar o servidor MCP dentro do sandbox ou conectar a uma API de ferramenta baseada em sandbox
  rotear chamadas de ferramenta através de verificações de aprovação e política
  coletar logs e artefatos aprovados
  parar, redefinir ou pausar o sandbox de acordo com o ciclo de vida da tarefa

Isso mantém a orientação estável no nível do artigo, deixando as chamadas exatas do SDK para a documentação mais recente e seu código de plataforma.

Lista de verificação de implementação

Use esta lista de verificação antes de conectar um servidor MCP a um agente autônomo ou semiautônomo:

Área	Perguntas a responder
Escopo da ferramenta	Que ferramentas o servidor expõe e quais delas alteram estado externo?
Posicionamento	O servidor deve executar no sandbox do agente, em um sandbox sepaado ou fora do sandbox por trás de uma API estrita?
Sistema de arquivos	Quais diretórios são montados, são somente leitura ou leitura-escritae como os escapes de caminho são bloqueados?
Segredos	Quais credenciais são injeadas, como são escopadas e onde podem aparecer em logs ou saídas?
Rede	O egresso é negado por padrão, roteado por proxy ou na lista de permissões por domínio, registry e API interna?
Subprocessos	Quais comandos, gerenciadores de pacotes, trabalhos em segundo plano e ouvintes são permitidos?
Estado	Como são gerenciados espaços de trabalho por agente, snapshots, timeouts de inatividade, comportamento de pausa/retomada e limpeza?
Logs	Você pode reconstruir chamadas de ferramentas, alterações em arquivos, domínios externos e artefatos sem armazenar segredos?
Revisão humana	Quais chamadas de ferramenta exigem arovação antes da execução, exortação, imlantação ou ação voltada ao cliente?
Testes	Você testou injeção de prompt, traversia de link simbólico/caminho, saída grande, limpeza falha e caminhos de egresso negados?

O MCP torna a integração de ferramentas mais fácil. O sandbox impede que essa integração se torne uma expansão silenciosa dos privilégios do modelo. O design certo geralmente é uma mistura: alguns servidores no mesmo espaço de trabalho do agente, alguns em sandboxes separados e alguns fora do sandbox por trás de APIs com autorização rigorosa. Escolha o posicionamento que corresponda aos dados, segredos, subprocessos e necessidades de rede da ferramenta.

FAQ

Todo servidor MCP deve ser executado em um sandbox?

Não. Priorize servidores que executam código, leem ou escrevem arquivos, usam segredos, chamam serviços privados, iniciam navegadores, instalam pacotes ou alteram estado externo. Servidores somente leitura de menor risco ainda podem precisar de autenticação, logging e controles de rede, mas podem não precisar de um sandbox dedicado por solicitação.

stdio é mais seguro que HTTP para servidores MCP?

Não automaticamente. Stdio pode ser simples para servidores locais, mas o servidor pode herdar acesso local ao sistema de arquivos, ambiente e rede. Servidores baseados em HTTP precisam de controles de autenticação e exposição mais fortes. A escolha mais segura depende de onde o processo é executado e quais permissões de tempo de execução ele recebe.

As raízes MCP podem substituir o sandbox do sistema de arquivos?

Não. As raízes ajudam a comunicar os locais de espaço de trabalho pretendidos entre cliente e servidor, mas não são um limite de tempo de execução completo. Use validação de caminho e controles de sistema de arquivos no nível do sandbox para manter o servidor dentro do espaço de trabalho pretendido.

Onde os segredos devem ser armazenados para ferramentas MCP em sandbox?

Injete apenas as credenciais que a ferramenta precisa, idealmente como variáveis de ambiente de curta duração ou segredos de tempo de execução com escopo. Não monte pastas amplas de credenciais de desenvolvedor nem passe segredos através de prompts. Redacione-os de logs e respostas da ferramenta

Quando uma ferramenta MCP deve exigir aprovação humana?

Exija aprovação para implantações em produção, mensagens voltadas ao cliente, alterações de faturamento ou controle de acesso, exportações grandes de dados, escritas em infraestrutura e qualquer comando ou ação de rede fora da política normal do espaço de trabalho.

Artigos recomendados

• Requisitos de Sandbox para Código Gerado por IA em Aplicativos de Produção
• Claude MCP: Como Configurar Servidores MCP no Claude Code e Claude Desktop
• Construindo um Agente de Codificação com o Novita Agent Sandbox