Blog / Português
MCP em produção: o problema não é conectar ferramentas, é controlar autoridade
Conectar uma IA ao GitHub, ao banco e ao Slack cria uma demonstração impressionante.
Dar a essa IA autoridade sobre os três cria um sistema que precisa de arquitetura.
O Model Context Protocol, ou MCP, reduz o esforço para uma aplicação de IA descobrir ferramentas, recursos e contratos de entrada e saída. Essa padronização é poderosa. Também torna mais fácil confundir integração com governança.
Uma chamada funcionando prova conectividade. Não prova que o agente deveria ver aquele dado, executar aquela ação ou manter aquela permissão amanhã.
MCP padroniza a porta. A empresa ainda decide quem recebe a chave
Em linguagem simples, MCP permite que um host conecte modelos a servidores que oferecem recursos e ferramentas. O protocolo organiza descoberta, mensagens, contratos e transporte.
Isso resolve uma parte importante da engenharia. A parte difícil começa depois:
- quem pode invocar cada ferramenta;
- em nome de qual usuário ou serviço;
- quais dados entram no contexto;
- quais ações exigem aprovação;
- quanto tempo a credencial permanece válida;
- que evidência será registrada;
- como conter um erro ou uma instrução maliciosa.
O protocolo transporta capacidade. A arquitetura define autoridade.
O erro mais caro é autorizar o agente como se fosse uma pessoa confiável
Um agente não recebe apenas comandos da equipe. Ele também processa issues, documentos, páginas, logs, mensagens e descrições de ferramentas. Parte desse conteúdo pode estar errada ou tentar influenciar seu comportamento.
Quando a mesma identidade consegue ler dados, alterar código, aprovar mudanças e publicar resultados, uma instrução externa pode atravessar todo o fluxo. O problema não é apenas prompt injection. É a combinação de conteúdo não confiável com autoridade ampla.
Por isso, “o usuário autorizou o agente” é uma política insuficiente. A autorização precisa responder a cinco perguntas separadas.
As cinco dimensões da autoridade
1. O que pode ver?
Limite o contexto por projeto, repositório, diretório, tenant, tipo de dado e finalidade. Ler um schema não implica ler dados de produção. Ler uma issue não implica acessar todos os anexos.
2. O que pode fazer?
Permissão deve seguir a capacidade: ler arquivo, editar branch, abrir PR, executar migration, enviar mensagem. Escopos genéricos como “acesso total ao GitHub” escondem ações com riscos muito diferentes.
3. Em nome de quem?
Evite credenciais compartilhadas. Cada chamada precisa preservar a identidade do usuário, agente ou serviço responsável. Sem isso, auditoria vira uma lista de ações sem autor real.
4. Por quanto tempo?
Credenciais temporárias reduzem o estrago de vazamento e esquecimento. Uma tarefa de vinte minutos não precisa de um token válido por meses.
5. Sob qual condição?
Leitura pode ser automática. Uma alteração reversível pode exigir apenas registro. Produção, comunicação externa e operações destrutivas devem depender de aprovação no momento da ação.
Autonomia não é ausência de limites. É liberdade dentro de um contrato observável.
Uma escada de permissão para agentes
| Nível | Capacidade | Controle mínimo |
|---|---|---|
| 1 | ler contexto autorizado | escopo de dados, redaction e log de acesso |
| 2 | propor alteração | saída isolada, diff e nenhuma credencial de escrita |
| 3 | editar ambiente local | sandbox, testes e rollback local |
| 4 | abrir PR ou agir em staging | identidade própria, política por ferramenta e trilha de auditoria |
| 5 | ação externa ou produção | credencial temporária, aprovação imediata e plano de reversão |
O agente deve subir de nível pela necessidade da tarefa, não pela conveniência da configuração. Ao terminar, a autoridade deve expirar.
Quatro atalhos que parecem eficientes
Um token para tudo
É simples até não ser possível saber qual serviço deveria aceitar o token. A especificação MCP exige validação de audiência e proíbe o repasse indevido de tokens entre serviços. Cada recurso precisa reconhecer credenciais destinadas a ele.
A descrição da ferramenta como política
Uma descrição ajuda o modelo a escolher uma função. Ela não deve conceder acesso. Autorização pertence a uma camada determinística, fora do texto que o agente interpreta.
Aprovação no início da sessão
Autorizar uma conexão não significa aprovar todas as ações futuras. O momento de consentimento precisa acompanhar a consequência: publicar, apagar, enviar ou alterar produção.
Logar tudo sem critério
Logs completos podem vazar segredos e dados pessoais. Registre ferramenta, identidade, escopo, horário, decisão de autorização e resultado. Proteja ou elimine o conteúdo sensível que não é necessário para auditoria.
O contrato mínimo de cada ferramenta
Antes de colocar um servidor MCP em produção, documente:
- objetivo da ferramenta;
- dados que ela lê e escreve;
- efeitos externos e reversibilidade;
- identidade usada na execução;
- menor conjunto de permissões;
- condição de aprovação humana;
- timeout, limite de uso e expiração;
- campos registrados para auditoria;
- tratamento de conteúdo não confiável;
- mecanismo de rollback ou contenção.
Se uma ferramenta não consegue preencher esse contrato, ela ainda não está pronta para autoridade de produção.
Onde o ArchGenerator.com entra
Sua equipe pode continuar usando a IA de coding e os servidores MCP que já escolheu. O ArchGenerator.com mantém em uma sede própria da empresa as definições que não deveriam ficar espalhadas entre prompts e configurações.
No discovery e no SPEC, o fluxo do agente ganha objetivo, atores, dados, restrições e critérios de aceite. As decisões arquiteturais registram limites de confiança, identidade e permissão. Os Laudos ajudam a observar a implementação e ligar achados a evidências. O Kit SDD entrega o contrato necessário à IA que executará o coding.
Isso separa responsabilidades: MCP conecta; a ferramenta de coding implementa; o ArchGenerator.com organiza intenção, arquitetura, especificação e governança.
Você não precisa reduzir a autonomia do agente. Precisa impedir que autonomia vire autoridade invisível.
Experimente o ArchGenerator.com modelando um único fluxo MCP crítico. Registre quem pode ver, fazer, aprovar e provar cada ação. Quando o próximo servidor for conectado, sua equipe terá um padrão de decisão — e não apenas mais uma chave com alcance difícil de explicar.