Servidores MCP em Sandboxes Isoladas: Sistema de Arquivos, Segredos e Compensações de Rede

Os servidores MCP devem ser executados com montagens de sistema de arquivos com escopo definido, 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. Uma 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 deve estar em torno de 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.

A especificação do MCP descreve várias expectativas de segurança que importam para o design de 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 em nível de aplicação. Uma sandbox adiciona controles em tempo de execução abaixo deles, 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 ruim.

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
Runtime da sandbox	Sistema de arquivos, processos, rede, segredos, ciclo de vida e logs	O processo do servidor herda acesso ao host porque está sendo executado muito próximo aos recursos de produção

O objetivo não é tornar todo 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 em 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 normal de prompt em um incidente mais amplo.

Candidatos de alta prioridade para colocação 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 um repositório, upload de usuário, conjunto de dados 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álises, tickets ou documentos privados.
• Ferramentas de implantação e CI que podem criar branches, publicar previews, rotacionar configurações ou modificar infraestrutura.
• Ferramentas de pacotes e dependências que podem buscar código de registries, repositórios Git ou URLs arbitrárias.

Servidores MCP de menor risco ainda podem merecer controles. Um servidor de pesquisa 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 permitido, 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
Mesma sandbox do 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, então uma ferramenta comprometida pode ver o mesmo workspace a menos que montagens e segredos tenham escopo
Sandbox separada por servidor MCP ou grupo de ferramentas	A ferramenta precisa de isolamento mais forte do workspace do agente, lida com credenciais diferentes ou executa tarefas de maior risco	Transferência de arquivos entre sandboxes e latência tornam-se parte do design do produto
Fora da sandbox por trás de uma API com escopo	A ferramenta é um serviço de produção estável com sua própria autenticação, autorização, registro em log e limites de taxa	A API deve ser estreita; não exponha uma superfície administrativa interna ampla apenas porque está fora da sandbox

Executar um servidor na mesma 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.

Uma sandbox separada é 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 pesquisa 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 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 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 workspace:

• Atribua a cada execução de agente seu próprio diretório de workspace.
• Monte apenas o repositório, pasta de upload, conjunto de dados ou diretório de artefatos necessários para a tarefa.
• Prefira montagens somente leitura para material de origem e montagens leitura-escrita apenas para saídas.
• Separe saídas geradas de arquivos de origem 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, locatários ou jobs não relacionados.

As raízes (roots) do MCP podem ajudar os clientes a comunicar os locais do sistema de arquivos nos quais o 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 em nível de sistema de arquivos, e o servidor deve validar caminhos para que as solicitações não possam escapar do workspace pretendido usando links simbólicos, caminhos relativos ou truques de extração de arquivos.

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

Diretório	Acesso	Propósito
/workspace/input	Somente leitura	Uploads do usuário, repositório inicial, 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 quando possível	Se inevitável, montar um arquivo de segredo com escopo único, tempo de vida estrito e ocultação

Os caminhos exatos não importam. O princípio sim.

Segredos e variáveis de ambiente

Segredos geralmente são mais fáceis de vazar do que arquivos, pois viajam através de variáveis de ambiente, logs, stack traces, scripts de pacotes, histórico do shell, sessões do navegador e respostas de ferramentas. Quando um servidor MCP precisar de uma credencial, forneça a credencial mais restrita que possa 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 criação de PR 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 isso.

Uma boa manipulação de segredos para servidores MCP se parece com isso:

• Injete segredos no início da sandbox ou do processo, não através de prompts.
• Use tokens de curta duração ou revogáveis quando o provedor suportar.
• Defina escopo das credenciais por ferramenta, locatário, ambiente e ação.
• Oculte 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 agente decidir qual segredo carregar.
• Rotacione as 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 para todos os fins montado em cada sessão de agente. Isso facilita o desenvolvimento local e dificulta a revisão em produção. Se uma ferramenta não precisa de um segredo, ela não deve ser capaz de lê-lo.

Saída 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 HTTP Streamable 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 da 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ções, proxy, política de DNS ou sem saída
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 registro em log
Outro processo pode alcançar o servidor?	Detalhes de bind e autenticação	Firewall de entrada e limite de rede da sandbox

Para servidores stdio locais, o risco é frequentemente o acesso herdado ao host. O servidor pode executar como um processo filho do aplicativo 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 locatários. 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 saída de rede, a negação padrão é mais fácil de raciocinar do que a permissão padrão. Se uma ferramenta precisar de instalação de pacotes, permita o registry de pacotes ou um cache pull-through. Se precisar de pesquisa na web, encaminhe 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çã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 exigem 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 os caches de build e os 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: desvio de estado. Um servidor que vive por horas pode acumular arquivos, credenciais, cookies de navegador, histórico de shell, alterações de dependências e jobs 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 contexto de outro agente
Timeout de inatividade	Limpa sessões de ferramenta abandonadas
Política de pausa e retomada	Suporta jobs longos sem manter computação desnecessária ativa
Política de snapshot ou template	Inicia ambientes repetíveis a partir de uma linha de base conhecida
Desmontagem explícita	Remove arquivos, mata processos e libera credenciais após o job

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

Registro em log, limpeza e revisão humana

Os logs das ferramentas MCP devem responder a perguntas de segurança e depuração sem se tornar um novo repositório de segredos. Logs úteis incluem nome da ferramenta, identidade do chamador, ID da 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údos completos de arquivos ou saída completa de comandos por padrão. Mantenha traces sensíveis atrás de controles de acesso mais rigorosos e políticas de retenção.

Algumas ações do MCP devem permanecer sob revisão humana mesmo dentro de uma 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 workspace.
• Chamar APIs internas com permissões de escrita.

A 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 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 ferramentas precisa de um workspace 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 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 várias etapas.
• Executar trabalho em segundo plano que o agente possa verificar posteriormente.
• 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 log e comportamento de limpeza. A sandbox fornece o ambiente isolado onde essas decisões são aplicadas.

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

para cada tarefa do agente:
  criar sandbox a partir de template aprovado
  montar apenas o workspace da tarefa
  injetar apenas segredos específicos da ferramenta
  iniciar o servidor MCP dentro da sandbox ou conectar a uma API de ferramenta com suporte a 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 a sandbox de acordo com o ciclo de vida da tarefa

Isso mantém a orientação em nível de artigo estável, enquanto deixa 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 semi-autônomo:

Área	Perguntas a responder
Escopo da ferramenta	Quais ferramentas o servidor expõe e quais alteram o estado externo?
Posicionamento	O servidor deve ser executado na sandbox do agente, em uma sandbox separada ou fora da 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 definidas em escopo e onde podem aparecer em logs ou saídas?
Rede	A saída é negação padrão, roteada por proxy ou permitida 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ê consegue reconstruir chamadas de ferramenta, alterações de arquivos, domínios externos e artefatos sem armazenar segredos?
Revisão humana	Quais chamadas de ferramenta exigem aprovação antes de execução, exportação, implantação ou ação voltada ao cliente?
Testes	Você testou injeção de prompt, travessia de caminho/link simbólico, saída grande, limpeza falha e caminhos de saída negados?

O MCP facilita a integração de ferramentas. A sandbox 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 da 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 uma 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, registro em log e controles de rede, mas podem não precisar de uma sandbox dedicada 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 ao sistema de arquivos, ambiente e rede local. 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 ele recebe.

As raízes (roots) do MCP podem substituir a sandbox de sistema de arquivos?

Não. As raízes ajudam a comunicar os locais de workspace pretendidos 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 em nível de 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 com escopo. 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 ação de comando ou rede fora da política normal do workspace.

Artigos recomendados

• Construa um Servidor MCP de Execução Remota de Código com Novita Sandbox e a Biblioteca mcp-use
• Construindo um Agente de Codificação com o Agent Sandbox da Novita
• Como Sandboxes de Agentes Potencializam Inovação em IA Segura e Escalável