Com a evolução do Model Context Protocol para uma arquitetura sem sessões obrigatórias, OAuth, tokens de acesso e políticas de autorização ganham protagonismo na proteção de agentes autônomos e sistemas corporativos.

A inteligência artificial está deixando de ser apenas uma interface de conversação para se transformar em uma tecnologia capaz de executar tarefas, acessar sistemas e tomar decisões operacionais. Essa evolução, impulsionada pelos chamados agentes de IA, está obrigando as empresas a repensarem seus modelos de segurança.

No centro dessa transformação está o Model Context Protocol (MCP), um padrão aberto que permite conectar aplicações de inteligência artificial a ferramentas, bases de dados e serviços externos.

Uma mudança recente na arquitetura do protocolo trouxe uma discussão importante para o mercado: como garantir que agentes autônomos acessem apenas os recursos necessários, especialmente quando a comunicação não depende mais de sessões persistentes?

O tema foi abordado pela Curity em um artigo publicado em outubro de 2026, que destaca o crescimento da importância dos mecanismos de autorização na nova arquitetura do MCP.

A questão vai além de uma mudança técnica. Ela coloca a identidade digital no centro da segurança da inteligência artificial corporativa.

O que mudou no MCP?

Tradicionalmente, muitas aplicações utilizam sessões para manter o contexto de comunicação entre clientes e servidores. Quando um usuário se autentica em determinado sistema, uma sessão permite reconhecer suas solicitações posteriores sem repetir todo o processo de identificação.

Nas implementações anteriores do MCP, a comunicação envolvia uma etapa de inicialização e mecanismos de gerenciamento de sessões.

A evolução apresentada pela Curity, associada à especificação de 28 de julho de 2026, adota uma abordagem stateless, ou seja, sem a necessidade de manter uma sessão de protocolo entre as solicitações.

Isso significa que cada requisição pode ser processada de maneira independente, reduzindo a complexidade de gerenciamento das conexões.

Do ponto de vista operacional, o modelo oferece vantagens importantes, como maior facilidade de escalabilidade, simplificação da infraestrutura e menor dependência de informações armazenadas entre chamadas.

Entretanto, essa mudança também exige atenção à segurança.

Se o servidor não depende de uma sessão para reconhecer quem está realizando determinada operação, os mecanismos de autenticação e autorização precisam fornecer informações suficientes para avaliar cada solicitação.

É nesse cenário que OAuth e os tokens de acesso ganham relevância.

OAuth deixa de ser apenas uma integração técnica

O OAuth 2.0 já é amplamente utilizado para permitir que aplicações acessem recursos protegidos sem compartilhar diretamente as credenciais dos usuários.

No universo dos agentes de inteligência artificial, seu papel se torna ainda mais estratégico.

Imagine um agente responsável por organizar viagens corporativas. Para executar sua função, ele pode precisar consultar o calendário de um colaborador, acessar políticas internas, pesquisar passagens e criar solicitações em um sistema financeiro.

Embora todas essas atividades façam parte de um mesmo processo, elas não deveriam compartilhar permissões irrestritas.

O agente pode ter autorização para consultar compromissos, mas não para excluir eventos. Pode pesquisar passagens, mas não necessariamente aprovar pagamentos.

Com OAuth, as permissões podem ser representadas por tokens de acesso emitidos para recursos e finalidades específicas.

Dessa forma, a autorização deixa de depender apenas da identidade do usuário ou do agente e passa a considerar também quais operações estão sendo solicitadas.

A diferença é fundamental: um agente autenticado não é necessariamente um agente autorizado a executar qualquer ação.

Tokens de acesso passam a carregar o contexto de segurança

Em uma arquitetura MCP sem sessões obrigatórias, o token de acesso assume um papel importante na identificação e autorização das solicitações.

Dependendo da implementação, o token pode representar informações como identidade do usuário, aplicação cliente, público destinatário, escopos de acesso e outros atributos relevantes.

Essas informações podem ser utilizadas por diferentes componentes da arquitetura, incluindo gateways, servidores MCP, APIs e serviços internos.

O resultado é a possibilidade de construir um modelo no qual as decisões de autorização sejam aplicadas em diferentes pontos da comunicação.

Entretanto, o uso de tokens também exige cuidados.

Um token válido não deve ser interpretado automaticamente como autorização irrestrita. É necessário verificar seu emissor, destinatário, validade, permissões e demais condições estabelecidas pela política de segurança.

Além disso, a identidade de quem delegou uma tarefa e a identidade do agente que a executa podem precisar ser tratadas separadamente.

Essa distinção é especialmente importante quando diferentes agentes colaboram para concluir uma atividade.

Token Exchange: menos privilégios, menos riscos

Uma das tecnologias destacadas pela Curity é o OAuth 2.0 Token Exchange, definido pela RFC 8693.

O mecanismo permite trocar um token existente por outro com características adequadas ao serviço que será acessado.

Considere um agente de IA que recebe autorização para executar um processo envolvendo três sistemas corporativos.

Em vez de utilizar o mesmo token com permissões amplas em todas as etapas, a arquitetura pode permitir a emissão de tokens específicos para cada serviço.

Um token utilizado para consultar dados de clientes não precisa conceder permissão para modificar informações financeiras. Da mesma forma, uma credencial destinada a uma API não deveria ser aceita automaticamente por outra.

Esse modelo reduz a exposição de privilégios e limita o impacto potencial do comprometimento de uma credencial.

A abordagem também se aproxima de um dos princípios fundamentais do Zero Trust: conceder somente o acesso necessário, pelo tempo necessário e dentro do contexto autorizado.

Vale destacar que a simples adoção de Token Exchange não garante essa proteção. Os benefícios dependem das políticas aplicadas pelo servidor de autorização e da validação correta dos tokens pelos serviços envolvidos.

O desafio da identidade não humana

A adoção de agentes autônomos está acelerando uma transformação que já vinha ocorrendo no mercado de Identity and Access Management (IAM).

Historicamente, a gestão de identidades corporativas esteve concentrada em colaboradores, fornecedores, parceiros e contas técnicas.

Agora, as organizações precisam lidar com agentes de IA que podem executar tarefas em nome de pessoas, aplicações ou processos de negócio.

Essas identidades apresentam características diferentes das contas tradicionais.

Um agente pode ser criado dinamicamente, operar por poucos minutos, acessar múltiplos serviços e executar centenas de solicitações durante uma única atividade.

Além disso, um agente pode acionar outros agentes, formando cadeias de execução nas quais a responsabilidade por determinada ação se torna mais difícil de identificar.

Nesse ambiente, perguntas aparentemente simples passam a exigir respostas mais elaboradas:

• Quem criou e é responsável pelo agente?
• Em nome de qual usuário ou processo ele está atuando?
• Quais sistemas e informações pode acessar?
• Quem aprovou suas permissões?
• Como suas atividades são registradas e auditadas?
• Como revogar seu acesso quando a tarefa terminar ou ocorrer um incidente?

Essas questões demonstram por que a segurança dos agentes de IA não pode ser tratada apenas como um problema de proteção de APIs.

Ela exige governança de identidades, gestão do ciclo de vida, controle de privilégios e rastreabilidade.

MCP e Zero Trust: uma aproximação natural

A arquitetura stateless do MCP reforça uma característica importante dos modelos modernos de segurança: não presumir que uma solicitação é confiável apenas porque faz parte de uma comunicação anteriormente estabelecida.

Cada operação deve ser avaliada com base em informações confiáveis e políticas apropriadas.

Essa abordagem se conecta diretamente aos princípios de Zero Trust, especialmente à verificação explícita e ao princípio do menor privilégio.

Entretanto, existe uma diferença entre validar um token e implementar uma arquitetura completa de Zero Trust.

Um token pode comprovar que determinada aplicação recebeu uma autorização, mas não necessariamente indicar que a operação continua adequada ao contexto atual.

Por isso, arquiteturas mais avançadas podem combinar OAuth com mecanismos de autorização contextual, análise de risco, políticas baseadas em atributos e monitoramento contínuo.

A integração desses elementos permite decisões mais precisas, considerando não apenas quem está solicitando acesso, mas também qual recurso será utilizado, qual operação será executada e em quais condições.

O risco de agentes autorizados executarem ações indevidas

Um dos desafios mais relevantes da inteligência artificial agêntica está no fato de que comportamentos inesperados nem sempre envolvem credenciais roubadas ou acessos não autorizados.

Um agente pode possuir uma identidade legítima e permissões válidas, mas executar uma ação inadequada após interpretar incorretamente uma instrução ou receber conteúdo malicioso.

Ataques de prompt injection representam um exemplo desse cenário.

Um documento, uma página web ou uma resposta de ferramenta pode conter instruções maliciosas destinadas a influenciar o comportamento do agente.

Se o agente possuir permissões excessivas, o impacto potencial será maior.

Mecanismos de autorização bem implementados ajudam a limitar esse risco, impedindo operações que ultrapassem os privilégios concedidos.

Entretanto, não eliminam completamente a possibilidade de uso indevido de permissões legítimas.

Por esse motivo, a segurança de agentes precisa combinar autorização, validação das operações, proteção contra manipulação de instruções, monitoramento e capacidade de resposta.

A governança de IA precisa acompanhar a velocidade da automação

A principal consequência dessa evolução é que os processos tradicionais de governança de acesso precisarão se adaptar.

Em muitas organizações, a concessão de permissões ainda depende de solicitações manuais, aprovações e revisões periódicas.

Esse modelo continua importante para determinados controles, mas pode não ser suficiente para ambientes nos quais agentes são criados e executados dinamicamente.

A tendência é ampliar a utilização de autorizações temporárias, políticas dinâmicas, identidades de curta duração e mecanismos automatizados de revogação.

Também será necessário integrar a governança de agentes às soluções existentes de IAM, PAM, segurança de APIs e monitoramento de ameaças.

Isso não significa substituir os controles tradicionais, mas estendê-los a uma nova categoria de identidade digital.

O futuro da segurança de IA passa pela autorização

A evolução do MCP evidencia que a segurança da inteligência artificial corporativa não depende apenas da proteção dos modelos ou da qualidade das instruções utilizadas.

À medida que agentes passam a interagir diretamente com sistemas de negócio, a capacidade de controlar suas permissões se torna um requisito essencial.

OAuth, Token Exchange, políticas de autorização e governança de identidades não são tecnologias novas. O que está mudando é o contexto em que precisam operar.

O desafio agora é aplicar esses mecanismos a sistemas que executam tarefas de maneira autônoma, frequentemente em nome de usuários e por meio de múltiplos serviços.

Para as organizações, a mensagem é clara: adotar agentes de IA sem uma estratégia de identidade e autorização significa ampliar a superfície de risco.

Na era da inteligência artificial agêntica, a pergunta não é apenas o que um agente consegue fazer, mas o que ele realmente deveria ter permissão para fazer.

Fonte de referência: Curity — Now That MCP Is Stateless, Authorization Matters More Than Ever, Michal Trojanowski, 5 de outubro de 2026.