MCP seguro: quando conectar uma IA a ferramentas transforma contexto em privilégio
O Model Context Protocol (MCP) facilita a integração entre modelos de inteligência artificial, dados e ferramentas. Em vez de criar uma conexão diferente para cada aplicação, empresas podem usar uma forma padronizada para que agentes encontrem recursos e solicitem operações. A conveniência, porém, vem acompanhada de uma mudança importante: uma IA que antes apenas produzia texto pode passar a consultar documentos, abrir chamados, enviar mensagens ou executar ações em sistemas reais.
Nesse cenário, o contexto recebido pelo modelo pode influenciar decisões com efeitos concretos. Uma instrução maliciosa escondida em um arquivo, por exemplo, não fica necessariamente restrita à conversa: pode levar um agente a acionar uma ferramenta. A integração, portanto, exige mais do que uma conexão funcional. Exige regras claras sobre identidade, permissões e autorização.
Um protocolo comum não define confiança
O MCP padroniza a comunicação entre clientes e servidores, mas não determina, por si só, quais partes são confiáveis nem o que cada uma pode fazer. A segurança depende de uma cadeia que envolve o cliente MCP, o servidor, a identidade de quem faz a solicitação, as permissões concedidas, a ferramenta acionada e o sistema que recebe a operação.
Cada componente precisa cumprir sua responsabilidade. O cliente deve controlar a quais servidores se conecta. O servidor precisa identificar quem está chamando e verificar se a solicitação está dentro do escopo permitido. Já o sistema de destino deve validar a operação antes de executá-la, mesmo quando a requisição parte de um agente legítimo.
Tratar a presença de um protocolo padronizado como garantia de segurança é um erro. A padronização reduz o esforço de integração; não substitui controles de acesso, gestão de identidade, validação de dados ou governança.
Nem todas as ferramentas devem ter o mesmo poder
Uma integração que permite consultar documentação não oferece o mesmo risco de outra capaz de apagar recursos em nuvem. Da mesma forma, visualizar uma agenda é diferente de enviar uma mensagem para todos os contatos, e abrir um chamado não equivale a executar comandos em produção.
Por isso, as ferramentas devem ser separadas conforme o tipo e o impacto das ações que podem realizar. Operações de leitura podem ter permissões mais amplas do que alterações. Ações administrativas ou destrutivas precisam de restrições adicionais e, em situações de maior risco, de confirmação humana.
Também é importante limitar cada ferramenta ao mínimo necessário. Um agente encarregado de consultar o status de um serviço não deve receber, por conveniência, permissão para modificá-lo. Reduzir o escopo diminui o dano possível caso o modelo seja induzido a agir de forma inadequada ou uma credencial seja comprometida.
Prompt injection pode sair da conversa e virar ação
A prompt injection ocorre quando um conteúdo externo tenta manipular o comportamento do modelo. Esse conteúdo pode estar em uma página, um documento ou outro material consultado pelo agente. Quando a IA também tem acesso a ferramentas, a tentativa de influência pode resultar em uma operação concreta.
Imagine um agente autorizado a ler arquivos e enviar e-mails. Um documento malicioso poderia instruí-lo a encaminhar informações para um endereço externo. Se a decisão de permitir ou não o envio ficar somente a cargo do próprio modelo, a separação entre conteúdo não confiável e execução será frágil.
A autorização não deve depender do raciocínio do agente. O modelo pode solicitar uma operação, mas o servidor e os sistemas envolvidos precisam verificar se ela é permitida. Políticas independentes, limites de escopo e aprovações para ações sensíveis ajudam a impedir que uma instrução inserida em um documento se transforme automaticamente em privilégio.
O próprio servidor MCP precisa ser avaliado
O risco não está apenas no modelo ou nos dados que ele consulta. Um servidor MCP pode conter vulnerabilidades, ser comprometido ou apresentar ferramentas de forma enganosa. Descrições imprecisas podem levar o agente a interpretar incorretamente o efeito de uma operação, enquanto respostas do servidor podem tentar influenciar decisões posteriores.
Por isso, organizações devem manter um catálogo de servidores aprovados e revisar quais ferramentas cada um expõe. A capacidade técnica de se conectar a um servidor não deve ser confundida com autorização para usá-lo. A inclusão de uma nova integração precisa passar por avaliação, especialmente quando ela acessa informações confidenciais ou executa ações externas.
As descrições das ferramentas também merecem atenção. Como o modelo pode usá-las para decidir quando chamar uma ferramenta, esses metadados fazem parte da superfície de confiança. Em ambientes controlados, convém revisá-los, registrar alterações e evitar descrições ambíguas ou que ocultem consequências relevantes.
Identidade e credenciais exigem gestão cuidadosa
Credenciais estáticas compartilhadas costumam acelerar a criação de protótipos, mas podem se tornar difíceis de administrar. Quando vários agentes ou usuários dependem da mesma chave, fica mais complicado identificar quem realizou uma operação, limitar permissões ou revogar apenas uma integração sem interromper as demais.
Em ambientes corporativos, a conexão deve se alinhar às práticas de identidade e autorização já adotadas, incluindo mecanismos apropriados de autenticação, escopos restritos e tokens com duração limitada. Cada agente ou integração deve ter uma identidade identificável, com permissões compatíveis com sua função.
A revogação também precisa fazer parte do planejamento. Se um servidor deixar de ser confiável ou uma credencial for exposta, a organização deve conseguir interromper o acesso de forma rápida e direcionada, sem depender de uma chave compartilhada por todo o ambiente.
Controles para uma implantação mais segura
Antes de disponibilizar uma ferramenta, é essencial definir quais dados ela pode acessar, que operações pode executar e quem está autorizado a solicitá-las. Também é recomendável registrar chamadas, resultados e decisões de autorização. Esses registros ajudam a investigar incidentes e a identificar usos fora do padrão.
Para operações de maior impacto, a validação pode incluir limites de quantidade, confirmação explícita ou aprovação de uma pessoa. O controle deve ocorrer antes da execução, e não apenas depois, quando a ação já pode ter alterado dados ou enviado informações a terceiros.
Testes regulares devem considerar tanto falhas técnicas quanto tentativas de manipulação por conteúdo externo. A equipe pode verificar, por exemplo, se uma instrução maliciosa em um documento consegue induzir o agente a enviar dados, modificar registros ou ampliar o acesso. O objetivo é confirmar que as políticas continuam funcionando mesmo quando o modelo recebe informações adversariais.
Por fim, o acesso a ferramentas deve ser acompanhado ao longo do tempo. Integrações sem uso, permissões excessivas e servidores que deixaram de atender às necessidades da organização aumentam a superfície de ataque sem oferecer benefício. Revisões periódicas permitem remover acessos desnecessários e ajustar as regras conforme as ferramentas e os processos mudam.
O MCP torna mais simples conectar IA a sistemas e dados, mas essa simplicidade não elimina a necessidade de decidir em quem confiar. Uma implantação segura combina servidores aprovados, identidades verificáveis, permissões mínimas e autorização independente do modelo. Assim, o contexto pode orientar o agente sem se transformar, por conta própria, em acesso privilegiado.