Guia
Como implementar RBAC e Filtragem de Ferramentas em Servidores MCP?
Para implementar RBAC em servidores MCP, você deve integrar um provedor de identidade via OAuth 2.1, validar os tokens em cada requisição e utilizar o endpoint listTools para retornar dinamicamente apenas as ferramentas permitidas para a função do usuário. Esse modelo de deny-by-default impede que agentes executem ações sensíveis sem autorização explícita, sendo essencial para ambientes corporativos que exigem isolamento de dados e privilégios mínimos em fluxos de IA.
Em 2026, a maturidade do ecossistema Claude transformou o Model Context Protocol (MCP) de uma novidade experimental em uma infraestrutura crítica de TI. No entanto, com a autonomia crescente dos agentes, o risco de segurança também escalou. O uso de permissões excessivas — onde um agente tem acesso total a bancos de dados ou APIs via MCP — tornou-se o principal vetor de ataques de injeção de comandos indireta. Implementar o Controle de Acesso Baseado em Função (RBAC) não é mais opcional; é a base para qualquer deploy de IA agentica em larga escala.
Por que o controle de acesso é o novo padrão para MCP?
No início do protocolo, a maioria dos servidores MCP operava em um modelo de “tudo ou nada”. Se o Claude estivesse conectado a um servidor de banco de dados, ele teoricamente poderia ler e escrever em qualquer tabela. Com a especificação MCP evoluindo (veja mais em modelcontextprotocol.io), o foco mudou para o Princípio do Menor Privilégio. O RBAC no MCP permite que você defina que um desenvolvedor júnior usando o Claude Code tenha permissões apenas de leitura em produção, enquanto um engenheiro sênior possa disparar scripts de manutenção. Sem essa camada, um agente manipulado por um prompt malicioso poderia exfiltrar dados sensíveis ou deletar recursos críticos.
Como funciona a Filtragem Dinâmica de Ferramentas?
Uma das funcionalidades mais poderosas introduzidas na especificação é a capacidade de listar ferramentas de forma dinâmica. Em vez de o servidor enviar uma lista estática de recursos para o Claude, o endpoint tools/list pode ser condicional. Quando o cliente (Claude Desktop ou uma aplicação via API) solicita as ferramentas disponíveis, o servidor MCP verifica o contexto do usuário (via token JWT ou sessão) e filtra o JSON de resposta.
Abaixo, um exemplo da lógica de filtragem que deve ser implementada no lado do servidor:
| Função (Role) | Ferramentas Visíveis | Permissões Efetivas |
|---|---|---|
| Viewer | read_log, search_docs | Somente leitura, sem alteração de estado. |
| Developer | read_log, push_code, run_tests | Escrita em ambientes de staging/dev. |
| Admin | * (Todas) | Acesso total, incluindo gestão de infraestrutura. |
O papel do OAuth 2.1 e das Notificações de Mudança
A autenticação é tratada pelo OAuth 2.1, conforme padronizado pela Anthropic (detalhes em docs.claude.com). Mas a mágica do RBAC acontece na autorização. Quando o nível de acesso de um usuário muda durante uma sessão, o servidor pode enviar uma notificação notifications/tools/list_changed. Isso força o Claude a invalidar o cache local de ferramentas e solicitar a nova lista permitida imediatamente. Essa reatividade é crucial para revogar acessos em tempo real sem precisar encerrar a sessão de chat do usuário.
Implementando a lógica de ‘Deny-by-Default’
A melhor prática de segurança em 2026 dita que qualquer chamada para tools/call deve passar por um interceptor de autorização. Mesmo que uma ferramenta esteja listada, o servidor deve validar novamente o token de acesso no momento da execução. Isso protege contra ataques onde um agente tenta adivinhar o nome de uma ferramenta restrita.
Para desenvolvedores TypeScript usando o SDK oficial, isso significa envolver o handler principal em uma função de validação:
- O servidor recebe o
call_tool. - O middleware extrai o
user_ide oroledo cabeçalho da requisição. - O servidor verifica se o
rolepossui a capability específica para aquela ferramenta. - Se não permitido, retorna um erro de
InsuficientPermissions(código -32003 no JSON-RPC).
Monitoramento e Auditoria com a Compliance API
Para empresas que utilizam o plano Claude Enterprise, o RBAC deve ser integrado à Compliance API da Anthropic. Isso permite que cada tentativa de acesso negada pelo servidor MCP seja logada centralmente. Em 2026, ferramentas de SIEM como Splunk e Datadog já possuem conectores nativos que monitoram esses logs de auditoria, permitindo identificar padrões de “jailbreak” ou tentativas de escalação de privilégios por parte dos usuários finais. Saiba mais sobre governança corporativa em anthropic.com.
Leia mais no site
- Como implementar Autenticação OAuth em Servidores MCP para o Claude?
- Claude MCP Inspector: Como Testar e Validar seus Servidores MCP?
- Como filtrar dados sensíveis em Agentes Claude usando MCP?
- MCP Server: Python vs. TypeScript? Qual escolher para o Claude em 2026?
- Como implementar observabilidade e tracing em agentes Claude?
Perguntas frequentes
O Claude consegue burlar o RBAC definido no servidor MCP?
Não. Como a lógica de filtragem e execução reside no servidor MCP (backend), o Claude só 'conhece' e pode chamar as ferramentas que o servidor decide listar. Se o servidor for configurado corretamente com uma política de negação padrão, o modelo não tem meios técnicos de forçar a execução de uma ferramenta para a qual não recebeu permissão.
Qual o impacto na latência ao usar filtragem dinâmica de ferramentas?
O impacto é mínimo (geralmente <50ms), pois a verificação de permissões ocorre na memória do servidor MCP. No entanto, é recomendável usar um cache distribuído como Redis para armazenar as permissões de funções complexas, garantindo que o endpoint listTools responda rapidamente mesmo em ambientes com milhares de usuários simultâneos.