Os desenvolvedores estão criando agentes de IA em ritmo acelerado para automatizar tudo, desde o suporte ao cliente até o gerenciamento de infraestrutura. Esses agentes de IA são muito robustos e conseguem ler e-mails, consultar bancos de dados de produção e até mesmo implantar servidores. Embora as capacidades dessas máquinas de IA tenham evoluído, a forma como as protegemos não acompanhou essa evolução.
A maioria dos agentes de IA atuais é operada usando chaves de API estáticas com permissões amplas e de longa duração. Isso significa que, se um invasor modificar o agente por meio de injeção de prompt, ele poderá obter as chaves de administrador. Este modelo de segurança está desatualizado e viola os princípios fundamentais do Zero Trust.
Primeiro, vamos explorar por que os agentes de IA precisam de identidades distintas e, em seguida, veremos como implementar o Protocolo de Contexto do Modelo (MCP) para conceder aos agentes de IA acesso com privilégios mínimos e garantir que eles ajam somente quando autorizados.
O problema do “superusuário”
Na última década, abandonamos o uso de senhas compartilhadas entre humanos, mas frequentemente tratamos agentes de IA como superusuários, concedendo-lhes segredos pré-programados. Ao inserir um token de API estático diretamente nas variáveis de ambiente de um agente, criamos uma grande superfície de ataque. Este token carece de contexto – o sistema sabe que o token da API foi usado, mas não sabe por que ou por quem o agente foi acionado.
Os agentes podem ter alucinações ou ser manipulados; uma vez que isso aconteça, eles podem realizar ações difíceis de rastrear, e pode ser ainda mais difícil revogar o acesso sem comprometer toda a aplicação. Para resolver esse problema, precisamos tratar os agentes de IA com a mesma mentalidade de priorizar a identidade que aplicamos aos funcionários humanos.
O pesadelo da “rotação”
Sejamos honestos, ninguém troca as chaves estáticas com a frequência necessária porque é um pesadelo logístico.
Se tivermos um único OKTA_API_TOKEN embutido em três microsserviços diferentes, um pipeline de CI/CD e um arquivo .env local, isso pode causar problemas. Criar um arquivo para teste e rotacionar essa chave não é uma tarefa de segurança – é uma interrupção prestes a acontecer. Para fazer isso corretamente, precisamos gerar uma nova chave, encontrar todos os repositórios que usam a chave antiga, reimplantar todos os serviços e torcer para não termos esquecido nenhuma pequena tarefa cron em execução em algum servidor legado.
Como esse processo é muito trabalhoso, as equipes o adiam. Já vi algumas chaves de produção que não foram rotacionadas há anos porque o desenvolvedor original que as criou saiu da empresa, e ninguém quer ser o responsável por quebrar a compilação alterando-as. Isso cria uma enorme janela de vulnerabilidade: se essa chave vazar, o invasor terá acesso permanente até que ela seja rotacionada imediatamente.
A solução: o fluxo “em nome de”
Para garantir a segurança dessa nova onda de automação, precisamos migrar de chaves estáticas para a troca dinâmica de tokens (definida na RFC 8693). Em arquitetura de identidade, conhecemos isso como o fluxo "em nome de" (OBO, na sigla em inglês). Nesse caso, o agente atua como um delegado e não como um administrador em Modo Deus. Quando um usuário pede ao agente para fazer algo, o agente se autentica, mas solicita permissão para agir em nome desse usuário específico.
Isso requer dois componentes principais:
- Um protocolo padrão: Precisamos de uma maneira para a IA padronizar suas solicitações; o Protocolo de Contexto do Modelo (MCP) é onde isso entra em jogo.
- Afirmação de identidade: Precisamos de uma maneira de trocar a sessão do usuário por um token de acesso temporário e com escopo definido para o agente.
Implementando o Model Context Protocol (MCP)
Agora, vamos analisar como podemos implementar esse padrão na prática. Para isso, utilizaremos o Okta MCP Server de código aberto para gerenciar a conexão entre nosso LLM (como o Github Copilot ou o Claude) e seu provedor de identidade (IdP).
Passo 1: remover segredos estáticos
Primeiro, vamos auditar o código do nosso agente. Para isso, identifique quaisquer variáveis de ambiente que armazenem segredos de longa duração, por exemplo, OKTA_API_TOKEN, e exclua todas elas. Usar chaves estáticas para agentes dinâmicos é o equivalente, em termos de segurança, a compartilhar sua senha bancária com um prestador de serviços temporário. O objetivo é garantir que o agente não tenha privilégios quando estiver ocioso.
Etapa 2: configurar permissões com escopo
Em seu respectivo IdP, registre este agente como um aplicativo distinto. Isso nos permite definir exatamente o que ele pode e o que não pode fazer. Em vez de conceder acesso de leitura/gravação, tente usar escopos granulares. Por exemplo, não deveria ter permissões explícitas como users.delete. No Okta, isso é gerenciado por meio do acesso entre aplicativos (XAA), que nos permite vincular essas permissões específicas ao ID de cliente exclusivo do agente.
Passo 3: A troca de token
Agora, vamos analisar o fluxo técnico quando um usuário solicita algo ao agente (por exemplo, "Redefinir minha senha"):
- O gatilho: O usuário envia uma mensagem ao agente por meio de seu IDE ou interface de chat.
- O handshake: O agente então se conecta ao servidor MCP usando o protocolo padrão.
- A troca: O servidor intercepta a solicitação e realiza uma asserção de identidade. A mensagem enviada ao IdP diz: "Sou um agente de redefinição de senha." O usuário X acaba de me autorizar. Solicito, por gentileza, um token válido por cinco minutos.
- A ação: O IdP emite então um token de curta duração, válido apenas para essa tarefa específica de redefinição de senha.
O resultado: agentes prontos para auditoria
Ao implementarmos essa arquitetura, transformamos nossos registros vagos em um rastreamento de pilha claro.
Em vez de exibir uma ação genérica do sistema, nossos registros mostrarão:
“O agente de redefinição de senha acessou a API de senhas em nome do Usuário-X.”
Essa visibilidade granular permite que as equipes de segurança realizem revisões de acesso em agentes de IA, da mesma forma que fazem com os funcionários comuns. Se, por algum motivo, um agente de IA começar a se comportar de forma suspeita, podemos revogar instantaneamente sua política de acesso específica, sem precisar rotacionar as chaves de toda a equipe de engenharia.
Das chaves estáticas para a autonomia segura
À medida que os agentes de IA evoluem e se tornam mais autônomos, não podemos nos dar ao luxo de protegê-los com as mesmas chaves estáticas antigas que usávamos para tarefas agendadas em 2015.
Ao adotarmos o Protocolo de Contexto de Modelo e a asserção de identidade (XAA), poderemos ter agentes de IA útis, capazes e, o mais importante, seguros.
Vamos começar a criar? Conheça o servidor Okta MCP de código aberto. Esta implementação de referência fornece uma ponte entre o agente de IA e qualquer IdP para permitir uma troca segura de tokens em nome de terceiros.
