A onda da IA agêntica está se acelerando rapidamente. O que começou como chatbots equipados com ferramentas simples agora está evoluindo para trabalhadores digitais autônomos que estão profundamente integrados aos fluxos de trabalho das empresas.
À medida que essas implementações amadurecem, uma lacuna crítica de segurança está se tornando cada vez mais evidente.
Muitas arquiteturas de agentes atuais ainda dependem do que pode ser descrito como um modelo God Key, em que credenciais amplas e de longa duração combinam a identidade do usuário, a autorização e o acesso à ferramenta em um único segredo compartilhado.
Essa abordagem não é dimensionada com segurança.
Para as empresas que pretendem operacionalizar agentes em escala, é necessário fazer a transição para a identidade delegada e mecanismos de aplicação com reconhecimento de IA.
Veja a seguir uma análise detalhada do problema real e o que implica uma solução de nível de produção.
1. O risco real: credenciais de agente com excesso de privilégios
Em muitas implantações iniciais de agentes, como ferramentas do tipo LangChain, servidores MCP personalizados e gateways de ferramentas internas, a autenticação geralmente é gerenciada usando credenciais de serviço estáticas:
- chaves de API de longa duração
- contas de serviços compartilhados
- Credenciais amplas do cliente OAuth
- ou identidades grosseiras de carga de trabalho
Para esclarecer, o MCP em si não exige chaves estáticas. O protocolo é compatível com o OAuth adequado e com modelos de identidade delegados. No entanto, nas implementações do mundo real, muitos agentes ainda usam credenciais com escopo excessivo e não vinculadas ao usuário para conversar com servidores MCP individuais.
Essa é a fonte do risco.
O problema da identidade compartilhada (atribuição entre usuários)
Considere um cenário em que:
- 50 funcionários usam um único agente de marketing
- o agente chama o GitHub usando uma credencial de serviço
Nessa configuração, os registros do GitHub mostrariam simplesmente: Agent_Service_Account excluiu o repo X.
O que está faltando:
- qual humano iniciou a ação
- se o usuário foi autorizado
- se a ação era esperada
Do ponto de vista da auditoria e da perícia, a atribuição é perdida. Isso não é uma falha do MCP, mas sim uma lacuna de propagação de identidade presente em muitas implementações de agentes.
O problema da permissão excessivamente ampla (escopo de ferramentas cruzadas)
Considere um servidor MCP que expõe várias ferramentas:
- read_file
- list_files
- delete_file
Se o agente se autenticar com uma única credencial de escopo amplo, qualquer injeção de prompt bem-sucedida ou comportamento incorreto do agente poderá invocar ferramentas de maior risco. Embora o MCP permita que os servidores apliquem a autorização por ferramenta, muitos serviços de MCP atualmente se concentram principalmente na funcionalidade da ferramenta e não foram projetados para servir como pontos de aplicação de políticas empresariais completas.
Isso cria uma lacuna arquitetônica significativa.
2. A realidade arquitetônica: Os servidores MCP não são gateways ZTNA
Na maioria das empresas, não se espera que os aplicativos internos implementem eles próprios uma lógica abrangente de autenticação, autorização e política de risco. Em vez disso, essa responsabilidade geralmente é centralizada em uma camada de Zero Trust Network Access (ZTNA) que fica na frente dos aplicativos corporativos.
Os serviços do MCP devem ser vistos da mesma forma.
Na prática, muitos servidores MCP:
- foco na execução da ferramenta
- confiar na identidade upstream
- implementar autenticação grosseira ou em nível de serviço
- falta de modelos profundos de política de usuário/grupo
- não realizar a troca de tokens
- não foram projetados para lidar com decisões de risco imediatas
Esperar que cada servidor MCP atue como um mecanismo completo de aplicação do Zero Trust não é realista nem escalável.
3. Por que a ZTNA é o ponto de controle natural
A ZTNA já desempenha um papel bem estabelecido na segurança empresarial:
- fronting de aplicativos internos
- centralização da autenticação
- Aplicação de políticas de acesso
- fornecer um único plano de controle
- reduzir a carga das equipes de aplicativos
A aplicação desse modelo aos serviços de MCP oferece às organizações uma abordagem unificada para proteger tanto os aplicativos tradicionais quanto o acesso a ferramentas orientadas por IA.
Uma maneira consistente de proteger tanto os aplicativos tradicionais quanto o acesso a ferramentas orientadas por IA.
No entanto, a IA introduz um novo requisito para as soluções ZTNA.
4. A ZTNA tradicional é cega para o comportamento da IA
As soluções tradicionais de ZTNA baseiam suas decisões em fatores como:
- identidade do usuário
- postura do dispositivo
- contexto de rede
- identidade do aplicativo
O tráfego de IA autêntica adiciona novas dimensões de risco, como:
- qual ferramenta MCP está sendo chamada
- quais argumentos estão sendo passados
- se a solicitação foi gerada por prompt
- se a ação representa um alto risco
- se o usuário está autorizado para essa ferramenta específica
As soluções tradicionais de ZTNA não podem ver ou aplicar controles nessa camada. Para fazer a frente dos serviços de MCP com segurança, o ZTNA deve ser sensível ao protocolo de MCP e à IA.
O que é necessário não é uma substituição da ZTNA, mas uma evolução dela.
ZTNA com reconhecimento de MCP: a evolução necessária
O ZTNA tradicional continua sendo a porta de entrada arquitetônica correta para aplicativos corporativos, incluindo serviços de MCP. A centralização do controle de acesso fora do aplicativo provou ser dimensionável, auditável e operacionalmente eficiente.
No entanto, os fluxos de trabalho orientados por agentes introduzem dois novos requisitos que a ZTNA clássica não foi projetada para atender:
identidade delegada em nível de usuário para a execução da ferramenta
visibilidade em nível de protocolo da atividade da ferramenta MCP
O atendimento a esses requisitos não substitui a ZTNA – ele a desenvolve.
Uma camada ZTNA com reconhecimento de MCP amplia o modelo Zero Trust tradicional em duas dimensões essenciais: delegação de identidade e autorização com reconhecimento de protocolo.
Identidade delegada: Por que a troca de tokens é necessária
Quando um agente de IA invoca uma ferramenta MCP, o serviço downstream deve ser capaz de responder a uma pergunta fundamental:
Essa ação está sendo executada em nome de qual pessoa?
Passar um token de usuário amplo e de longa duração diretamente para cada serviço MCP não é seguro nem dimensionável. Isso cria uma propagação excessiva de confiança e aumenta o raio de explosão se um token for mal utilizado.
Em vez disso, as arquiteturas Zero Trust modernas usam identidade delegada.
Nesse modelo:
- o usuário se autentica com o IdP da empresa
- o agente propaga a identidade do usuário
- A camada de aplicação do ZTNA valida o usuário
- A camada de aplicação realiza a troca de tokens
- uma credencial de curta duração e de escopo restrito é criada para o serviço específico de MCP
Essa abordagem garante que os serviços downstream recebam apenas a autoridade mínima necessária para a operação solicitada.
A troca de tokens delegados também permite que as empresas:
- Aplicar controles consistentes de tempo de vida
- normalizar os públicos
- reduzir o raio de explosão da ficha
- e manter a atribuição total do usuário
Mas a identidade por si só não é suficiente.
Por que a conscientização sobre o protocolo MCP é importante
Mesmo com a identidade perfeita, a ZTNA tradicional ainda não tem visibilidade do que o agente está realmente fazendo.
Do ponto de vista da rede, o tráfego MCP geralmente aparece como HTTPS padrão. Sem o reconhecimento do protocolo, a camada de aplicação não consegue ver:
- qual ferramenta MCP está sendo chamada
- quais argumentos estão sendo passados
- se a ação é de alto risco
- se o usuário está autorizado para essa ferramenta específica
Esse é o principal ponto cego.
Uma camada ZTNA com reconhecimento de MCP inclui análise profunda de protocolo que pode extrair:
- Nome da ferramenta
- argumentos da ferramenta
- contexto da sessão
- reclamações de usuários
Esses sinais permitem políticas de autorização refinadas e com reconhecimento de IA que vão muito além de simples decisões de acesso a aplicativos.
Somente depois que a delegação de identidade e a inspeção em nível de MCP estiverem em vigor é que a verdadeira aplicação do mínimo privilégio poderá ser obtida para fluxos de trabalho autênticos.
Detalhe crítico de implementação: Os agentes devem propagar a identidade do usuário
Para que a identidade delegada funcione de ponta a ponta, o tempo de execução do agente deve propagar ativamente as informações de identidade do usuário. Em muitas implementações atuais, o usuário é autenticado no front-end (por exemplo, usando ZTNA e OIDC), mas as chamadas de ferramentas downstream ainda são feitas com credenciais de serviço estáticas. Quando isso ocorre, a atribuição do usuário é perdida e os controles de privilégio mínimo são interrompidos.
Para habilitar o Zero Trust com reconhecimento de IA, o agente ou a estrutura do agente deve garantir que as solicitações de MCP ou de ferramenta de saída carreguem uma credencial verificável e vinculada ao usuário para o AI>Secure. Esse recurso não é automático na maioria das estruturas de agentes e geralmente requer configuração explícita e, em alguns casos, pequenas alterações no código.
Padrão de produção recomendado: Cabeçalhos de dupla identidade
Nas implantações de produção do AI>Secure, as solicitações normalmente incluem duas identidades verificáveis de forma independente:
Identidade do agente:
Autorização: Bearer
Identidade do usuário:
X-AI-User-Assertion:
Delegado a montante:
Autorização: Bearer
Ambos os tokens são validados de forma independente pela AI>Secure antes que qualquer avaliação de política seja realizada.
O que muda no agente (mínimo)
A maioria das estruturas de agentes exige apenas pequenas alterações para dar suporte a esse padrão:
- aponte o ponto de extremidade MCP para AI>Secure
- continuar enviando o Agent JWT existente
- adicionar um cabeçalho de saída com o JWT do usuário
As estruturas modernas, como o OpenClaw, geralmente oferecem suporte a cabeçalhos de saída personalizados, o que torna essa transição simples. Não são necessárias alterações no protocolo MCP.
Como a AI>Secure aplica o privilégio mínimo
Quando uma solicitação chega ao AI>Secure, ocorrem as seguintes etapas:
- A identidade do agente é validada
- A identidade do usuário é validada
- O tráfego MCP é analisado
- A política de granularidade fina é avaliada
- AI>Secure realiza troca de tokens
- Um token delegado de curta duração é enviado para o upstream
Antes de encaminhar a solicitação, o AI>Secure remove as credenciais originais e as injeta:
Autorização: Bearer
Isso garante que o servidor MCP receba apenas uma identidade com escopo adequado.
Com o que o AI>Secure deve ser configurado
Autenticação upstream por servidor MCP
Para cada servidor MCP, o AI>Secure é configurado com o método de autenticação upstream apropriado, que pode incluir:
- Portador do OAuth
- Chave da API
- mTLS
- outros métodos suportados
Políticas de autorização refinadas
As políticas do AI>Secure são capazes de aplicar:
- ferramenta permitir/negar regras
- inspeção de argumentos
- controles de usuário/grupo
- condições baseadas em risco
Configuração do agente de identidade
O AI>Secure Identity Broker lida com as seguintes tarefas:
- validação de tokens de usuário recebidos
- verificação do emissor e do público
- Executando a troca de tokens OAuth
- cunhar tokens delegados de curta duração
- tokens de escopo para o serviço MCP de destino
- aplicação de limites de tempo de vida
- opcionalmente transformando reivindicações
Com esses mecanismos, os servidores MCP recebem apenas credenciais de menor privilégio e não precisam implementar uma lógica de identidade complexa por conta própria.
O resultado final
O desafio não é uma falha no protocolo MCP. O principal problema é que muitas implantações de agentes iniciais (ou mesmo atuais) dependem de credenciais com privilégios excessivos e sem a devida atribuição. Essas credenciais concedem permissões excessivas e não conseguem identificar claramente qual usuário ou agente executou uma ação específica. Como resultado, os serviços de MCP estão sendo solicitados a aplicar controles de segurança e políticas de acesso para os quais nunca foram projetados, sobrecarregando indevidamente suas implementações.
Ao colocar uma camada ZTNA com reconhecimento de IA na frente dos serviços MCP, as empresas podem:
- centralizar o controle de acesso
- preservar a atribuição do usuário
- aplicar o privilégio mínimo por ferramenta
- evitar sobrecarregar as implementações de serviços MCP
As organizações que adaptarem sua arquitetura Zero Trust para a era da IA estarão mais bem posicionadas para dimensionar com segurança os funcionários digitais. Na era dos agentes autônomos, a Confiança Zero deve ir além de quem pode se conectar – até o que a IA realmente tem permissão para fazer.