Ferramentas MCP controladas para agentes de IA

O Model Context Protocol facilita a ligação de um modelo ou agente a ferramentas. O próprio protocolo não decide se o agente deve ser autorizado a executar uma operação específica, em que recurso e com que consequência. A camada de aplicação ainda tem de impor esses limites.

Se um agente pode usar o MCP para ler um relatório, alterar a configuração, começar a gastar dinheiro ou eliminar um recurso, tratamo‑lo como um cliente de API privilegiado. O prompt descreve a intenção. O gateway impõe os limites.

Na prática, desenhamos esse limite em torno de sete princípios.

1. Separar a identidade do operador das credenciais do sistema‑alvo

Um agente actua em nome de alguém. Por isso precisamos responder, pelo menos, a duas perguntas distintas:

• quem solicitou esta operação e o que essa pessoa tem permissão para fazer no Brillnet?
• como o Brillnet autentica‑se junto ao fornecedor externo?

Não são a mesma coisa.

Na nossa ferramenta interna Brillnet Ads MCP, o operador passa pela camada de autorização do Brillnet, enquanto as chamadas ao Google utilizam uma identidade de serviço separada. O token do fornecedor tem vida curta e não é devolvido ao modelo através do MCP como dado.

O modelo não precisa conhecer uma credencial para executar uma tarefa permitida. Também não pode colar acidentalmente essa credencial numa resposta se nunca a recebeu.

Regra

Um segredo deve estar disponível apenas ao componente que precisa usá‑lo, não a toda a cadeia de execução.

2. Expressar permissões por operação, não apenas por nome de agente

Um papel como marketing-agent é fácil de ler, mas, por si só, diz muito pouco sobre o que o sistema realmente permitirá.

É mais útil separar as permissões por consequência:

read
→ relatórios e recuperação

write
→ criar ou modificar um recurso

operate
→ ativar uma consequência operacional, como gasto ou publicação

destructive
→ eliminar, desvincular, revogar ou fazer outra alteração difícil de reverter

Um agente pode ter read sem write. Pode ter write para preparar uma campanha, mas não operate, logo não pode ativar essa campanha. A eliminação pode exigir tanto write + destructive.

Os nomes não precisam ser exatamente esses. A distinção importante é entre preparar uma mudança e ativar a sua consequência.

Leia: Privilégio mínimo para agentes de IA

3. Os padrões seguros devem funcionar sem ajuda do modelo

Se a omissão de um parâmetro pode ativar uma ação, o padrão é inseguro.

Na nossa ferramenta interna Brillnet Ads MCP, uma nova campanha permanece PAUSED quando nenhum estado é explicitamente fornecido. O detalhe parece pequeno, mas a regra é crucial: informação ausente não equivale a consentimento para iniciar gastos.

O mesmo padrão aplica‑se a outros contextos:

• documento sem estado → rascunho, não publicado;
• novo utilizador sem papel → sem acesso, não um papel padrão;
• integração sem destino confirmado → sem sincronização;
• recurso ambíguo → erro, não o registo “mais provável”;
• aprovação ausente para ação de alto risco → parar, não tentar novamente.

Um padrão seguro deve permanecer seguro quando o modelo alucina, omite um campo ou interpreta mal a intenção.

4. Operações de alto impacto precisam de um portão separado

Um agente pode preparar uma mudança tecnicamente correta que ainda assim seja a decisão de negócio errada.

Gastar orçamento, publicar conteúdo, enviar mensagem a um cliente, mudar acessos ou eliminar dados gera consequências que ultrapassam a sessão do agente. A aprovação deve, portanto, ser um evento independente.

No mínimo, uma pré‑visualização de aprovação deve mostrar:

• sistema‑alvo e recurso;
• tipo de operação;
• parâmetros materiais da mudança;
• consequência esperada;
• se a operação é reversível;
• quem está a aprovar.

“Continuar?” não basta. A pessoa precisa saber exatamente o que está a aprovar.

Leia: Quando um agente de IA deve requerer aprovação humana?

5. Uma repetição não deve duplicar silenciosamente uma escrita

Sistemas agenticos fazem muitas chamadas de API. Erros de rede, tempos limite e tentativas de novo são normais. O problema surge quando repetir a mesma operação cria um segundo recurso ou executa um segundo pagamento, publicação ou mensagem.

Quando a operação o permite, usamos uma chave de idempotência. O gateway reconhece a mesma tentativa e impede uma escrita duplicada não controlada.

Isso deve ser combinado com read‑after‑write:

agente solicita uma mudança
↓
gateway valida e executa a escrita
↓
sistema‑alvo responde
↓
gateway lê o estado resultante do recurso
↓
operador vê o estado resultante

Um fornecedor que devolve HTTP 200 deixa de ser a única evidência de que o sistema está no estado esperado.

6. Um gateway bruto não deve tornar‑se uma porta dos fundos

Grandes APIs criam uma tentação prática: em vez de construir uma ferramenta dedicada para cada ponto de extremidade, expor uma capacidade REST mais geral.

Isso pode ser razoável, mas apenas se o caminho geral herdar os mesmos controlos.

No Brillnet, método, ponto de extremidade e características da requisição são classificados antes da execução. Uma requisição de baixo nível não contorna os escopos funcionais exigidos nem o controlo adicional para operações destrutivas.

O anti‑padrão parece‑se com isto:

ferramentas MCP seguras
→ escopos e validações

raw_http_request
→ pode chamar qualquer ponto de extremidade com um token de acesso total

Nesse desenho, os controlos anteriores são em grande parte cosméticos. O caminho mais amplo define a verdadeira fronteira de segurança.

7. O registo de auditoria grava a decisão e o resultado, não os segredos

A nossa ferramenta interna grava metadados de requisição e resultados numa cadeia de auditoria apenas‑acréscimo e controlada por integridade. Credenciais, cabeçalhos de autorização e identificadores pessoais brutos são excluídos.

Essa distinção importa. Um registo de auditoria deve reconstruir uma ação, não duplicar o contexto de segurança para outro repositório de dados.

Para uma operação de agente, normalmente queremos saber:

• ID da requisição/tarefa;
• identidade do operador e do agente;
• ferramenta e classe da operação;
• recurso alvo;
• decisão de autorização;
• ID da aprovação, se exigida;
• resultado do fornecedor/backend;
• estado observado após uma escrita;
• versão da política ou configuração que se aplicou.

Leia: Registos de auditoria de agentes de IA

Exemplo de arquitetura: um agente para Google Ads

O nosso caso interno é deliberadamente estreito. A ferramenta é usada apenas para contas Google Ads de propriedade do Brillnet. Não é um serviço de agência e não recebe acesso a contas de anúncios de clientes.

O fluxo pode ser simplificado para:

operador Brillnet
↓
identidade + perfil + escopos
↓
agente / modelo
↓
chamada da ferramenta MCP
↓
gateway: validação + classificação + política de aprovação
↓
token de fornecedor de vida curta
↓
Google Ads API
↓
normalização + redação
↓
read‑after‑write / resultado
↓
registo de auditoria

O controlo mais importante não está dentro do modelo. Está na camada entre a intenção e a execução.

Anti‑padrões de aparência conveniente

Um token de administrador para cada agente

Facilita o protótipo. Mais tarde, torna‑se difícil limitar o impacto de um erro ou provar que um agente deveria ter tido acesso a um recurso.

“O modelo vai perguntar ao utilizador se a ação é arriscada”

Isso delega a decisão de segurança ao mesmo componente cujos erros o controlo pretende conter.

Registar o prompt completo e a resposta como registo de auditoria

Uma conversa não é um registo operacional de auditoria. Pode ainda conter informação que não deve ser copiada para o sistema de registo.

Repetir automaticamente cada erro

Nem todo erro é transitório. Nem toda escrita é idempotente. Uma repetição não classificada pode aumentar o dano.

Um ponto de extremidade universal com acesso total “para funcionalidades futuras”

Se uma ferramenta ampla pode contornar as ferramentas restritas, a ferramenta ampla é o verdadeiro modelo de permissões.

Lista de verificação para revisão do servidor MCP

Antes de usar em produção, verificaria pelo menos:

• A identidade do operador é conhecida para cada chamada?
• As credenciais do sistema‑alvo estão ocultas ao modelo?
• As permissões de ler, escrever, operar e destrutivo podem ser separadas?
• A autorização restringe o recurso/inquilino/conta assim como a função?
• A omissão de um parâmetro conduz a um estado seguro?
• Operações financeiras, externas e destrutivas têm aprovação independente?
• As repetições de escrita são controladas?
• O recurso alvo é lido novamente após uma escrita?
• Qualquer gateway de baixo nível usa as mesmas regras de autorização?
• O registo de auditoria exclui tokens, segredos e dados pessoais brutos?
• Caminhos de sistema de ficheiros arbitrários e cargas úteis ilimitadas são rejeitados?
• O acesso de agente ou operador pode ser revogado centralmente?

MCP 2026‑07‑28 altera o protocolo, não a necessidade de controlos de aplicação

A versão 2026-07-28 do MCP introduziu, entre outras mudanças, um núcleo de protocolo sem estado e um reforço adicional de autorização. Essas alterações facilitam a escalabilidade e a compreensão da camada de comunicação. Elas não decidem a política de negócio para uma implantação: se um agente pode gastar 5 000 PLN, eliminar uma conta ou enviar mensagem a 10 000 pessoas.

A aplicação ainda tem de impor essa decisão.

Quem precisa deste padrão de design

Responsáveis de processo, desenvolvedores e revisores de segurança precisam desta fronteira. Agentes de fabricação podem redigir pedidos de mudança; agentes de gestão de propriedades podem organizar documentos; agentes B2B podem analisar tickets. Enviar avisos a residentes ou mudar permissões de clientes requer controlo da consequência.

O exemplo Ads MCP provém de documentação de design de ferramenta interna. Não descreve um serviço de contas publicitárias de cliente nem uma auditoria independente do ambiente de produção atual.

Identidade e isolamento exigem mais que um token válido

A autorização MCP requer tokens destinados ao recurso próprio do servidor. Uma assinatura válida num token de outro serviço é insuficiente. Verifique o público, o emissor e a validade. Rejeite tokens inadequados antes da execução.

Também verifique o acesso ao recurso. Compare um tenant_id fornecido com a identidade estabelecida pelo servidor, em vez de confiar no identificador do agente. Cada leitura e escrita precisa de autorização de recurso, incluindo anexos, exportações e trabalhos em segundo plano.

O MCP 2026-07-28 não tem sessões a nível de protocolo. As aplicações ainda podem manter estado, como um identificador de pré‑visualização de mudança. Posse não substitui autenticação. Vincule identificadores a operadores autorizados, verifique cada uso e defina expiração. Um identificador roubado não deve expor o fluxo de trabalho de outra pessoa.

Validar conteúdo e destinos de comunicação

Resultados de pesquisa, PDFs, e‑mails e respostas de API são material de análise. Instruções embutidas para obter segredos ou enviar documentos para outro local não constituem aprovação do operador. Para proteção contra injeção de prompt, o servidor deve rejeitar recursos, destinatários e operações não autorizados, mesmo quando os argumentos da ferramenta são tecnicamente válidos.

Para uma ferramenta que aceita URLs, defina destinos permitidos e tratamento de redirecionamentos. As orientações do MCP abordam SSRF na descoberta de metadados OAuth. Avalie o mesmo problema em ferramentas de recuperação personalizadas. Permissão para buscar uma página pública não deve expor um serviço de administração local ou ponto de extremidade de metadados da nuvem. As protecções dependem da arquitetura de rede; uma lista de nomes de host sozinha pode não controlar o destino final da conexão.

Para ferramentas de ficheiros, restrinja diretórios e tamanho da carga útil. Rejeite caminhos fora da área permitida, campos desconhecidos e exportações excessivas. Um erro explícito é preferível a expandir silenciosamente a atribuição.

Um pequeno cenário de implantação: rascunhos de tickets de serviço

Imagine que uma empresa queira reduzir o tempo de preparação de tickets de incidentes de equipamento. O agente lê um manual aprovado e o histórico de incidentes, depois prepara um rascunho. Enviá‑lo a um fornecedor continua a ser uma operação separada. Este é um cenário de design, não uma afirmação de que o Brillnet oferece atualmente essa funcionalidade.

O proprietário do serviço seleciona um grupo de equipamento e define a saída esperada: um rascunho que identifique o equipamento, sintoma, hora do evento e informação em falta. O desenvolvedor expõe duas ferramentas estreitas: recuperação de documento aprovado e criação de rascunho num projeto especificado. A versão inicial não fornece nem mensagens nem configuração de equipamento. O revisor de segurança verifica o escopo de dados e a revogação central de acesso.

Teste uma leitura permitida, uma tentativa de leitura cruzada de projeto, um documento contendo instruções maliciosas e uma repetição de escrita após timeout. Um pequeno catálogo de ferramentas basta para iniciar. Ele deve impor as restrições que o design promete.

Se o envio for adicionado mais tarde, a aprovação deve cobrir o destinatário e o conteúdo. Alterar o destinatário invalida a aprovação anterior. Quando um fornecedor não oferece suporte a idempotência, resolva um timeout ambíguo verificando se a mensagem já existe. Não reenvie simplesmente porque o agente não recebeu resposta.

O que fazer amanhã, com um proprietário

O proprietário do processo escolhe uma ação e a consequência permitida. O desenvolvedor mapeia ferramenta, operação e recurso, incluindo o caminho de acesso mais amplo disponível. O revisor de segurança verifica onde termina a identidade do operador, onde começa a identidade do serviço e se o modelo pode aceder a credenciais. O resultado do primeiro dia deve ser um mapa curto e uma execução cujo estado resultante possa ser verificado no sistema alvo.

Meça a qualidade dos rascunhos aceites, as violações de escopo rejeitadas e o tempo de revisão humana. Mais chamadas de ferramenta não são automaticamente úteis. Se a correção levar mais tempo que a preparação economiza, restrinja a tarefa antes de acrescentar capacidades.

Orientação técnica e obrigações legais

OWASP e NIST fornecem orientação técnica. A especificação MCP define requisitos de protocolo. Estas fontes não determinam independentemente as obrigações legais ou períodos de retenção de dados de uma empresa específica. Estabeleça os requisitos setoriais, contratuais e legais aplicáveis ao processo. Este guia explica o design de controlos e não confere certificação de conformidade.

Fronteira

Estes são padrões que usamos no nosso próprio trabalho. Esta página não afirma que toda a ferramenta está certificada ou universalmente em conformidade com OWASP, NIST ou a especificação completa do MCP. Cada integração ainda necessita do seu próprio modelo de ameaças e testes de segurança.

Se está a avaliar como o Brillnet gere acesso, dados e IA, veja Segurança e Conformidade e supervisão de IA.

Fontes

As fontes técnicas sustentam os princípios declarados. Os cenários de implantação e o plano de ação são recomendações de design do autor.

• Model Context Protocol — Specification 2026-07-28 release — acedido: 2026-10-02.
• Model Context Protocol — Authorization 2026-07-28 — acedido: 2026-10-02.
• Model Context Protocol — Security Best Practices 2026-07-28 — acedido: 2026-10-02.
• OWASP AI Agent Security Cheat Sheet — acedido: 2026-10-02.
• OWASP MCP07:2025 — Insufficient Authentication & Authorization — acedido: 2026-10-02.
• OWASP MCP08:2025 — Lack of Audit and Telemetry — acedido: 2026-10-02.
• OWASP Authorization Cheat Sheet — acedido: 2026-10-02.