O MCP conecta agentes a ferramentas. Não as governa. O watsonx Orchestrate mostra a camada que falta

O Model Context Protocol fez pelas ferramentas de agentes o que o USB fez pelos periféricos: um jeito padrão de plugar as coisas. Por isso a adoção foi rápida. E por isso a governança ficou para trás. Um conector padrão diz como uma ferramenta é chamada; não diz quais ferramentas podem ser chamadas, por quem, com que frequência, com quais entradas, nem o que acontece quando uma chamada parece errada.

A versão de fim de setembro do watsonx Orchestrate, da IBM, é um bom retrato do que essa camada que falta contém.

O que a IBM lançou

As notas de versão do time do watsonx Orchestrate, publicadas em 22 de setembro, incluem:

• Registro de MCP por tenant. Servidores MCP remotos podem ser registrados direto no namespace de um tenant a partir do catálogo, para que um time use uma ferramenta sem publicá-la no catálogo global.
• Controles personalizados nas ferramentas. Numa página unificada de Controles, administradores definem regras de validação, monitoram a contagem de execuções das ferramentas e aplicam salvaguardas de runtime. Os controles valem para ferramentas MCP, especificações OpenAPI e pacotes de plugins ZIP, junto com os controles nativos da IBM.
• Monitoramento por workspace. Os dashboards podem ser filtrados por workspace privado para ver desempenho, uso e métricas operacionais. A IBM informa que esse filtro é exclusivo do IBM Cloud.
• Suporte ao protocolo Agent-to-Agent (A2A) para conectar agentes externos, além de itens como transcrição de chamadas em tempo real para o Genesys Cloud Agent Assist.

Nada disso é dramático isoladamente. Junto, descreve os controles de que um time de plataforma precisa quando o MCP deixa de ser experimento de desenvolvedor.

A camada de governança de ferramentas, peça por peça

1. Servidor MCP registrado num tenant
2. Ferramenta liberada para agentes nomeados
3. Regras de validação de entrada e saída
4. Contagem e limite de execuções
5. Salvaguardas de runtime
6. Uso monitorado por workspace

• Quem pode usar: Servidor MCP registrado num tenant · Ferramenta liberada para agentes nomeados
• Como pode usar: Regras de validação de entrada e saída · Contagem e limite de execuções · Salvaguardas de runtime
• Evidência: Uso monitorado por workspace

EscopoPolítica em cada chamada

Escopo. Uma ferramenta registrada num tenant ou workspace não fica automaticamente disponível para todo agente. É a diferença entre uma loja interna de apps e uma pasta compartilhada.

Validação. Regras de entrada e saída pegam as falhas óbvias: uma ferramenta de pagamento chamada com valor acima do limite, uma consulta que devolve dados pessoais que o agente não deveria ver, um parâmetro fora da faixa permitida.

Limites. Contagem de execuções é controle de confiabilidade e de custo. Um agente preso num loop chamando a mesma ferramenta mil vezes deveria bater num teto, não numa fatura.

Salvaguardas de runtime. Política aplicada no momento da chamada, fora do raciocínio do agente, é o mesmo princípio que descrevemos na análise sobre contenção de agentes: a fronteira precisa ficar onde o agente não consegue discutir com ela.

Monitoramento. O uso por workspace é a evidência que o responsável precisa para responder “quais agentes usaram essa ferramenta, e quantas vezes?”

O que os controles da plataforma não cobrem

Uma camada de controle governa como seus agentes usam uma ferramenta. Não torna o servidor MCP confiável. Um servidor de terceiros pode mudar de comportamento, devolver conteúdo envenenado ou ter vulnerabilidades próprias. Trate cada servidor MCP externo como um fornecedor: quem mantém, como é atualizado, que dados recebe e o que dizem os termos. Fixar versões e revisar mudanças importa tanto quanto em qualquer outra dependência.

No Brasil, isso tem duas consequências práticas. Se o servidor MCP recebe dados pessoais, o fornecedor dele passa a ser operador no sentido da LGPD, com contrato e instruções de tratamento. E, para instituições supervisionadas pelo Banco Central, a Resolução CMN 4.893 já exige diligência sobre prestadores de serviços relevantes de processamento e armazenamento de dados; um servidor MCP que lê ou altera dados de clientes entra nessa conversa.

A identidade é a outra metade. Controles em ferramentas funcionam melhor quando cada chamada já carrega a identidade de um usuário ou de um agente, que é o tema da análise sobre por que o MCP enterprise começa pela identidade.

Num stack Microsoft

Os controles da IBM são da IBM; não existem dentro de produtos Microsoft. As perguntas, porém, são as mesmas. No Copilot Studio, servidores MCP entram por conectores, então as políticas de dados do Power Platform e os limites de ambiente são o lugar natural para decidir quais agentes usam quais ferramentas. No Foundry, esse papel é do gateway na frente das ferramentas. Qualquer que seja a plataforma, escreva os mesmos cinco controles: escopo, validação, limites, política de runtime e monitoramento.

O que fazer agora

1. Inventarie os servidores MCP em uso em todas as plataformas, inclusive os adicionados por desenvolvedores.
2. Registre ferramentas por time ou workspace, não globalmente, e mantenha uma lista de permitidas por agente.
3. Escreva regras de validação primeiro para ferramentas de alto impacto: pagamentos, alterações de cadastro, exportação de dados.
4. Defina limites de execução em toda ferramenta, com alerta antes do limite.
5. Trate servidores MCP de terceiros como fornecedores: responsável, versão fixada, revisão de mudanças, dados recebidos e contrato de operador quando houver dado pessoal.
6. Confira a disponibilidade de recursos por modelo de implantação (a IBM informa que parte do monitoramento é só no IBM Cloud) antes de desenhar em cima deles.

Em resumo

O MCP resolveu o encanamento. Agora as plataformas vão competir nas válvulas: escopo, validação, limites, política de runtime e evidência. Seja IBM, Microsoft ou outro stack, a camada de governança é sua de definir, e ela deveria estar pronta antes que o número de ferramentas conectadas torne isso doloroso.