Governança MCP: O que Realmente Significa em Produção (E as Quatro Barreiras que Precisamos Construir)

TL;DR: A governança MCP é o conjunto de controles que determina quais agentes podem acessar quais ferramentas, sob quais identidades, com quais limites e com qual trilha de auditoria. O MCP bruto não possui nada disso - é um protocolo para chamadas de ferramentas estruturadas, não um mecanismo de políticas. A camada de governança é algo que as equipes precisam construir deliberadamente, e a maioria não começa até que algo quebre. Este post é a coisa que eu gostaria de ter lido antes do nosso primeiro incidente.

Quando implantamos os servidores MCP em produção pela primeira vez, nossa história de governança era: não faça nada obviamente estúpido. Sem controles de acesso além de "você tem a URL do servidor ou não." Sem trilha de auditoria além dos logs gerados pela API downstream. Sem limites sobre quais ferramentas qualquer agente poderia chamar.

Essa história durou cerca de quatro meses, até que três coisas aconteceram em rápida sucessão:

Um agente de suporte que tinha acesso a um servidor Jira MCP acabou sendo testado com uma configuração habilitada para escrita. Ele criou 47 tickets duplicados antes que alguém notasse.

Um contratado terminou um engajamento e revogamos seu acesso ao GitHub e Slack. Três semanas depois, seu token Jira MCP ainda estava ativo porque não estava na lista de desligamento - as credenciais MCP não faziam parte do nosso processo padrão.

Um agente de pesquisa puxando conteúdo de concorrentes via uma ferramenta MCP de busca na web recuperou uma página contendo instruções injetadas que o agente executou. Nada catastrófico, mas o raio de explosão poderia ter sido significativo com um agente configurado de forma diferente.

Todos esses três são falhas de governança. Nenhum deles exigiu ataques sofisticados. Eles apenas exigiram a ausência de controles que deveriam existir.

O que a governança MCP realmente é

A governança MCP é a camada de controles sobre o protocolo MCP que determina:

• Quem pode se conectar a quais servidores MCP (identidade + controle de acesso)
• O que eles podem fazer uma vez conectados (RBAC em nível de ferramenta)
• Sobre quais limites (limites de taxa, orçamentos de token, limites de etapas de fluxo de trabalho)
• Com que registro (trilha de auditoria por invocação)
• Com que aplicação de políticas sobre o conteúdo (guardiões de entrada e saída)

O protocolo MCP em si não fornece nada disso. Ele define como os agentes chamam as ferramentas e como as ferramentas retornam resultados. A governança é uma infraestrutura que você constrói em cima disso ou não, e aprende por que deveria ter feito.

As quatro paredes

Após nossos três incidentes, mapeamos o problema de governança em quatro áreas de controle distintas. Cada uma tem diferentes modos de falha e diferentes mitigações.

Parede 1: Controle de acesso

O modo de falha: Qualquer agente com uma URL de servidor pode chamar qualquer ferramenta. Sem escopo de acesso, sem requisito de identidade, sem restrições por equipe.

O que precisávamos: RBAC em nível de ferramenta. Não apenas "a equipe A pode se conectar ao servidor Jira", mas "a equipe A pode chamar search_issues e create_issue, mas não delete_issue, delete_project ou bulk_update."

O segundo requisito é o que a maioria das configurações iniciais do MCP perde. Controlar o acesso ao servidor no nível da conexão não ajuda se o servidor expuser tanto ferramentas de leitura quanto de escrita e você quiser que diferentes agentes tenham diferentes capacidades.

Como implementamos: Todo o acesso ao MCP passa por um gateway central. As políticas de RBAC são definidas por servidor, por ferramenta, por função. Os agentes recebem listas de ferramentas filtradas - tools/list retorna apenas o que eles estão autorizados a chamar. Eles nunca veem ferramentas que não podem usar, o que remove completamente a área de superfície para má configuração.

Usamos o Gateway MCP da TrueFoundry para isso. A configuração do RBAC levou cerca de um dia por servidor para ser configurada corretamente. Também usamos Servidores MCP Virtuais - endpoints lógicos curados que expõem apenas o subconjunto de ferramentas que uma determinada persona de equipe precisa, de modo que um agente de pesquisa e um agente de suporte ao cliente vejam superfícies de ferramentas completamente diferentes, mesmo que ambos estejam autorizados para os mesmos servidores subjacentes.

Parede 2: Governança de identidade e credenciais

O modo de falha: As credenciais são gerenciadas individualmente por desenvolvedor por servidor. Quando alguém entra, configura as credenciais manualmente. Quando alguém sai, você espera que alguém as revogue em todos os lugares.

O que precisávamos: Gerenciamento centralizado de credenciais com desligamento que se propaga.

O problema das credenciais do contratado do nosso incidente é quase universal. Os servidores MCP são tipicamente um sistema separado de tudo o mais em seu fluxo de trabalho de integração/desligamento. A menos que você os conecte deliberadamente, eles não estarão cobertos.

Como implementamos: Cada desenvolvedor e agente de serviço se autentica em um gateway central com um único token (PAT para humanos, VAT para agentes de serviço). O gateway gerencia todas as credenciais downstream - OAuth do GitHub, chaves da API do Jira, tokens do Confluence, contas de serviço da API interna e as atualiza automaticamente antes da expiração.

O desligamento se tornou uma ação: revogar o token do gateway. O acesso de cada servidor MCP downstream é cortado automaticamente porque as credenciais que o gateway gerencia estão sob o controle do gateway, não do indivíduo.

Para ferramentas que devem agir em nome de um usuário específico (postar no Slack como uma pessoa, não como um bot), usamos OAuth 2.0 com nossa integração Okta. O gateway gerencia a troca e atualização de tokens - os agentes não gerenciam fluxos OAuth diretamente.

Parede 3: Trilha de auditoria

O modo de falha: Chamadas de ferramentas geram logs em dois lugares - os logs do servidor MCP e os logs da API downstream - e nenhum deles informa qual agente ou usuário acionou a chamada.

O que precisávamos: Uma trilha de auditoria estruturada por invocação de ferramenta que registra: qual agente, qual usuário autenticado, qual ferramenta, quais parâmetros de entrada, qual foi a resposta, a que horas.

Isso é o que a equipe de conformidade realmente pede. "A ferramenta X foi chamada 400 vezes no mês passado" não é útil. "O agente Y, sob a conta de serviço Z, chamou delete_record na tabela T às 14:23:07 com esses parâmetros" é o que torna uma investigação de incidente recuperável.

Como implementamos: O gateway registra cada chamada de ferramenta com metadados estruturados antes de encaminhá-la para o servidor downstream. Os logs são exportados via OpenTelemetry para nossa configuração do Datadog. Consultável. Quando nossa equipe de segurança perguntou "quais agentes acessaram a API de dados de produção nos últimos 30 dias", passou de uma investigação de dois dias para uma consulta de dez minutos.

Parede 4: Guardrails de conteúdo

O modo de falha: Um agente recupera conteúdo de um sistema externo via uma ferramenta MCP. Esse conteúdo contém instruções injetadas. O agente processa e executa as instruções injetadas. Isso é injeção de prompt via resposta da ferramenta e é o que nos pegou com o agente de busca na web.

O que precisávamos: Inspeção pós-chamada de ferramenta do que a ferramenta retorna antes de entrar no contexto do agente.

Isso é diferente dos guardrails de entrada em chamadas LLM (que inspecionam o que o usuário ou aplicativo envia ao modelo). Os guardrails de resposta da ferramenta inspecionam o que o servidor MCP envia de volta antes que o agente o veja. A injeção ocorre na saída da ferramenta, então a defesa deve estar nesse nível.

Como implementamos: Guardrails pós-execução em nível de gateway que inspecionam as respostas da ferramenta MCP antes de retorná-las ao agente chamador. Executamos detecção de PII e correspondência de padrões de injeção de prompt nas respostas da ferramenta. Para ferramentas de alto risco (busca na web, recuperação de documentos, respostas de API externas), também aplicamos sanitização de conteúdo.