Autorização de Ferramentas Baseada em Certificado para Agentes MCP
O Protocolo de Contexto de Modelo (MCP) define como modelos de linguagem chamam ferramentas externas. Ele não define quem tem permissão para chamá-las.
A invocação de ferramentas é uma fronteira de segurança. O MCP não a impõe.
A maioria dos sistemas de agentes depende de uma chave de API compartilhada que é verificada uma vez no momento da conexão. Depois disso, todas as ferramentas por trás daquela chave são acessíveis. Isso funciona quando um processo de agente possui as ferramentas e opera sob uma única identidade. Isso colapsa quando um servidor MCP centralizado executa ferramentas para muitos usuários, porque a chave compartilhada não pode distinguir quem tem permissão para fazer o quê.
Com essa abordagem, você não pode expressar o menor privilégio, um princípio fundamental em posturas de segurança como defesa em profundidade. Você não pode vincular o uso da ferramenta a uma identidade criptográfica real. Seu log de auditoria mostra que o agente chamou database_query, mas não mostra qual usuário causou essa chamada.
Eu construí um protótipo que impõe a autorização de ferramentas baseada em identidade para o MCP usando certificados X.509.
Isso começou como uma exploração de se a identidade do usuário no contexto da Infraestrutura de Chave Pública (PKI) poderia ser mapeada de forma limpa no modelo de ferramentas do MCP. Neste protótipo, esse mapeamento de identidade é direto.
O Padrão
Cada usuário possui um certificado X.509 privado e um público que codifica as ferramentas MCP que podem invocar. O servidor MCP impõe a autorização diretamente daquele certificado em cada chamada de ferramenta iniciada em nome de um LLM.
- Sem busca de permissão externa.
- Sem chave de API compartilhada.
- Sem controles de acesso abrangentes no nível da sessão.
A autorização de ferramentas acontece por chamada.
Esta implementação é um servidor MCP funcional chamado por um LLM rodando no Ollama. Existem três usuários e três conjuntos de permissões. Um LLM selecionando ferramentas em tempo real. Cada tentativa de acesso à ferramenta é registrada.
Arquitetura
Uma autoridade certificadora RSA de 2048 bits local é gerada na inicialização da demonstração e assina os certificados dos usuários. O servidor MCP confia apenas naquela CA.
Cada certificado contém uma extensão personalizada com OID 1.3.6.1.4.1.99999.1. Este OID vive sob o arco do Número de Empresa Privada da IANA (1.3.6.1.4.1). O valor 99999 é usado aqui como um identificador de empresa de espaço reservado para o protótipo. Um sistema de produção registraria um Número de Empresa Privada oficial com a IANA e definiria a extensão sob aquele ramo atribuído.
O valor da extensão é JSON codificado em UTF-8:
{"allowed_tools": ["web_search", "summarization"]}
A extensão é armazenada como uma UnrecognizedExtension contendo bytes brutos. Neste caso, não há um wrapper ASN.1.
Neste protótipo, o parser e o escritor vivem na mesma base de código. Usar JSON bruto mantém o tráfego legível. Um sistema de produção deve definir uma estrutura ASN.1 adequada para conformidade com o RFC 5280 e interoperabilidade com ferramentas padrão.
O LLM se comunica com o servidor MCP via JSON-RPC usando transporte stdio. Cada cenário de demonstração gera um novo processo de servidor. Não há sessão persistente, nem conexões simultâneas, e nenhum estado de sessão entre chamadas.
Uma implantação de produção usaria HTTP com TLS mútuo, validando o certificado do cliente na camada de transporte antes de processar qualquer solicitação de ferramenta.
O cliente orquestra toda a troca. O LLM nunca se conecta diretamente ao servidor MCP. Quando o modelo seleciona uma ferramenta, ele retorna essa seleção ao cliente. O cliente então emite a solicitação MCP em nome do modelo, assina-a com a chave privada do usuário e retorna o resultado da ferramenta de volta ao modelo.
A interação se parece com isso:
O cliente apresenta o certificado e prova a posse da chave privada correspondente assinando o payload da solicitação MCP. O servidor verifica a assinatura antes de avaliar as permissões.
Em cada invocação de ferramenta, o servidor MCP:
- Valida a assinatura do certificado contra a CA confiável
- Verifica a assinatura da solicitação usando a chave pública no certificado
- Extrai a lista de allowed_tools da extensão
- Verifica se a ferramenta solicitada é permitida
- Adiciona uma entrada ao audit.jsonl
- Se a validação da solicitação falhar, o acesso é negado.
- Se a extensão estiver ausente ou malformada, o acesso é negado.
- Se a ferramenta não estiver listada no conjunto de ferramentas permitidas, o acesso é negado.
Não há caminhos de fallback.
As Ferramentas
O servidor MCP registra quatro ferramentas:
- web_search
- summarization
- database_query
- file_operations
Todas retornam dados simulados. A imposição é realizada pelo servidor MCP.
As Identidades da Demonstração
A demonstração provisiona três usuários:
| Usuário | Ferramentas Permitidas |
|---|---|
| alice |
web_search, summarization
|
| bob |
web_search, summarization, database_query, file_operations
|
| carol | summarization |
Um fluxo concreto:
Alice envia uma solicitação: "Buscar por computação quântica."
O cliente envia essa tarefa para o Ollama com as quatro definições de ferramenta. O modelo seleciona web_search. O cliente assina a solicitação MCP com a chave privada de Alice e inclui seu certificado.
O servidor MCP valida a cadeia de certificados. Ele verifica a assinatura da solicitação. Extrai a extensão e vê que web_search é permitido. A chamada prossegue. Uma entrada de auditoria é escrita.
Carol envia uma tarefa que leva o modelo a selecionar database_query. O cliente assina a solicitação com sua chave e apresenta seu certificado ao servidor MCP. O servidor valida a cadeia, verifica a assinatura, extrai a extensão e descobre que apenas summarization é permitido. O servidor MCP rejeita a chamada. O log de auditoria registra tanto a ferramenta tentada quanto a consulta SQL que o LLM tentou executar em nome de Alice.
Cada chamada ao servidor MCP é avaliada de forma independente. Bob pode invocar duas ferramentas com quatro milissegundos de diferença e ambas são validadas com base nas operações autorizadas de Bob.
Seleção de Ferramentas Versus Autorização
O modelo decide quais ferramentas deseja chamar. O servidor MCP decide se essas chamadas de ferramentas são permitidas.
O cliente carrega o certificado e a chave privada de um usuário, envia a tarefa para o Ollama, recebe uma seleção de ferramenta
A implementação de autorização baseada em identidade é crucial para empresas que utilizam agentes de IA, pois permite um controle mais rigoroso sobre quem pode acessar quais ferramentas. Isso é especialmente relevante em ambientes corporativos onde a segurança de dados é uma prioridade.
