MCP conecta o Agente às ferramentas, mas não resolve segurança e governança

Um Agente IA se torna mais útil quando deixa de apenas responder perguntas e passa a interagir com os sistemas da empresa. Ele pode consultar um CRM, verificar horários disponíveis, buscar informações em um banco de dados, atualizar um pedido, preparar uma proposta ou iniciar um processo de pagamento.

Essa capacidade de usar ferramentas para resolver problemas reais também aumenta a complexidade da operação.

Cada sistema possui APIs, métodos de autenticação, formatos de dados e regras próprias. Sem alguma padronização, conectar um Agente a dez sistemas diferentes pode exigir dez integrações construídas e mantidas separadamente.

O Model Context Protocol, conhecido como MCP, surgiu para reduzir essa fragmentação. Ele estabelece uma forma comum pela qual aplicações de IA podem descobrir e utilizar ferramentas, fontes de dados e fluxos externos.

A documentação apresenta o protocolo como uma espécie de USB-C para aplicações de IA: uma interface padronizada para conectar diferentes sistemas.

A comparação explica bem o potencial do MCP, mas pode gerar uma interpretação perigosa.

Um conector padronizado não garante que o dispositivo conectado seja confiável. Da mesma forma, o MCP facilita a conexão entre um Agente e uma ferramenta, mas não garante que essa ferramenta seja segura, que suas permissões estejam corretas ou que o Agente deva utilizá-la em qualquer situação.

O MCP padroniza a comunicação. Segurança e governança continuam sendo responsabilidades da empresa.

O que o MCP realmente faz

O MCP utiliza uma arquitetura cliente-servidor. De um lado está a aplicação de IA que hospeda o Agente. Do outro estão os servidores MCP que disponibilizam recursos e funcionalidades.

Segundo a documentação de arquitetura do MCP, esses servidores podem oferecer três elementos principais:

* Ferramentas: funções executáveis, como consultar um pedido, criar um evento ou atualizar um cadastro.

* Recursos: fontes de dados, como arquivos, registros de bancos de dados e respostas de APIs.

* Prompts: modelos reutilizáveis para estruturar instruções e interações.

A aplicação pode consultar as ferramentas disponíveis, entender os parâmetros exigidos e executar uma delas utilizando uma estrutura padronizada. Cada integração deixa de exigir um formato completamente diferente para descoberta e execução.

Em uma operação comercial, diferentes servidores MCP poderiam disponibilizar ferramentas como:

* `consultar_cliente`;

* `verificar_estoque`;

* `calcular_proposta`;

* `agendar_reuniao`;

* `atualizar_crm`;

* `enviar_link_pagamento`.

Durante a conversa, o Agente identifica uma necessidade, seleciona a ferramenta adequada, envia os parâmetros e utiliza o resultado para continuar o atendimento.

Essa estrutura reduz parte da complexidade técnica e favorece a reutilização. Uma ferramenta construída para consultar determinado sistema pode ser utilizada por diferentes aplicações compatíveis com o protocolo.

O MCP, porém, concentra-se no intercâmbio de contexto e na comunicação entre clientes e servidores. Ele não determina como a aplicação deve administrar o contexto recebido nem como o modelo deve decidir quando uma ferramenta será usada.

O protocolo define como a conexão acontece. Não decide se aquela conexão deveria existir.

Conectar não significa confiar

Quando uma empresa conecta um sistema ao seu ambiente, normalmente precisa avaliar quem desenvolveu a integração, quais dados ela acessa, onde é executada, quais credenciais utiliza e quais ações pode realizar.

O mesmo princípio deve ser aplicado aos servidores MCP.

Um servidor pode declarar que oferece uma ferramenta para consultar documentos, atualizar clientes ou executar comandos. O protocolo permite que a aplicação descubra essa ferramenta e entenda como chamá-la. Isso não comprova que a implementação seja legítima, segura ou adequada para o ambiente da empresa.

Um servidor malicioso ou comprometido pode tentar obter credenciais, acessar informações indevidas, enviar dados para terceiros ou executar ações diferentes daquelas que aparenta realizar.

As boas práticas de segurança do MCP descrevem riscos relacionados ao repasse indevido de tokens, acesso à rede interna, sequestro de sessões, execução de servidores locais e concessão de permissões excessivas.

Servidores locais merecem atenção especial. Eles podem ser executados com os mesmos privilégios da aplicação que os iniciou e, sem isolamento, acessar arquivos, rede e outros recursos do dispositivo.

Instalar um servidor MCP não deve ser tratado como adicionar uma extensão comum ao navegador. Dependendo das permissões concedidas, ele pode se tornar uma porta de entrada para sistemas internos, credenciais e dados empresariais.

Os principais riscos de uma implementação sem governança

1. Credenciais utilizadas fora do contexto correto

Uma integração pode utilizar tokens, chaves de API ou credenciais corporativas para acessar sistemas externos.

O problema surge quando esses tokens são encaminhados para outros serviços sem que o servidor valide para quem foram emitidos, quais permissões possuem e qual recurso deveriam acessar.

A documentação de segurança classifica esse comportamento como token passthrough. Nesse modelo, o servidor MCP aceita um token recebido do cliente e o encaminha para uma API posterior sem validar corretamente sua finalidade.

Essa prática reduz a rastreabilidade, enfraquece controles de segurança e pode permitir que um token roubado seja utilizado em serviços para os quais não deveria conceder acesso.

A especificação de autorização do MCP exige que o recurso de destino seja identificado durante a solicitação do token. A intenção é evitar que a mesma credencial circule indiscriminadamente entre diferentes serviços.

As credenciais de um Agente precisam ter finalidade, validade e escopo definidos. Elas também devem permanecer fora dos prompts, dos históricos de conversa e dos logs acessíveis a usuários sem autorização.

2. Permissões excessivas

Um Agente que precisa consultar o status de um pedido não deveria receber permissão para cancelar pedidos, alterar preços ou exportar toda a base de clientes.

Essa separação desaparece quando a empresa utiliza uma credencial administrativa para simplificar a integração. O resultado é um Agente com muito mais poder do que sua tarefa exige.

Tokens com escopos amplos aumentam o impacto de vazamentos, dificultam a revogação e tornam a auditoria menos clara. Uma única credencial pode acabar permitindo acesso a ferramentas e dados sem relação com a solicitação original.

As permissões precisam acompanhar a finalidade da ferramenta, e não a capacidade completa do sistema conectado.

Essa estrutura depende de identidade própria e permissões específicas para cada Agente. A organização precisa saber qual Agente realizou a ação, em nome de qual usuário e com qual nível de autorização.

3. Acesso à rede interna

Uma integração aparentemente simples pode ser induzida a fazer requisições para endereços que não deveriam estar acessíveis.

A documentação do MCP descreve ataques de Server-Side Request Forgery, ou SSRF, nos quais URLs controladas por um servidor malicioso direcionam o cliente para recursos internos.

Entre os possíveis destinos estão:

* painéis administrativos;

* bancos de dados locais;

* serviços como Redis;

* aplicações acessíveis apenas na rede corporativa;

* endpoints de metadados de provedores de nuvem.

Esses endpoints podem revelar credenciais de infraestrutura, chaves de API, informações sobre servidores e detalhes da rede.

Por isso, clientes MCP precisam aplicar restrições de saída, validar redirecionamentos, bloquear faixas de IP privadas quando apropriado e impedir que servidores externos utilizem o cliente como ponte para a rede interna.

A conexão com um servidor externo não deveria conceder acesso indireto a tudo que o cliente consegue alcançar.

4. Execução de comandos com os privilégios do usuário

Servidores MCP locais podem ser instalados e executados no computador do usuário.

Sem isolamento, um servidor malicioso pode tentar ler arquivos, enviar informações pela internet, modificar dados ou executar comandos no sistema operacional. O risco aumenta quando a instalação ocorre por meio de comandos copiados de repositórios ou páginas desconhecidas.

A documentação recomenda que o usuário veja o comando completo antes de autorizar sua execução. Também orienta que servidores locais sejam executados com acesso restrito ao sistema de arquivos, à rede e aos demais recursos do dispositivo.

Dentro de uma empresa, isso significa que servidores MCP não deveriam ser instalados livremente por qualquer colaborador.

A organização precisa definir:

* uma lista de servidores aprovados;

* responsáveis por revisar cada integração;

* versões autorizadas;

* ambientes permitidos;

* processos de atualização;

* mecanismos de revogação.

Ferramentas sensíveis podem ser executadas em containers, redes segmentadas ou ambientes isolados. O acesso à internet, ao sistema de arquivos e à rede interna deve ser liberado apenas quando necessário.

5. Manipulação do Agente por dados externos

Uma ferramenta não entrega apenas dados ao Agente. Ela também pode retornar textos que serão adicionados ao contexto utilizado pelo modelo.

Isso cria espaço para ataques de prompt injection. Um documento, e-mail, site ou resultado de API pode conter instruções maliciosas tentando convencer o Agente a ignorar regras, acionar outra ferramenta ou revelar informações.

O conteúdo retornado por uma ferramenta deve ser tratado como dado externo potencialmente não confiável. Ele não pode adquirir o mesmo nível de autoridade das regras internas do Agente apenas porque chegou por meio de uma integração.

Esse risco é uma extensão do prompt injection no atendimento. A diferença é que a instrução maliciosa pode estar escondida em documentos, respostas de APIs ou dados recuperados automaticamente, sem ter sido escrita diretamente pelo cliente na conversa.

Limites técnicos precisam impedir que um texto externo amplie permissões, libere novas ferramentas ou autorize ações críticas.

O roadmap de 2026 mostra que o MCP ainda está amadurecendo para empresas

O roadmap de 2026 do MCP apresenta quatro áreas prioritárias:

1. evolução e escalabilidade dos transportes;

2. comunicação entre Agentes;

3. amadurecimento da governança;

4. preparação para ambientes empresariais.

A parte de preparação para empresas reconhece que organizações estão adotando MCP e encontrando problemas relacionados a trilhas de auditoria, autenticação integrada aos sistemas corporativos, funcionamento por meio de gateways e portabilidade de configurações entre clientes.

O próprio roadmap descreve essa área como a menos definida entre as quatro prioridades. Parte do trabalho ainda deverá ser desenvolvida com a participação das organizações que estão enfrentando esses desafios em produção.

Segurança e autorização também permanecem como áreas em evolução. O projeto cita a necessidade de permissões mais específicas, proteção dos fluxos de autorização, gerenciamento seguro de credenciais e aprofundamento dos mecanismos de segurança.

Isso não reduz a importância do MCP. Mostra que o protocolo está avançando de experimentos locais para cenários reais de produção.

Um padrão pode facilitar a interoperabilidade antes de oferecer respostas completas para todos os problemas de governança empresarial.

Segurança de Agentes exige adaptações

Em maio de 2026, o NIST publicou uma análise sobre considerações de segurança para Agentes IA.

Segundo o relatório, os participantes consultados concordaram amplamente que sistemas de Agentes apresentam novas ameaças e que as preocupações com segurança continuam sendo uma barreira para a adoção.

Também houve concordância de que princípios tradicionais de cibersegurança continuam relevantes, mas precisam ser adaptados para lidar com as características desses sistemas.

Essa adaptação é necessária porque um Agente combina diferentes capacidades:

* interpreta instruções em linguagem natural;

* consome informações externas;

* seleciona ferramentas;

* executa processos em várias etapas;

* mantém contexto entre ações;

* interage com diferentes sistemas.

Em um software convencional, o desenvolvedor normalmente define antecipadamente qual função será executada em cada etapa. Em um Agente, parte dessa decisão pode ser tomada dinamicamente pelo modelo.

A segurança não pode depender da expectativa de que o modelo sempre escolherá a ação correta. A arquitetura precisa limitar tecnicamente quais ações estão disponíveis e quais consequências cada uma pode produzir.

Outro documento do NIST sobre identidade e autorização de Agentes reforça que conceder acesso a diferentes dados, ferramentas e aplicações exige controles apropriados de identificação e autorização.

Como uma empresa deve governar ferramentas conectadas por MCP

Antes de disponibilizar uma ferramenta para um Agente, a empresa precisa responder a algumas perguntas.

Quem desenvolveu e mantém essa ferramenta?

Servidores MCP precisam ter origem conhecida.

A empresa deve avaliar o responsável pelo projeto, o repositório, as dependências utilizadas, o histórico de atualizações e o processo de correção de vulnerabilidades.

Uma ferramenta encontrada em um catálogo ou repositório público não deve ser considerada confiável apenas por estar disponível.

Qual identidade será utilizada?

O Agente não deveria herdar automaticamente a identidade de um administrador ou colaborador.

Sempre que possível, precisa possuir uma identidade própria, com credenciais independentes e permissões vinculadas à sua função.

Quando o Agente age em nome de uma pessoa, os registros devem preservar tanto a identidade do Agente quanto a identidade do usuário que iniciou ou autorizou o processo.

Quais dados podem ser lidos?

O acesso deve ser limitado aos campos, registros, clientes ou documentos necessários.

Um Agente de atendimento não precisa consultar informações financeiras completas apenas para verificar o andamento de uma solicitação. Um Agente comercial conectado ao CRM pode precisar acessar contatos atribuídos ao seu canal, mas não exportar toda a base.

Quais ações podem ser executadas?

Ferramentas de consulta, alteração e exclusão precisam ser tratadas de maneiras diferentes.

Ler um horário disponível possui um risco menor do que cancelar uma agenda inteira. Consultar o preço de um produto não tem o mesmo impacto de alterar esse preço para todos os clientes.

A empresa pode estabelecer níveis de ação:

* ações somente de leitura;

* alterações reversíveis;

* ações que exigem confirmação do usuário;

* ações que exigem aprovação interna;

* operações críticas indisponíveis para o Agente.

Essa divisão se conecta à supervisão humana em Agentes IA. A aprovação humana deve ser aplicada de acordo com o impacto da ação, não como uma etapa genérica adicionada a tudo.

Onde a ferramenta será executada?

Ferramentas sensíveis podem ser executadas em ambientes isolados, containers ou redes segmentadas.

O acesso à internet, ao sistema de arquivos e à rede interna deve ser bloqueado por padrão e liberado apenas para os recursos necessários.

Um servidor que consulta um CRM remoto não precisa, por exemplo, acessar arquivos pessoais do colaborador nem serviços administrativos internos.

Como as ações serão registradas?

Cada chamada precisa deixar uma trilha de auditoria que responda:

* qual Agente solicitou a ação;

* qual usuário iniciou ou autorizou o processo;

* qual ferramenta foi utilizada;

* quais parâmetros foram enviados;

* qual sistema recebeu a solicitação;

* qual foi o resultado;

* quando a ação aconteceu.

Esses registros são necessários para segurança, depuração, conformidade e melhoria operacional.

Quando a ferramenta altera informações comerciais, também pode ser necessário registrar o resultado no CRM e no histórico da conversa, preservando o contexto que levou à decisão.

Como interromper o acesso?

A empresa precisa conseguir revogar credenciais, desativar uma ferramenta, bloquear um servidor e interromper uma execução sem reconstruir toda a integração.

Governança também significa possuir um mecanismo claro de contenção quando algo foge do esperado.

Esse mecanismo pode incluir:

* revogação imediata de tokens;

* desativação centralizada de ferramentas;

* bloqueio de versões vulneráveis;

* limites de quantidade por período;

* interrupção de processos em andamento;

* retorno temporário para operação humana.

Um exemplo prático: o Agente conectado ao CRM

Imagine um Agente comercial conectado ao CRM por meio de um servidor MCP.

Uma implementação apressada poderia utilizar uma credencial administrativa. Com ela, o Agente seria capaz de ler todos os contatos, alterar qualquer oportunidade, excluir registros e exportar informações.

Talvez o Agente utilizasse apenas uma pequena parte dessas capacidades durante o atendimento normal. Mesmo assim, todas permaneceriam disponíveis caso uma instrução fosse mal interpretada, uma ferramenta fosse comprometida ou um ataque de prompt injection tivesse sucesso.

Uma implementação governada seria diferente.

O Agente teria uma identidade própria. Poderia consultar apenas os leads atribuídos ao seu canal, atualizar campos específicos e registrar novos contatos. A exclusão de registros permaneceria bloqueada. Alterações de preço exigiriam aprovação humana.

Todas as operações seriam registradas. Também haveria limites de quantidade por período e um mecanismo para interromper o acesso.

O MCP utilizado nas duas implementações poderia ser exatamente o mesmo.

A diferença estaria na arquitetura de segurança construída ao redor dele.

O MCP é uma camada de conexão, não uma política de segurança

O MCP pode se tornar uma das principais formas de conectar Agentes IA a ferramentas, dados e aplicações empresariais.

Ele reduz o esforço necessário para criar integrações, favorece a reutilização e amplia o conjunto de capacidades disponíveis para os Agentes.

Nenhuma dessas vantagens elimina a necessidade de controle.

O protocolo não decide quais servidores são confiáveis. Não determina quais ferramentas uma empresa deve aprovar. Não conhece a sensibilidade dos dados acessados. Não define o impacto aceitável de uma ação. Também não substitui políticas de identidade, permissões, isolamento, auditoria e resposta a incidentes.

É assim que a Amplify enxerga a integração de Agentes IA com sistemas empresariais: a conexão precisa fazer parte de uma operação controlada, e não de uma coleção de ferramentas adicionadas sem critérios.

Padronizar a conexão facilita o acesso às ferramentas. A empresa ainda precisa decidir quais ferramentas podem ser usadas, por quem e dentro de quais limites.