Conectando um servidor MCP dá mãos ao seu agente. Também dá a um estranho uma maneira de entrar.

No momento em que você conecta um servidor MCP, seu agente de codificação deixa de ser uma coisa que lê e escreve em seu repositório e se torna uma coisa que pode alcançar e agir. Ler um banco de dados, acessar uma API, tocar um serviço, puxar uma página da web. Essa é toda a atração. É também todo o problema, e os dois são a mesma característica vista de dois lados.

Eu passei por isso ao conectar ferramentas para meu próprio trabalho de plugin, e a coisa que me salvou de um erro pior foi uma cicatriz que eu já tinha. Eu havia enviado um chatbot de IA anteriormente, onde renderizei a saída do modelo diretamente na página e cometi um erro de injeção de HTML. Aquela me ensinou uma regra da maneira mais difícil: qualquer coisa que um LLM devolve é entrada não confiável. O MCP é essa mesma lição com o raio de explosão aumentado, porque agora a coisa não confiável não é apenas o texto do meu modelo, é o que quer que um servidor conectado decida retornar.

Dois medos diferentes, e as pessoas só têm um

Quando as pessoas falam sobre segurança do agente, quase sempre querem dizer: e se o agente executar algo destrutivo. Deletar arquivos, forçar um push, acessar algo que não deveria. Esse medo é real e tem uma resposta real, que eu vou abordar.

Mas isso é apenas metade da ameaça, e é a metade visível. A outra metade é mais silenciosa: e se o agente acreditar em algo que não deveria. Um servidor MCP retorna uma resposta de API, uma linha de banco de dados, um corpo de problema, um thread de e-mail, e em algum lugar nesse conteúdo retornado há uma linha que parece uma instrução. O modelo não tem uma maneira confiável de distinguir sua instrução do texto que chegou dentro dos dados. Para ele, eles são o mesmo canal. Portanto, o perigo não é apenas o comando que o agente executa, é o comando que ele é convencido a executar por conteúdo que voltou através de uma ferramenta.

Esses são dois problemas separados, e eles precisam de duas defesas separadas. A maioria das configurações instala uma e assume que está coberta.

O lado da saída: trate cada retorno de ferramenta como um campo de formulário

Aqui está a regra que eu carrego da falha do chatbot. O que quer que um servidor MCP retorne está exatamente na mesma categoria de confiança que uma string que um estranho digitou em um formulário em seu site. Não "dados da minha ferramenta." Dados de fora, que acontecem de chegar através da minha ferramenta.

Essa reformulação muda o que você faz com isso. Você não passa a saída bruta de uma ferramenta diretamente para os argumentos do próximo comando. Você não a renderiza na tela sem escapar. E você não deixa uma frase imperativa enterrada em um documento retornado se tornar silenciosamente algo que o agente trata como uma diretiva. A saída é uma carga a ser inspecionada, não um valor a ser confiado, e o fato de que veio de um servidor ao qual você se conectou não a limpa. Você conectou o tubo. Você não garantiu tudo que flui através dele.

Essa é a metade que as ferramentas não farão por você, porque não podem. Nenhuma flag de sandbox sabe se uma string retornada é um resultado legítimo de API ou uma instrução plantada. Esse julgamento reside em como você conecta os dados, não em uma configuração.

O lado da ação: paredes, não maneiras

A outra metade, o medo do comando destrutivo, tem uma resposta de configuração, e vale a pena acertar exatamente, porque é fácil fazer isso pela metade.

Pedir ao modelo educadamente para não executar coisas perigosas é maneiras, e maneiras são contornadas no momento em que a entrada o convence a fazer algo. O que você quer é uma parede. No Claude Code, isso é o sandbox: ligue-o e a execução do Bash é isolada no nível do OS, com a restrição herdada por cada subprocesso que o agente gera. Cinto de segurança no macOS, Bubblewrap no Linux e WSL2.

// .claude/settings.json
{
  "sandbox": {
    "enabled": true,
    "allowUnsandboxedCommands": false
  }
}

Aqui está a parte que me surpreendeu, diretamente da documentação: o sandbox restringe gravações no seu diretório de trabalho, mas por padrão ainda permite leituras na maior parte da máquina. O que significa que credenciais como ~/.aws/credentials e ~/.ssh/ são legíveis, a menos que você diga o contrário. O sandbox é uma parede ao redor da gravação e execução, não ao redor da leitura. A leitura você fecha, com regras de negação:

{
  "permissions": {
    "deny": [
      "Bash(rm -rf *)",
      "Bash(curl *)",
      "Bash(wget *)",
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(~/.ssh/**)",
      "Read(~/.aws/**)"
    ]
  }
}

Essa é a combinação que realmente importa, e é exatamente onde as duas metades se encontram. Se um retorno de ferramenta convence o agente a exfiltrar um segredo, a negação de leitura é o que impede que ele leia o segredo, e a negação de comando de rede é o que impede que ele o envie. O problema do lado da saída é o que faz o agente tentar; as paredes do lado da ação são o que fazem a tentativa falhar. Nenhum cobre o outro.

A terceira coisa: não conecte o que você não confia, ou não precisa

O servidor em si é uma superfície de ataque. Um servidor MCP conectado que você não verificou é código rodando em seu loop com um canal para seu agente. Portanto, três hábitos, nenhum deles inteligente:

Verifique a fonte antes de conectá-la. Quem a escreveu, você pode ver o código. Um servidor MCP não é uma aba do navegador que você pode fechar e esquecer; enquanto estiver conectado, faz parte de sua fronteira de confiança.

Desconecte os que você não está usando. Cada servidor ocioso é uma superfície de ataque e peso de contexto ao mesmo tempo, e /mcp mostrará o que está realmente conectado versus o que você conectou uma vez e esqueceu.

E a que eu mais uso: se um CLI já faz o trabalho, não levante um servidor. Eu gerencio o WordPress com wp-cli, e em vez de envolvê-lo em um servidor MCP, eu o chamo de uma Skill quando preciso. Uma superfície sempre conectada a menos, uma coisa a menos retornando conteúdo que eu teria que desconfiar. "Conectar um servidor" e "chamar um comando" não são o mesmo risco, e o segundo é muitas vezes o menor.

O que eu realmente verifico agora

Antes de conectar qualquer servidor MCP, três perguntas, nesta ordem. Eu confio de onde veio este servidor? Qual é o pior comando que ele poderia convencer meu agente a executar, e esse comando está isolado por regras de negação? E a saída será tratada como entrada não confiável em todos os lugares onde ela pousar, ou estou prestes a passar o texto de um estranho diretamente para um destino?

O sandbox responde exatamente uma dessas. As outras duas estão comigo, e elas são as que...