A segurança e a governança de MCP definem quais servidores uma aplicação de IA pode usar, que informações e autoridade cada interação pode levar e como as operações de ferramentas são autorizadas e verificadas entre host, cliente, servidor e destino.
Essa definição operacional conecta escolhas de protocolo aos recursos empresariais por trás de uma ferramenta. O guia usa a revisão de 28 de julho de 2026 da especificação MCP. As implementações podem adotar outras revisões; verifique a versão e o comportamento dos componentes em análise antes de aplicar um requisito do protocolo. A segurança de agentes de IA fornece o modelo de ameaça mais amplo.
O que MCP muda
MCP oferece uma interface comum pela qual uma aplicação de IA pode obter contexto e usar capacidades expostas por servidores. Na arquitetura citada, o host gerencia clientes, consentimento e contexto; cada cliente interage com um servidor. Um servidor pode ser um processo local ou um serviço remoto. Essa revisão é stateless: as solicitações levam informações de protocolo e capacidades, e os servidores anunciam capacidades por server/discover. Um fluxo de negócio ainda pode manter estado fora dessas trocas de protocolo. Arquitetura MCP, 2026-07-28.
Considere uma tarefa hipotética: consultar um registro de inventário de equipamentos de um único local permitido. A aplicação seleciona asset_lookup, exposta por um servidor MCP remoto configurado. Esse servidor consulta uma API de inventário usando uma credencial que permite acessar vários locais. Essas condições compõem um exemplo hipotético para avaliar a arquitetura. Não descrevem uma integração real, um incidente ou um teste executado.
O local solicitado, a ferramenta selecionada, o servidor configurado e a credencial usada no destino descrevem relações diferentes. Uma credencial mais ampla não comprova que um registro sem autorização foi consultado. Ela exige, porém, uma explicação de onde a restrição ao local permitido é aplicada.
| Relação no exemplo | Questão a resolver | O que a resposta não comprova |
|---|---|---|
| Aplicação com o servidor configurado | Qual endpoint e qual operador estão aprovados para esta tarefa? | O que cada operação implementada ali fará |
| Ferramenta selecionada com o servidor | Qual servidor recebe esta solicitação de asset_lookup? | Que outra ferramenta com o mesmo nome seja equivalente |
| Cliente com o serviço MCP protegido | Qual identidade e quais condições de acesso admitem a solicitação? | Permissão para consultar todos os registros do inventário no destino |
| Servidor com a API de inventário | Qual credencial atua e onde o local permitido é verificado? | Que a consulta solicitada de fato ocorreu |
| Resposta da ferramenta com a aplicação | Qual fonte produziu o registro retornado e como ele será usado? | Autoridade para ampliar a tarefa ou consultar outro local |
A tabela orienta a revisão deste exemplo. O guia de arquitetura de governança de agentes explica os limites mais amplos entre componentes; este guia examina as relações MCP dentro deles.
Avalie a confiança no servidor antes de habilitar o acesso
Para o servidor remoto de inventário, identifique o operador, o endpoint, o uso permitido e o responsável por mudanças. Examine como ele obtém acesso ao destino e quem pode modificar sua implementação ou configuração. Uma conexão criptografada com o endpoint pretendido não comprova que o comportamento do serviço atende aos requisitos da organização.
Um servidor local introduz outro limite de execução. Examine o executável ou pacote iniciado, seus argumentos, origem, processo de atualização e acesso efetivo a arquivos, rede e credenciais. A orientação de segurança de MCP recomenda restringir privilégios de servidores locais e trata do consentimento antes de uma configuração com um clique executar comandos. A comunicação por STDIO, por si só, não cria isolamento de processo. Boas práticas de segurança de MCP, comprometimento de servidor local.
Atribua a revisão de mudanças a quem pode agir sobre o componente alterado. Trocar um endpoint exige avaliar o novo serviço; mudar um comando de inicialização local exige avaliar a nova execução. Um rótulo anteriormente aprovado não deve carregar essas aprovações adiante de forma silenciosa. O mecanismo para suspender ou aprovar novamente uma mudança depende dos controles reais do host e da implantação.
Diferencie a descoberta de uma ferramenta da permissão para usá-la
As ferramentas MCP descrevem nome, título de exibição opcional, descrição, schema de entrada, schema de saída opcional e anotações. Schemas descrevem a estrutura esperada; anotações oferecem indicações de comportamento. Clientes devem tratar anotações como não confiáveis, salvo quando o servidor for confiável. Nomes de ferramentas têm escopo de servidor, portanto podem colidir na agregação; serverInfo.name também não tem unicidade global garantida. Ferramentas MCP, 2026-07-28.
Para asset_lookup, a aplicação precisa de uma associação inequívoca com o servidor selecionado para a tarefa de inventário. Quem revisa uma permissão ou um evento deve conseguir resolver essa associação sem depender apenas do nome visível da ferramenta. A afirmação de que a ferramenta apenas lê registros ainda precisa de evidência sobre a implementação e as permissões do servidor real.
Mantenha a interface revisada vinculada à configuração instalada. Se a ferramenta ganhar um argumento que seleciona outra fonte de dados, a revisão anterior talvez já não explique para onde as informações podem ir. Uma mudança compatível com o schema também pode alterar o comportamento por trás da interface. Determine quais mudanças exigem nova avaliação e como o responsável fica sabendo delas; a descoberta fornece informação para esse processo, não seu resultado de aprovação.
Separe o acesso a MCP das permissões da ferramenta no destino
A especificação de autorização citada define um modelo opcional de autorização para HTTP. A recomendação para implementações HTTP que oferecem autorização é seguir esse modelo; para STDIO, é não usar esse fluxo e obter credenciais do ambiente. Não aplique o desenho OAuth de HTTP a toda conexão MCP. Autorização MCP, aplicabilidade.
No fluxo HTTP protegido, o servidor MCP deve validar que o token de acesso foi emitido para ele. Ao acessar uma API de destino como cliente OAuth, usa um token separado para esse serviço, em vez de repassar o token recebido do cliente MCP. Essas restrições mantêm distintos os destinatários dos tokens e as relações de acesso. Considerações de segurança da autorização MCP.
Essa separação ainda deixa uma decisão de negócio no exemplo de inventário. A operação no destino usa a identidade do solicitante, uma identidade delegada ou uma identidade de serviço? Se a credencial do serviço alcança vários locais, onde o servidor ou o destino verifica que esta solicitação pode consultar este registro? A restrição de local da tarefa precisa de um controle conectado à operação; o texto nas instruções do agente não reduz o alcance da credencial.
A especificação Tools de MCP exige validação de entradas e controles de acesso no servidor. A revisão da implantação precisa verificar sua aplicação aos recursos. Sintaxe válida para identificar um local não o torna autorizado; permissão para invocar asset_lookup não define quais registros ela pode retornar. Requisitos de Tools.
Acompanhe contexto e exposição de dados nas duas direções
Separe a informação enviada ao servidor daquilo que ele consulta e do que a aplicação consome depois. No exemplo, os argumentos enviados poderiam conter um identificador de local e uma referência de equipamento. O registro retornado poderia conter campos desnecessários para a tarefa. Examine os campos e destinatários reais, sem presumir que um prompt pequeno resulta em pouca divulgação de dados.
O responsável pela aplicação deve determinar de que contexto o servidor precisa para realizar a consulta. O responsável pelo inventário deve determinar quais registros e campos podem ser retornados para essa finalidade. O responsável pela aplicação receptora deve definir se a resposta pode entrar no contexto do modelo, ser retida ou compartilhada adiante. Essas decisões tratam de cópias e etapas de processamento distintas.
Um servidor remoto não herda as restrições de sistema de arquivos ou rede impostas ao processo local de um agente. Examine seu próprio ambiente de execução e as permissões no destino. Restringir o workspace local do agente não comprova que o serviço de inventário está limitado aos mesmos recursos.
Impeça que o conteúdo retornado se torne autoridade delegada
Uma resposta de inventário pode ser um dado legítimo da tarefa e ainda conter texto que a aplicação não deve tratar como instrução. A OWASP descreve prompt injection indireta como conteúdo externo que altera o comportamento do modelo e recomenda separar conteúdo não confiável e limitar privilégios. Essas medidas reduzem a exposição; não comprovam prevenção garantida. Orientação da OWASP sobre prompt injection.
Em uma variação hipotética, um registro inclui texto que incentiva o agente a consultar equipamentos de outro local. A presença desse texto não comprova que o agente o segue. Se ele influenciar uma nova consulta, porém, essa proposta exige autorização com base em seus próprios fatos. A chegada do conteúdo por um servidor aprovado não autoriza outro destino ou finalidade.
Preserve a origem e o papel do material retornado ao montar o contexto e avalie as propostas de ferramentas resultantes conforme o escopo permitido da tarefa. Um servidor pode estar aprovado para fornecer dados de inventário sem ter autorização para redefinir o fluxo de trabalho. A revisão de segurança deve examinar tanto a influência sobre o agente quanto a autoridade disponível caso ele a siga.
Avalie políticas sobre a operação resolvida
Uma decisão de política útil diz respeito ao servidor, à operação, ao alvo e à identidade executora reais. Para esta consulta, a decisão precisa de informação confiável suficiente para conectar a ferramenta selecionada ao serviço de inventário e o registro solicitado ao local permitido. Uma regra baseada apenas em asset_lookup não distingue o servidor pretendido de outra implementação com o mesmo nome.
Determine onde cada fato fica disponível. O host pode conhecer a tarefa do usuário e o endpoint configurado; o servidor pode resolver a referência do equipamento; a API de inventário pode manter a associação oficial do registro a um local. Posicione cada verificação onde ela possa usar contexto confiável e ainda restringir o acesso relevante. Não atribua a um componente informações que ele não recebe.
Se o host avaliar um alvo, mas o servidor resolver outro depois, examine como a restrição aplicável chega a essa etapa de resolução. O guia de governança pré-execução aprofunda essa correspondência entre uma proposta e o efeito que ela pode autorizar. Aqui, a questão específica de MCP é preservar o escopo através de uma fronteira de protocolo e da chamada do servidor ao destino.
Faça a aprovação identificar o acesso realmente solicitado
Uma aprovação deve permitir ao revisor identificar o servidor selecionado, a operação da ferramenta, o local solicitado e os dados envolvidos. Esse revisor também precisa ter autoridade sobre a exceção proposta. Um diálogo que apenas pergunta se asset_lookup pode ser usada talvez deixe sem resposta a decisão de acesso ao local.
Diferencie a permissão para configurar ou conectar um servidor da aprovação de uma consulta específica. Da mesma forma, o consentimento no cliente não concede uma permissão ausente na API de inventário. Se a tarefa mudar para outro local, resolva a autorização desse local com o responsável e o controle apropriados antes de prosseguir; não trate um clique anterior como permissão transferível.
A aplicação precisa de um estado de pendência definido enquanto a aprovação não for resolvida. Quando ela chegar, verifique se vale para o servidor, a operação e o escopo agora propostos. Uma mudança de endpoint ou alvo exige conferir essa relação novamente. São requisitos a estabelecer no fluxo de trabalho, não garantias fornecidas por MCP ou por um rótulo de aprovação.
Observe solicitações, respostas e atividade no destino separadamente
A observação deve esclarecer qual servidor configurado recebeu a chamada, qual operação foi solicitada e qual resposta ficou disponível para a aplicação. Quando houver evidência no destino, relacione-a à tentativa específica feita ali. Um evento da aplicação que mostra a seleção de uma ferramenta não comprova que a API de inventário recebeu uma solicitação.
A especificação Tools distingue erros de protocolo de erros reportados pela ferramenta, como falhas de API ou de negócio. Preserve esses significados ao interpretar a resposta. Um timeout no cliente deixa o resultado sem confirmação, salvo se outras evidências o estabelecerem; não prova que o servidor deixou de chamar o destino. Erros de Tools.
Para o fluxo de inventário, decida antecipadamente quem pode investigar uma consulta sem resultado confirmado e onde estão os registros necessários. A correlação pode conectar registros para revisão, mas uma janela de tempo coincidente, sozinha, não prova qual tentativa consultou um registro. Evite transformar uma resposta ausente em classificação automática de sucesso ou falha.
Construa um registro de auditoria que preserve cada identidade
Uma auditoria precisa distinguir a pessoa ou sistema que pede a consulta, o cliente admitido pelo serviço MCP e a identidade que atua na API de inventário. Preserve a relação entre eles quando estiver estabelecida e marque como desconhecidos os vínculos ausentes. Usar um único rótulo conveniente de ator para os três pode ocultar onde a autoridade mudou.
Mantenha as evidências de configuração e política pertinentes à operação: a associação ao servidor selecionado, o escopo do alvo, a decisão aplicável, a aprovação quando exigida e os registros disponíveis da tentativa e do resultado. O guia de trilha de auditoria de agentes de IA explica o modelo mais completo de evidências, incluindo os limites de timestamps, correlação, integridade e completude.
O próprio registro de inventário pode ser sensível. Prefira a evidência mínima que responde à pergunta da revisão, com referências controladas ao material protegido quando necessário. Não coloque tokens de acesso no registro de auditoria para demonstrar qual credencial foi usada. Registrar a identidade ou finalidade de uma credencial não exige reter seu valor secreto.
Verifique os controles em runtime na fronteira em que atuam
Antes de habilitar esse fluxo, determine onde uma consulta não permitida ainda pode ser impedida: no host antes da invocação, no servidor MCP antes da chamada ao inventário ou na API de inventário. Esses pontos podem aplicar controles com base em fatos diferentes. Uma decisão do host não comprova, por si só, que um serviço remoto restringiu o trabalho posterior, e interromper uma chamada futura não recolhe dados já retornados.
Defina o comportamento quando a configuração não puder ser resolvida, a avaliação falhar, a aprovação estiver pendente ou faltar a resposta do destino. Verifique essas condições na implementação usada pelo fluxo. Trata-se de uma proposta de validação de aceite para o desenho hipotético; nenhum resultado desses testes é afirmado aqui. A governança de IA em runtime explica como a validade e a aplicação da decisão dependem desses contratos.
Na implementação do adaptador de Claude Code examinada para este guia, a KonaSense associa nomes de ferramentas com prefixo MCP à configuração de servidor disponível para avaliação de políticas. A associação pode incluir uma URL ou um comando configurado; na ausência de configuração, pode restar apenas um nome extraído. Isso é contexto de configuração, não atestação do servidor ou prova de autorização no destino.
No caminho PreToolUse dessa implementação, decisões de política podem produzir respostas deny ou ask para o host. A falha de avaliação resulta em Allow. A resposta só afeta a execução se o host a aplicar; o código não comprova cobertura universal de MCP nem confirma o resultado no sistema de inventário. Avalie o Kona for Agents conforme o host, o caminho de evento, o servidor e a fronteira de aplicação de controle exigidos pelo fluxo.