"O Imposto de Ferramentas": Por que agentes de IA desperdiçam tokens
Cada chamada para um modelo de linguagem grande envolve não apenas o pedido em si, mas também todo o contexto que entra nele. Quando um agente está conectado a servidores do Model Context Protocol (MCP), o modelo recebe o catálogo completo das ferramentas disponíveis em cada etapa: seus nomes, descrições, parâmetros e esquemas. Mesmo que o agente nunca use a maioria deles, os tokens para processá-los já estão gastos — antes mesmo do modelo decidir chamar qualquer coisa. Em Okta, esse efeito é chamado de "imposto de ferramentas", e cresce com o número de ferramentas e usuários.
O problema não é só dinheiro. O agente vê definições de todas as ferramentas, incluindo aquelas a que não tem acesso. Uma tentativa de usar tal ferramenta será bloqueada no momento da execução, mas os tokens para processá-la no prompt já estão consumidos — eles não podem ser devolvidos. Assim, tanto do ponto de vista de segurança como econômico, você precisa cortar o excesso antes que a informação chegue ao modelo.
Como Okta se propõe a cortar custos
A solução do Okta é construída restringindo a lista de ferramentas com base na identidade. Em vez de dar ao agente todo o catálogo de servidores MCP, um administrador especifica através do painel Okta quais ferramentas são permitidas para um agente específico ou o usuário por trás dele. Okta retorna apenas este conjunto reduzido, e é isso que vai para o prompt do modelo em cada passo. Além disso, o sistema verifica permissões no momento da execução, logo antes da chamada real.
Essencialmente, isso é aplicar o princípio do mínimo privilégio ao nível da ferramenta. O agente não deve saber sobre recursos, bases de dados ou ações para as quais não tem permissão explícita. E uma vez que uma ferramenta não entra no prompt, nenhum token é gasto em seu esquema. Em comparação com a abordagem anterior, onde o acesso só poderia ser restrito a um servidor inteiro, isso reduz o escopo para ferramentas individuais dentro de um servidor. Por exemplo, com integrações para o Google Workspace, Slack ou servidores MCP internos, um agente poderia ter acesso somente para leitura ao email, mas não permissão para enviar mensagens.
O que a modelagem mostrou e como a abordagem difere de Gateways
Okta ainda não liberou dados de implantações reais — as estimativas são baseadas em modelagem interna. Dentro da empresa, eles montaram um catálogo de ferramentas empresariais, mapearam-nas para escopos OAuth, e dividiram os usuários em papéis típicos: desde especialistas de suporte com direitos somente de leitura até superadmins. Em alguns cenários, o número de ferramentas visíveis foi reduzido em mais de 90%, e o custo de seus esquemas caiu aproximadamente na mesma proporção. Valores absolutos em tokens ou dólares não são divulgados, porque o resultado depende muito do catálogo, distribuição de permissão, tamanho médio do esquema, volume de solicitação e preço do modelo específico.
O escopo baseado na identidade deve ser distinto dos controles de custos de gateway. Gateways pode limitar orçamentos por chave, equipe, ou grupo, e fornecer limitação de taxa e roteamento, mas eles começam depois que o modelo já tomou uma decisão cara. As permissões baseadas em identidade determinam o próprio conjunto de ferramentas disponíveis com antecedência , no nível de agente e usuário, em vez de para um grupo como um todo. Isso não só salva tokens, mas também remove da visão do agente tudo o que ele não deveria ter acesso.
Parece que Okta vê esse mecanismo como parte de uma estratégia mais ampla para ambientes agentic seguros. O quão eficaz ele será na prática ficará claro depois de projetos-piloto com clientes, mas a própria ideia — remover o excesso do prompt antes de pagar por ele — parece um passo lógico na luta contra os contextos de agentes de IA inchados.
