Listas de permissões de servidores MCP: por que os sistemas agênticos precisam de firewalls de capacidade

A segurança de prompts é útil, mas não resolve o problema real quando um agente tem amplo alcance de ferramentas. A solução são os firewalls de capacidade: listas de permissões explícitas para quais ações são permitidas, onde podem ser executadas e quais dados podem tocar.

O alcance da ferramenta é o verdadeiro raio de impacto

As equipes continuam gastando energia na filtragem de prompts, enquanto concedem silenciosamente aos agentes acesso a shells, sistemas de arquivos, APIs de tickets, painéis de nuvem e armazenamentos de conhecimento interno. Isso está ao contrário. Um prompt estranho é recuperável. Uma ferramenta de alto privilégio com limites desleixados é como você causa danos reais.

Servidores MCP e conectores de agentes semelhantes devem ser tratados como middleware privilegiado, e não como plug-ins de conveniência. Se conseguirem conectar solicitações não confiáveis a sistemas confiáveis, precisarão de limites rígidos de capacidade.

O que um firewall de capacidade realmente significa

Se a sua política de conector for basicamente “ativada ou desativada”, ela será permissiva demais. A segurança real reside nas permissões com escopo definido, não em uma opção binária.

O padrão de fracasso que todos repetem

Um agente interno obtém acesso a uma ferramenta flexível. A ferramenta pode ler e escrever amplamente. O sistema assume que o prompt e a mensagem do sistema manterão o agente dentro dos limites. Então, um documento envenenado, uma saída de ferramenta enganosa ou um caminho alternativo mal projetado leva o fluxo de trabalho a algum lugar onde ele nunca deveria ter ido.

A causa raiz não é a falha mágica da IA. É uma falha de autorização comum disfarçada pelo marketing de IA.

Controles mínimos que deveriam existir agora

• Escopos por ferramenta, não escopos globais do agente.
• Permissões de leitura e gravação divididas por padrão.
• Listas de permissões de host de saída para cada conector compatível com rede.
• Registro estruturado da ação solicitada, escopo aprovado e meta de execução real.
• Adote interruptores de emergência para conectores que começam a se comportar de maneira estranha.

Isso não é engenharia excessiva. É uma contenção básica. Se um conector puder tocar dados de produção, finanças, identidade ou clientes, a prioridade deve ser a contenção.

Como equipes que adotam a abordagem do KENSAI devem avaliar o risco do conector

Comece listando todos os conectores que podem executar ações de alteração de estado. Em seguida, pergunte o que acontece se o fluxo de trabalho receber instruções hostis, contexto enganoso ou conteúdo recuperado excessivamente amplo. Se a resposta incluir execução de código, alterações de registro, acesso a credenciais ou transmissão de dados para sistemas externos, o conector precisará de um escopo mais rígido imediatamente.

A mentalidade certa é simples: trate a expansão de capacidade como abrir portas de firewall. Cada nova ação deve merecer o seu lugar.

A recomendação contundente

A negação padrão vence. Dê aos agentes o menor conjunto útil de ações, limite onde essas ações podem ocorrer e exija aprovação explícita para qualquer coisa cara, destrutiva ou sensível à privacidade. Os firewalls de capacidade são menos atraentes do que as demonstrações dos agentes, mas são a diferença entre um sistema poderoso e um risco grave.