Sobre este conteúdo
Este artigo é um guia operacional para colocar agentes baseados em MCP (Model Context Protocol) em produção sem perder controle. Pressupõe familiaridade com os vetores de ataque cobertos em MCP e Agentic AI Security. Aqui o foco é o que muda do piloto para o uso real e quais controles passam de "nice to have" para indispensáveis.
Neste artigo
O delta entre piloto e produção
Pilotos de agentes baseados em MCP escondem o problema operacional: um usuário, um ambiente isolado, baixa frequência de chamadas, alguém observando cada turn. Em produção essas quatro variáveis viram outras quatro: muitos usuários simultâneos, dados e identidades reais, frequência alta e ninguém olhando ao vivo. Classes de risco antes toleráveis — confused deputy, tool poisoning, excessive agency — viram incidentes potencialmente caros.
A diferença é exatamente a mesma do que separa um modelo ML em notebook de um modelo em online serving: observabilidade, controle de mudanças, capacidade de rollback, gestão de versões, e — crucial — a habilidade de parar tudo rápido quando algo dá errado. Os controles abaixo são o equivalente operacional para MCP.
Governance: quem aprova o quê
Antes de qualquer controle técnico, defina três artefatos por escrito:
Catálogo de MCP servers aprovados
Lista versionada de quais servidores externos seu agente pode falar. Cada entrada: URL canônica, hash do binário (se self-hosted), responsável interno, data de aprovação, escopo das tools expostas.
Política de ações permitidas
Para cada combinação (agente × tool × cenário), o que pode ser feito autonomamente, o que precisa human-in-the-loop e o que está vetado. Documente como código (YAML/JSON), não em wiki.
RACI de incidentes
Quem aciona o kill switch, quem reverte ações, quem comunica usuários afetados, quem decide retomar operação. Sem RACI, em incidente todos olham um para o outro enquanto o agente continua agindo.
O catálogo de MCP servers e a política de ações são versionados em Git, revisados por pares, e as mudanças geram trilha de auditoria. Servidores ou tools não listadas no catálogo são rejeitadas no gateway — não dependem de boa-fé do agente.
Allow-listing de MCP servers
O modelo de ameaça mais subestimado é tool poisoning: um atacante registra (ou compromete) um MCP server, expõe tools que parecem inocentes (get_user_preferences, format_output) mas que carregam comportamento malicioso — exfiltração, injeção de prompts indiretos, side effects em recursos externos. Sem allow-listing, qualquer prompt malicioso ou bug pode levar o agente a invocar essas tools.
Implemente em quatro camadas:
- Gateway de saída: o cliente do agente nunca fala direto com o MCP server externo. Sempre via proxy que valida o destino contra a allow-list (URL exata, hash de TLS pin, certificado esperado).
- Verificação de identidade do server: além de URL, exija assinatura ou mTLS. URL pode ser sequestrada; chave criptográfica do server, não.
- Mapeamento explícito de tools: nem todas as tools que um server expõe estão habilitadas. Mantenha por server uma lista de tools permitidas — se o server expor uma
delete_everything, ela continua bloqueada. - Pinning de versão: a allow-list referencia versão (semver ou commit hash) do server. Quando o server upgrada, o gateway bloqueia até alguém revisar o changelog e aprovar a nova versão.
Audit log imutável: o que registrar
O audit log é o seu único recurso quando algo dá errado. Sem ele, qualquer investigação esbarra em "não temos como saber". Registre, por chamada:
| Campo | Conteúdo | Por quê |
|---|---|---|
ts | Timestamp UTC ISO 8601 com ms | Correlação com outros logs |
session_id | UUID por sessão de agente | Reconstruir cadeia de turns |
principal | Identidade do humano que originou (Entra ID / Okta sub) | Accountability — quem pediu |
agent_id | Nome + versão do agente | Rastreio de regressões |
model | Provider + modelo + versão | Reproduzir comportamento |
prompt_hash | SHA-256 do prompt do usuário | Privacidade + auditoria |
mcp_server | URL canônica + versão | Mapear chamada à allow-list |
tool | Nome da tool invocada | Análise de uso |
tool_args | Argumentos finais enviados (com redação de PII) | Reproduzir ou refutar comportamento |
tool_result_hash | SHA-256 do resultado completo | Provar o que voltou sem armazenar tudo |
action_taken | Mudança de estado efetuada (criar, deletar, atualizar) + IDs dos recursos | Possibilita rollback e investigação |
approval | ID de aprovação humana (se HITL acionado) | Prova de governance |
chain_hash | SHA-256 (linha atual + chain_hash anterior) | Integridade do log |
Armazene em backend WORM (write-once-read-many) ou append-only com integridade verificável: AWS CloudWatch Logs com lock, Azure Immutable Blob Storage, GCP Bucket Lock, ou Object Lock S3 em compliance mode. O chain_hash em cadeia (cada linha referencia a anterior) detecta manipulação retroativa mesmo se o storage for comprometido.
Pegadinha de privacidade
Logue hashes de prompts e resultados, não o conteúdo bruto. Em incidente, você pode pedir consentimento específico para reconstruir, mas o log padrão não deve ter PII em texto claro — caso contrário você criou uma nova superfície de vazamento.
Kill switch operacional
Kill switch precisa funcionar em quatro camadas em paralelo, porque cada uma falha sozinha:
Endpoint /kill no orchestrator
Sessões em curso são interrompidas. Implementação simples: flag em Redis ou tabela, verificada a cada turn. Se flag setada para o agente, o orchestrator retorna erro controlado e não chama mais tools.
Revogação imediata de credenciais
Sessão morta no orchestrator não impede que execuções pendentes em tools terminem. Revogar tokens OAuth, rotacionar API keys e expirar service principals em paralelo ao kill é o que realmente interrompe o blast radius.
Circuit breaker no gateway
O gateway de MCP servers recusa novas chamadas para os destinos afetados (por server, por tool ou por agente). Independente do estado do orchestrator.
Feature flag global
Flag em config central (Redis pub/sub, Consul, AWS AppConfig, LaunchDarkly) que desativa o agente inteiro. Propagação em segundos. Esta é sua "estrela vermelha" — quando todo o resto falha, o agente para de iniciar sessões novas.
Teste o kill switch periodicamente em stage. Sem teste, ele falha justo quando você precisa — credenciais não revogam porque o secrets manager perdeu permissão, flag não propaga porque alguém mudou a chave, circuit breaker está em config errada. Faça GameDay trimestral de kill switch.
Human-in-the-loop nos pontos certos
HITL em tudo mata produtividade. HITL em nada mata o negócio. A linha está em impacto irreversível ou alto custo:
- Ação que muda estado externo persistente: criar fatura, aprovar pagamento, deletar recurso, abrir ticket externo, enviar comunicação a cliente.
- Custo de erro > custo de revisão: regra simples — se reverter custa muito mais do que aprovar custa, peça aprovação.
- Primeira execução de tool nova naquele contexto: mesmo se aprovada no catálogo, primeira invocação por aquele agente em produção justifica revisão.
- Ação fora dos guardrails da sessão: se o usuário definiu escopo (apenas relatórios de leitura), tentativas de sair desse escopo viram pedido de aprovação.
Implementação típica: o agente apresenta a ação proposta com argumentos finais, o humano vê (UI dedicada, e-mail com link, mensagem no Slack/Teams), aprova/rejeita/edita. A aprovação é o gatilho da execução. Logue a aprovação no audit junto com a ação — quem aprovou, quando, qual delta entre proposto e executado.
Rate limiting e quotas
Agentes têm padrão de uso bursty e podem entrar em loops degenerados (o modelo "convence a si mesmo" que precisa chamar a mesma tool dez vezes seguidas). Sem quotas, isso vira incidente de custo e de carga em sistemas downstream.
- Quota por sessão: N tools no total, M por tipo. Excedeu? Para a sessão e exige novo turn humano.
- Quota por usuário/dia: contém shadow usage e abuso de credencial.
- Quota por MCP server: protege o destino. Útil quando o server externo cobra por chamada.
- Loop detection: se a mesma tool é chamada com argumentos idênticos N vezes em janela curta, intercepte e exija HITL.
Métricas que importam
Acompanhe semanalmente:
| Métrica | Meta | Sinal de alerta |
|---|---|---|
| % ações irreversíveis com HITL | 100% | Qualquer queda — significa que alguma rota está bypass |
| Tempo médio kill switch → todas as execuções paradas | < 30s | Aumento sinaliza tokens não revogando |
| Cobertura de audit | 100% das chamadas a tools | Drop indica logger fora do ar ou caminho não instrumentado |
| MCP servers fora da allow-list bloqueados/semana | Próximo de zero (depois de estabilizado) | Alto = tentativas de shadow MCP, investigar |
| % prompts que disparam guardrail | Estável (depende do uso) | Alto demais: guardrails ruins; baixo demais: permissivos |
| MTTR de revisão de incidente | Tempo curto para reconstruir cadeia | Crescente = audit ou correlação degradados |
Perguntas frequentes
Por que MCP em produção é diferente de MCP em piloto?
Em piloto o impacto é contido (um usuário, ambiente isolado, baixa frequência). Em produção o agente atua sobre identidades e dados reais, em alta frequência e sem operador acompanhando. Confused deputy, tool poisoning e excessive agency saem do plano teórico e viram incidentes potencialmente caros.
O que deve estar no audit log?
Timestamp, identidade do principal humano, identidade do agente, modelo+versão, server MCP, tool chamada com argumentos, hash da resposta, ação executada (com IDs dos recursos), aprovação HITL quando aplicável. Em log imutável com integridade verificável (hash chain) e retenção alinhada à regulação.
Como implementar kill switch?
Quatro camadas em paralelo: endpoint /kill no orchestrator, revogação imediata de tokens OAuth/credenciais, circuit breaker no gateway, feature flag global. Teste em GameDay trimestral — sem teste, ele falha quando você precisa.
O que é allow-listing de MCP server?
Lista de servidores MCP aprovados pela organização, validada no gateway. Inclui URL canônica, identidade (mTLS/assinatura), tools permitidas por server e pinning de versão. Bloqueia tool poisoning e contém blast radius quando um server legítimo é comprometido.
Quando exigir human-in-the-loop?
Em pontos de impacto irreversível ou alto custo: criar/aprovar/deletar recurso externo, enviar comunicação a cliente, primeira execução de tool nova, ação fora dos guardrails da sessão. O humano aprova/edita, a aprovação é o gatilho da execução, e tudo é logado.
Como medir se a governance está funcionando?
% ações irreversíveis com HITL (meta 100%), tempo até kill switch propagar, cobertura de audit, bloqueios de MCP fora da allow-list, taxa de guardrail acionado, MTTR de revisão de incidente. Acompanhe semanal até estabilizar.
Referências
- Anthropic — Model Context Protocol specification — modelcontextprotocol.io
- OWASP Top 10 for LLM Applications (2025) — genai.owasp.org
- NIST AI Risk Management Framework — Generative AI Profile (NIST AI 600-1)
- MITRE ATLAS — Adversarial Threat Landscape for AI Systems — atlas.mitre.org
- EU AI Act — texto consolidado em eur-lex.europa.eu