Se o agente faz deploy, trate cada ferramenta MCP como uma API de produção

Tem uma diferença pequena na interface e enorme na operação: pedir a um agente que escreva uma migration gera um arquivo para revisão. Permitir que ele aplique a migration altera um banco de verdade.

O mesmo vale para criar uma configuração de deploy e acionar o deploy. Enquanto a resposta termina em um diff, ainda existe uma fronteira clara para a revisão. Quando uma chamada de ferramenta, ou tool call, muda estado real, o sistema já está lidando com uma operação de produção.

Essa mudança aparece em plataformas que começam a se apresentar como agent-ready. O anúncio do Catalyst 3.0, por exemplo, descreve ações estruturadas sobre tabelas, autenticação, armazenamento, eventos e deploy. Também menciona permissões limitadas por escopo, logs de chamadas MCP e mudanças reversíveis. Não é motivo para concluir que qualquer integração desse tipo seja segura por padrão. É um bom sinal de que a conversa saiu da geração de código e chegou à operação.

Nesse ponto, "não faça isso" no prompt é uma orientação útil, mas não é autorização. O freio precisa estar no host que expõe a ferramenta, na identidade usada para chamá-la e nas regras que validam cada operação.

Código sugerido e operação executada têm riscos diferentes

Um modelo pode ter capacidade para propor uma alteração sem receber permissão para executá-la. Misturar essas duas coisas costuma produzir credenciais amplas demais: o agente precisa consultar um status em staging e acaba herdando acesso de escrita em produção porque era a identidade disponível.

Eu gosto de separar a decisão em três partes:

o que o modelo consegue formular;
o que a identidade da sessão pode fazer;
qual é o impacto daquela operação naquele ambiente.

As duas primeiras podem ser iguais em tarefas bem diferentes. Ler o estado de um serviço e apagá-lo talvez usem o mesmo conector, mas não deveriam passar pela mesma política. O controle precisa chegar até a ação, o recurso e o ambiente.

Isso também explica por que um prompt bem escrito não resolve o problema. O prompt muda ao longo da conversa, pode incorporar conteúdo externo e não tem autoridade para revogar uma credencial. Uma política aplicada pelo host consegue negar a chamada antes que ela chegue ao serviço.

Dê a cada ferramenta um contrato de produção

Antes de liberar uma tool call, escreva o contrato como faria com uma API interna. O nome da ferramenta é só o começo. O host precisa saber quem chama, em qual ambiente, sobre qual recurso, com quais argumentos e dentro de quais limites.

Um pedido de deploy poderia chegar ao host assim:

{
  "tool": "deploy_service",
  "environment": "staging",
  "resource": "app:gerador-de-imagens",
  "version": "git:8f31c2a",
  "dry_run": true,
  "idempotency_key": "deploy-8f31c2a-staging"
}

O ponto não é esse formato específico. O ponto é que o host valida os campos em vez de confiar na intenção descrita pelo modelo. environment deve aceitar apenas os ambientes liberados para aquela identidade. resource precisa pertencer a uma allowlist, a lista explícita de alvos autorizados. Já dry_run pede uma simulação sem efetivar a mudança. Versão, timeout e tamanho dos argumentos também precisam de limites.

A chave de idempotência entra quando uma repetição pode causar efeito duplicado. Se o agente não recebe a resposta antes do timeout, ele pode tentar de novo. O serviço deve reconhecer que aquela segunda chamada representa a mesma operação, quando isso fizer sentido para o domínio. Idempotência não aparece por colocar um campo no JSON; o serviço precisa implementar o comportamento.

A aprovação deve acompanhar o impacto

Pedir confirmação humana em toda chamada parece prudente por alguns minutos. Depois vira uma fila manual com aparência de automação. Faz mais sentido classificar as operações e subir o nível de controle junto com o risco.

Nível	Exemplo	Controle padrão
Baixo	leitura escopada, sem dados sensíveis	identidade limitada, allowlist e timeout
Médio	escrita reversível em staging	preview ou `dry-run`, proteção contra repetição e log da mudança
Alto	exclusão, cobrança, mudança de acesso, migration destrutiva ou deploy em produção	aprovação explícita, identidade dedicada e plano de recuperação testado

Essa divisão não é universal. Atualizar uma flag pode ser banal em um projeto e interromper pagamentos em outro. O time precisa classificar o efeito no próprio domínio, não pelo verbo usado no nome da ferramenta.

Menor privilégio também tem custo. Políticas por recurso e ambiente precisam de manutenção e às vezes bloqueiam uma tarefa legítima. Ainda assim, é melhor descobrir uma permissão ausente em staging do que perceber, depois do incidente, que o agente carregava a mesma credencial de um administrador.

O log precisa ajudar alguém a recuperar o sistema

Guardar uma transcrição enorme da sessão raramente responde ao que importa durante um incidente. Para cada chamada, o registro operacional deveria permitir identificar:

a identidade ou sessão responsável;
a ferramenta, o ambiente e o recurso atingido;
o horário, o resultado e a referência da mudança;
um resumo dos argumentos, sem segredos nem dados pessoais desnecessários;
o estado anterior e posterior, ou um diff, quando houver uma forma segura de registrá-los.

Há um equilíbrio chato aqui. Pouco log deixa o time no escuro. Logar o payload inteiro pode guardar tokens, informações pessoais e grandes blocos de conteúdo por tempo demais. Uma saída prática é manter um recibo operacional compacto e deixar os rastros detalhados com acesso restrito e retenção curta.

O recibo também ajuda fora dos incidentes. Se ninguém consegue responder quem fez o deploy, qual versão entrou e qual política autorizou a chamada, a automação ainda não está pronta para receber mais autonomia.

Às vezes, a melhor ferramenta é a que não chega ao agente

Imagine um app pequeno que gera imagens. O agente pode provisionar o armazenamento e publicar a aplicação, mas isso não obriga todo o fluxo a passar pelo backend. O pós-processamento do arquivo pode continuar no dispositivo da pessoa.

Na preparação de formatos 1:1, 4:5 ou 9:16, uma ferramenta que executa o trabalho localmente no navegador, como o Resize Image for Instagram, faz o redimensionamento e a exportação sem enviar os pixels a uma API de processamento. Para esse pedaço do fluxo, saem de cena o upload, a credencial de backend e mais uma chamada privilegiada disponível ao agente.

Não existe almoço grátis. O navegador assume o trabalho, então imagens grandes esbarram na memória, no desempenho e na compatibilidade do dispositivo. Arquivos ainda precisam de validação. Mesmo assim, reduzir a superfície remota costuma ser mais simples do que adicionar uma ferramenta poderosa e tentar cercá-la depois.

Esse raciocínio vale além de imagens. Antes de expor uma nova capacidade ao agente, vale conferir se a tarefa pode permanecer no cliente, ser executada por um job sem credencial ampla ou virar apenas um artefato para revisão.

Rollback precisa sobreviver a uma falha parcial

Uma operação marcada como reversível ainda pode falhar no meio. A tabela foi criada, mas a configuração seguinte não entrou. A versão nova subiu, porém a atualização de rota expirou. O teste útil reproduz esse intervalo em staging e verifica o que o sistema faz a partir dali.

Para estado técnico, a recuperação talvez seja restaurar uma versão, reverter uma migration compatível ou reaplicar a configuração anterior. Efeitos externos pedem compensação. Um e-mail enviado não volta para a caixa de saída; uma cobrança pode exigir estorno; um dado exposto exige resposta de incidente. Chamar tudo isso de rollback esconde diferenças que aparecem justamente no pior momento.

Por isso o plano de recuperação precisa indicar quais passos voltam sozinhos, quais exigem uma ação compensatória e quem assume a recuperação quando a automação não consegue fechar o ciclo.

Um primeiro rollout que cabe em um time pequeno

Não é preciso redesenhar a plataforma inteira para testar esse modelo. Escolha uma única operação de escrita, reversível e fora de produção. Dê a ela uma identidade dedicada, restrinja recursos e argumentos e rode quatro cenários: entrada inválida, repetição, timeout e falha parcial.

No fim do teste, o time precisa conseguir responder com evidências:

quem iniciou a operação;
qual política permitiu a execução;
o que mudou;
como detectar uma execução incompleta;
qual procedimento recupera ou compensa o efeito.

Se alguma resposta depende de reler a conversa e interpretar o que o agente "quis dizer", ainda falta controle fora do prompt.

MCP facilita conectar o modelo a capacidades reais. A conexão, por si só, não define autorização, isolamento, aprovação ou recuperação. Agentes erram, integrações expiram e serviços respondem pela metade. Um fluxo de produção limita cada erro, deixa um recibo legível e oferece um caminho de volta que o time já exercitou.