Sandbox de Servidor 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 workspace 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, gerar 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 uma maneira comum para aplicações de IA conectarem 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.

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 de ferramentas, as descrições de 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 de nível de aplicação. 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 comum de falha
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
Runtime do sandbox	Sistema de arquivos, processos, rede, segredos, ciclo de vida e logs	O processo do servidor herda acesso do host porque está executando muito próximo aos 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 runtime 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 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 sandboxing 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 um repositório, upload de usuário, dataset montado, arquivo de credencial 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álise, tickets ou documentos privados.
• Ferramentas de implantação e CI que podem criar branches, publicar previews, rotacionar configuração ou modificar infraestrutura.
• Ferramentas de pacotes e dependências que podem buscar código de registries, remotos Git ou URLs arbitrárias.

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 requisiçã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 workspace do agente	O servidor está fortemente acoplado aos arquivos atuais do agente, comandos shell, sessão do navegador ou artefatos gerados	O servidor e o agente compartilham estado, portanto uma ferramenta comprometida pode ver o mesmo workspace, 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 workspace do agente, lida com credenciais diferentes ou realiza execução de maior risco	A transferência de arquivos entre sandboxes e a 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, registro e limites de taxa	A API deve ser estreita; não exponha uma superfície interna ampla de administração 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 workspace 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 para registries públicos, enquanto o agente de codificação principal não deveria. 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 é adequado para ferramentas que não são realmente “ferramentas de runtime”. Uma consulta de faturamento, leitura de feature-flag ou busca em issue tracker pode ser mais segura como uma API backend normal com autorização no lado do servidor do que como um servidor de forma livre dentro do ambiente de computação do agente.

Montagens de sistema de arquivos e workspaces por agente

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

Use limites explícitos de workspace:

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

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

Um padrão prático é dividir o acesso ao workspace por função:

Diretório	Acesso	Propósito
/workspace/input	Somente leitura	Uploads de usuário, repositório semente, 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	Evitar montagens de arquivo sempre que possível	Se inevitável, monte um arquivo de segredo limitado com vida útil estrita e ocultação

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, stack traces, scripts de pacotes, histórico de shell, sessões de navegador e respostas de ferramentas. Quando um servidor MCP precisa de uma credencial, forneça a credencial mais restrita que pode completar a ação da ferramenta.

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 PRs pode precisar de acesso de escrita a branches. Um servidor de implantação não deve compartilhar nenhum dos tokens, a menos que o modelo de permissão realmente exija.

Um bom tratamento de segredos para servidores MCP se parece com isso:

• Injete segredos no início do sandbox ou do processo, não através de prompts.
• Use tokens de curta duração ou revogáveis quando o provedor suportar.
• Escope as credenciais por ferramenta, inquilino, ambiente e ação.
• Oculte segredos do stdout, stderr, respostas estruturadas de ferramentas e logs de rastreamento.
• Não retorne variáveis de ambiente brutas para o modelo.
• Não permita que o agente decida 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 anti-padrão comum: um arquivo de ambiente único montado em todas as sessões de agente. Isso torna o desenvolvimento local mais fácil e a revisão de produção mais difícil. Se uma ferramenta não precisa de um segredo, ela não deve ser capaz de lê-lo.

Egresso de rede e escolhas de transporte

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

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

Pergunta	Transporte responde	Política de rede responde
Como o cliente MCP se comunica com o servidor?	stdio, transporte 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ção, proxy, política de DNS ou nenhum egresso
O servidor pode buscar pacotes ou páginas web?	Não suficiente por si só	Listas de permissões de registry, listas de permissões de URL, cache e registro
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 é frequentemente o acesso herdado ao host. O servidor pode ser executado como um processo filho da aplicação host e ver arquivos locais, variáveis de ambiente e rotas de rede. Se esse servidor executa código ou lê arquivos sensíveis, mova-o para um processo em sandbox ou execute todo o par host-worker dentro de um workspace 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 precisa de instalação de pacotes, permita o registry de pacotes ou um cache pull-through. Se precisa de pesquisa na web, roteie através de um proxy que registre os domínios solicitados e bloqueie endpoints internos de metadados. Se precisa de APIs internas, exponha uma API estreita em vez de toda a rede privada.

Instalação 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ção 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 de dependências devem ser fixadas ou baseadas em lockfile.
• Onde os caches de build e pacotes instalados residem.
• 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 uma segunda questão: 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 jobs em segundo plano. Esse estado pode ser útil para fluxos de trabalho de múltiplas 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
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
Encerramento explícito	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 workspace, a menos que o produto explicitamente precise de replay completo da sessão.

Logs, 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 workspace, 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 de clientes, 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 mais rigorosos e políticas de retenção.

Algumas ações MCP devem permanecer sujeitas a 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 de 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 workspace.
• 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 foi projetado para cargas de trabalho de agente que precisam de um runtime isolado para execução de código, arquivos, processos, fluxos de trabalho estilo navegador e sessões de longa duração. Ele pode se encaixar em arquiteturas MCP onde um servidor de ferramenta precisa de um workspace descartável em vez de acesso direto a um laptop de desenvolvedor, host de produção ou máquina CI compartilhada.

Use-o como o limite de runtime para servidores que precisam:

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

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

Para 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 workspace da tarefa
  injetar apenas segredos específicos da ferramenta
  iniciar o servidor MCP dentro do sandbox ou conectar a uma API de ferramenta apoiada pelo 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 no nível do artigo estável, deixando as chamadas exatas do SDK para a documentação mais recente e seu código de plataforma.

Checklist de implementação

Use este checklist antes de conectar um servidor MCP a um agente autônomo ou semiautônomo:

Área	Perguntas a responder
Escopo da ferramenta	Quais ferramentas o servidor expõe e quais alteram estado externo?
Posicionamento	O servidor deve ser executado no sandbox do agente, em um sandbox separado ou fora do sandbox por trás de uma API estreita?
Sistema de arquivos	Quais diretórios são montados, são somente leitura ou leitura-escrita e como as fugas de caminho são bloqueadas?
Segredos	Quais credenciais são injetadas, como são escopadas e onde podem aparecer em logs ou saídas?
Rede	O egresso é negar 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, jobs em segundo plano e listeners são permitidos?
Estado	Como são tratados workspaces por agente, snapshots, timeouts de inatividade, comportamento de pausa/retomada e limpeza?
Logs	Você pode reconstruir chamadas de ferramenta, alterações de arquivo, domínios externos e artefatos sem armazenar segredos?
Revisão humana	Quais chamadas de ferramenta exigem aprovação antes da execução, exportação, implantação ou ação voltada ao cliente?
Testes	Você testou injeção de prompt, traversal de link simbólico/caminho, saída grande, limpeza com falha e caminhos de egresso negados?

O MCP torna a integração de ferramentas mais fácil. O sandboxing evita 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 workspace do agente, alguns em sandboxes separadas 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, logs e controles de rede, mas podem não precisar de um sandbox dedicado por requisiçã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 runtime recebe.

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

Não. As raízes ajudam a comunicar as localizações pretendidas do workspace entre cliente e servidor, mas não são um limite de runtime completo. Use validação de caminho e controles de sistema de arquivos no nível do sandbox para manter o servidor dentro do workspace 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 runtime escopados. Não monte pastas amplas de credenciais de desenvolvedor nem passe segredos através de prompts. Oculte-os de logs e respostas de ferramentas.

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 workspace.

Artigos recomendados

• AI-Generated Code Sandbox Requirements for Production Apps
• Build a Remote Code Execution MCP Server with Novita Sandbox and mcp-use Library
• Building a Coding Agent with Novita’s Agent Sandbox
• How Agent Sandboxes Power Secure, Scalable AI Innovation