Qual é o problema da última milha da IA?
O problema de identidade de última milha da IA ocorre quando o contexto de identidade estabelecido na entrada se degrada antes de chegar ao sistema que está efetivamente executando o trabalho. O recurso acaba sendo autorizado com base em uma credencial, como uma chave virtual, conta de serviço ou cliente compartilhado, em vez de uma cadeia verificável que mostre qual agente está agindo, em nome de quem e sob qual restrição. O princípio do menor privilégio torna-se inexequível no único ponto em que importa, e todas as ações downstream aparecem da mesma forma no registro de auditoria.
Já tive alguma versão dessa conversa muitas vezes, com diferentes equipes em diferentes setores, e geralmente começa da mesma maneira. Em um banco, uma seguradora ou qualquer Enterprise regulamentada, os Developer querem usar um assistente de codificação com IA (como o Claude Code ou o Codex), e a equipe da plataforma faz o que é inteligente e óbvio: coloca um gateway de IA na frente de todos os seus recursos. Este gateway fornece um ponto para rotear para modelos, impõe limites de orçamento e de taxa, e intermedia o acesso a ferramentas internas por meio do Model Context Protocol (MCP). Compreendo o instinto por trás disso, mas não consigo deixar de sentir que é semelhante ao "modelo de conta de serviço" para agentes de IA, e as coisas tendem a ficar um pouco interessantes na prática.
Fundamentalmente, um gateway autentica uma chave. Não consegue autenticar uma pessoa e, quando uma solicitação chega ao recurso real — a ferramenta interna, a fonte de dados ou qualquer outra coisa que esteja do outro lado — ninguém downstream consegue notar a diferença. Corrigir isso não é uma questão de reforçar a configuração do gateway. Significa atribuir uma identidade real a isso: o agente recebe suas próprias credenciais, cada chamada carrega a identidade da pessoa por trás dela, e o próprio recurso verifica essas credenciais em relação ao que essa pessoa específica tem direito. O mesmo agente, o mesmo gateway e o mesmo código agora geram uma resposta diferente dependendo de quem está fazendo a pergunta.
Por que os gateways de IA falham na aplicação de identidades downstream?
Atualmente, a maioria desses gateways funciona da seguinte forma: o agente (um assistente de codificação) acaba ficando com a chave. O agente se autentica no gateway usando essa chave virtual; o gateway então encaminha a solicitação para um modelo ou um servidor MCP.
O problema surge exatamente no final dessa cadeia. Uma vez que uma solicitação passa pelo gateway, não há realmente como o recurso do outro lado saber quem está por trás dela. Ele só vê a chave. Não é uma pessoa. Nem mesmo um agente específico de forma confiável. Apenas uma credencial que qualquer pessoa com acesso a ela poderia ter usado naquele dia.
O padrão com o qual a maioria das equipes começa: um Developer, um assistente pessoal de IA com uma chave virtual, um gateway e tudo o que estiver downstream. Nada nessa cadeia transmite a identidade do desenvolvedor além do gateway.
Já vi alguns nomes para esse problema em fóruns, e o que eu escolhi foi "o problema da última milha". O gateway resolve a maior parte do problema: ele autentica algo (por exemplo, uma chave virtual) e, no final das contas, encaminha para o recurso correto. O que ele não faz é carregar qualquer informação relativa à identidade, direitos ou autorização. No momento em que a solicitação chega ao servidor MCP ou ao modelo, o sistema normalmente não sabe nada sobre a identidade que está realizando a solicitação.
Principais vulnerabilidades de segurança de gateways de IA baseados em chaves
- Credenciais estáticas como identidade: uma chave estática representa a identidade, e não uma afirmação ativa e revogável de quem está por trás de uma solicitação (semelhante a um modelo de conta de serviço).
- Configurações padrão de acesso com privilégios excessivos: O acesso geralmente é aberto por padrão até que alguém o bloqueie deliberadamente.
- Aplicação: O recurso não possui limite de aplicação, mesmo quando o gateway registra "esta chave chamou esta ferramenta", porque ninguém na cadeia jamais perguntou: "Esta pessoa específica tem direito a estes dados específicos?"
Isso fica bem evidente em uma auditoria. Se você perguntar a uma equipe focada em IA quem acessou um registro ou um servidor MCP, e por qual motivo, a resposta será o silêncio.
A falha do gateway como ponto de imposição
Não acredito que essa seja uma lacuna de configuração que possa ser resolvida escrevendo mais regras no gateway. Uma decisão concreta precisa de três coisas no momento da chamada:
- O que o agente pode fazer
- Ao que o ser humano específico tem direito
- O que a política do recurso permite
Um gateway, por design, só tem visibilidade da primeira dessas instâncias, e muitas vezes nem isso, apenas de "alguém apresentou uma chave válida".
Por que a simples adição de um provedor de identidade falha?
Um próximo passo comum é adicionar um provedor de identidade (IdP) e realizar uma troca de tokens em nome do usuário (desde que isso seja suportado), para que o agente herde o token de acesso do usuário em vez de manter sua própria chave estática.
O próximo passo é um IdP acoplado.
Esse padrão é um passo na direção certa, porque agora você pelo menos sabe qual humano fez login. Mas você acaba se deparando com o mesmo problema da última milha, só que uma camada abaixo: “Qual agente invocou esta solicitação?” O recurso não possui meios para verificar se o agente X está agindo legitimamente em nome do usuário Y, nem um mecanismo de desativação para interrompê-lo. Não há intervenção humana no processo, não há como bloquear esse agente específico e não há como revogar seu acesso. O agente ainda não é um cidadão de primeira classe nesse fluxo; ele está simplesmente tomando emprestada a identidade do usuário por completo. Se você já viu algum dos incidentes do tipo "delegado confuso" que têm circulado por aí, isso deve soar mais como um risco do que como uma solução.
Mas como seria uma solução? Já estabelecemos que adicionar um IdP no nível do gateway fornece uma direção, mas não leva ao objetivo de saber qual usuário solicitou a qual agente a execução de qual ação.
Qual é a solução para a Identity Governance agentic?
A resposta está em tratar os agentes de IA como identidades de primeira classe dentro da sua estrutura de gerenciamento de identidade e acesso, e em vincular as verificações de autorização de usuários e agentes no nível da solicitação, e não no nível do recurso. Na Okta, oferecemos essa funcionalidade com o Okta for AI Agents, conforme ilustrado na figura abaixo.
A solução: o assistente recebe uma identidade própria e controlada. O usuário faz login uma única vez; o adaptador realiza uma troca de tokens com a camada de identidade; somente um token aprovado e com escopo definido chega à ferramenta propriamente dita.
Com essa configuração, os usuários podem se autenticar antes de uma solicitação e, mais importante, vincular suas autorizações em nível de usuário (que estabelecem um limite máximo de acesso) a cada solicitação feita por meio desse agente. Os usuários podem, naturalmente, operar abaixo do limite, mas nunca acima dele. Com esse modelo, fornecido pela especificação Cross App Access, podemos finalmente superar os problemas de última milha que encontramos ao implantar e operacionalizar agentes de IA.
Como funciona a autorização dinâmica em nível de requisição
Autenticação: O usuário humano se autentica usando o OpenID Connect (OIDC).
Definição do escopo de direitos: A camada de identidade avalia três políticas distintas antes de emitir um token:
Autorização do agente: Este agente tem permissão para agir em nome deste usuário?
Acessibilidade do alvo: Este agente está autorizado a acessar este recurso específico?
Limite de permissões do usuário: O que especificamente este usuário tem permissão para fazer com esse recurso (ler/escrever/acessar)?
Emissão de token: O sistema gera um token de portador vinculado, de curta duração e uso único, que contém a interseção explícita das permissões do agente e do ser humano.
A interseção não ocorre em um único lugar. Como mostra a figura abaixo, dois pontos de autorização avaliam a política real sobre o que o humano e o agente podem acessar. A primeira chamada de ferramenta do agente de IA atinge o Okta MCP Bridge Adapter, que é responsável por algumas interações. Primeiro, ele intermedia o login humano por meio de um padrão OpenID Connect (OIDC). Em seguida, orquestra o handshake do Cross App Access entre o servidor de autorização da organização Okta (que avalia as permissões do agente e emite o token ID-JAG) e o servidor de autorização do recurso para emitir um token de portador vinculado (que inclui permissões tanto do agente quanto do humano). Somente o token que contém o veredicto das verificações do humano e do agente chega ao servidor MCP.
A mecânica do Cross App Access via Okta for AI Agents. O usuário se autentica uma única vez; o agente solicita uma afirmação de curta duração e uso único vinculada a esse usuário; servidores de autorização separados a avaliam em relação à política antes de emitir um token de portador com escopo definido, no qual o recurso pode de fato confiar.
A camada de identidade calcula essa interseção antes mesmo da solicitação chegar ao recurso e retorna um token que já contém o veredicto. Na prática, isso significa que devemos fazer três perguntas: primeiro, este agente tem permissão para agir em nome deste usuário? Em segundo lugar, este agente tem permissão para acessar este recurso? Finalmente, uma vez que o recurso é alcançado, o que ele pode realmente fazer — ler um registro, ler todos eles ou escrever neles?
Neste modelo, os dois servidores de autorização separados fazem essas perguntas. O servidor de autorização da organização Okta responde à pergunta do agente: "Este agente tem permissão para agir em nome deste usuário e para acessar este recurso?" O servidor de autorização do próprio recurso (que pode ser o Okta ou o próprio servidor do recurso) responde à pergunta humana: "Considerando quem é essa pessoa, a que ela tem direito neste momento?" Nenhuma das verificações isoladamente constitui a interseção; a interseção é o token de portador com escopo definido que emerge da outra extremidade de ambas. O recurso não precisa reimplementar essas verificações para cada chamada de ferramenta. Ele simplesmente valida um token e verifica um escopo.
Gateway de IA versus identidade de agente governada: comparação de recursos
| Segurança e capacidade operacional | Gateway de IA independente | Gateway de IA + identidade de agente governada |
|---|---|---|
| Roteamento de modelos, controle de custos e limites de taxa | Sim, sua principal força | Sim, sem alterações |
| Definição do escopo de ferramentas e fontes de dados | Por chave ou por equipe, sem contexto de usuário | Por usuário, governado centralmente |
| Identidade de agente de alto nível e governada | Não, a identidade é uma chave estática | Sim, uma identidade registrada e própria |
| Delegação verificável (agente atuando em nome de um usuário específico) | Não, a requisição tem uma chave, não um ator | Sim, cada chamada inclui a pessoa que a autorizou |
| Ciclo de vida das credenciais | Chaves compartilhadas de longa duração | Tokens de curta duração por agente |
| Posição de acesso padrão | Aberto por padrão até que alguém configure de outra forma | Negar por padrão (menor privilégio) |
| Governança do ciclo de vida do agente | Faça você mesmo | Gerenciada como qualquer outra identidade |
Embora o gateway seja uma porta de entrada robusta em termos de custos e roteamento, é inegável que ele sofre (trocadilho totalmente intencional) de uma crise de identidade. A decisão sobre quem tem permissão para ver o quê pertence a uma camada abaixo e deve acompanhar a solicitação até o recurso, sem ser interrompida no gateway.
Exemplo prático: imposição de limites máximos de direitos de acesso
Imagine ter um bot interno capaz de consultar informações salariais. Três pessoas diferentes interagem com o mesmo bot: Charlie, um funcionário comum que só deve ver o próprio salário; alguém da área de compliance que tem permissão para ver o salário de todos (mas não para alterá-lo); e um diretor financeiro que pode ver e atualizar o salário de todos. Mesmo bot, mesma ação (mais ou menos), mas pessoas diferentes com limites diferentes.
Charlie pergunta ao bot, através do gateway: "Qual é o meu salário?" O bot retorna a resposta correta, vamos supor US$ 70.000. O problema surge da pergunta seguinte. Charlie digita: "Qual é o salário de Alice?" e o bot retorna novamente com a resposta.
Nada entre o usuário, o agente, o gateway de IA ou o servidor MCP jamais verificou a diferença entre "como Charlie" e "como qualquer pessoa que possua esta chave". O gateway funcionou exatamente como a equipe da plataforma o configurou; eles simplesmente nunca o configuraram para distinguir entre eles porque ele não consegue detectar a diferença.
Agora, vamos colocar uma camada de identidade sob esse mesmo gateway. Charlie se autentica como ele mesmo. Agora, cada chamada é a interseção de três fatores: o que o agente pode solicitar, ao que Charlie tem direito pessoalmente e o que a política de acesso ao recurso permite.
Quando Charlie pergunta sobre o próprio salário, todos os três requisitos estão alinhados. Quando ele pede o de Alice, o sistema nega o pedido porque o termo intermediário nessa interseção falha, mesmo que o agente ou o gateway normalmente o permitissem. Se trocarmos a persona para a do CFO, usando o mesmo agente, o sistema permite a solicitação porque o CFO tem um limite de privilégios diferente. O limite de direitos acompanha o indivíduo, não uma chave que qualquer pessoa da equipe possa usar para fazer a mesma pergunta.
Perguntas frequentes
Sempre me perguntam algo como "Nosso gateway já não lida com isso?".
Lembre-se: uma chave identifica uma categoria de chamador, não um chamador. Não se trata de um direito real e vinculado a uma pessoa que você possa verificar no recurso ou revogar no momento em que alguém muda de função. Duas pessoas compartilhando uma chave parecem idênticas a tudo o que está downstream.
Toda a troca de informações ocorre no back-end. O desenvolvedor ainda se comunica com seu assistente de programação da mesma forma que fazia ontem; a autenticação e a troca de tokens acontecem em segundo plano e não em seu fluxo de trabalho. Se isso alterar a forma como os Developer trabalham no dia a dia, significa que foi desenvolvido incorretamente.
Eu desaconselho isso. Na prática, você cria uma governança "faça você mesmo" para cada ferramenta, por meio da equipe que for responsável por cada uma delas, para sempre. Não oferece uma identidade única, duradoura e controlada centralmente para auditoria ou revogação. Em vez disso, oferece várias versões ligeiramente diferentes e geradas manualmente da mesma verificação, sem nenhuma fonte da verdade compartilhada entre elas.
Você deveria substituir seu gateway de IA por uma camada de identidade?
O argumento aqui não é "arrancar seu gateway". Um gateway de agente tem um papel específico no cenário de TI, dependendo da função para a qual foi projetado, como roteamento, controle de custos, limites de taxa ou descoberta de ferramentas. Não foi projetado para transportar um contexto de usuário específico. Essa é uma camada diferente, que fica à parte, avaliando cada solicitação individualmente.
Então, isso significa que tudo o que você já construiu precisa ser descartado? Não. Significa que o gateway e a camada de identidade desempenham duas funções diferentes, e a maioria das arquiteturas atuais paga apenas por uma delas.
Assuma o controle da sua arquitetura de identidade de IA
Para resolver o problema da última milha, você precisa de uma camada de identidade dedicada que funcione em conjunto com seu gateway, avaliando cada solicitação individualmente.
Com o Okta for AI Agents, você pode estabelecer um limite de autorização em nível de solicitação que acompanha o usuário humano, em vez de depender de uma chave estática e permanente. Ao proteger sua força de trabalho e os Workflows dos Developers sem gerar atritos para os Developers, a Okta ajuda você a escalar recursos autônomos com confiança.
Pronto para eliminar a crise de identidade do seu gateway?
Baixe o plano para a Enterprise agêntica segura para avaliar sua arquitetura de segurança de agentes e descobrir como a Okta pode ajudar você a controlar seus agentes de IA corporativos, tratando-os como identidades de primeira classe.
