Agentes de IA estão ficando cada vez mais comuns nas empresas, mas tem um detalhe que passa batido na maioria das conversas sobre o assunto: cada vez que um agente faz uma chamada ao modelo, ele carrega consigo a lista completa de ferramentas disponíveis no servidor MCP, mesmo aquelas que nunca vão ser usadas. Isso parece um detalhe técnico menor, mas quando você começa a escalar o uso de agentes em produção, esse peso extra começa a aparecer de forma bem concreta na fatura do seu provedor de LLM.
Isso tem um nome e um custo. A Okta chamou esse peso extra de tool tax, ou taxa de ferramenta, e está propondo uma solução que une controle de acesso por identidade com uma redução significativa no custo de tokens consumidos a cada interação. Esses tokens incluem esquemas, nomes, descrições e parâmetros de cada ferramenta exposta pelo servidor, o que gera um overhead de prompt que o modelo processa mesmo para ferramentas que jamais serão chamadas. O número que chama atenção é esse: em alguns cenários, a modelagem interna da Okta apontou uma redução de mais de 90% na quantidade de ferramentas visíveis para o agente. Menos ferramentas no prompt significa menos tokens processados, e isso se traduz diretamente em menos dinheiro gasto por chamada de modelo.
Mas o que torna essa proposta ainda mais interessante é que ela não exige uma camada separada de controle de custos. A filtragem acontece antes mesmo de o prompt ser montado, usando as permissões já atribuídas à identidade do agente e do usuário associado a ele. Ou seja, eficiência e segurança andando juntas, sem criar mais complexidade no sistema. Vale destacar que a própria Okta reconhece que esses números vêm de modelagem interna, feita com dados de produto da empresa e documentação pública de fornecedores, sem uso de dados de clientes reais em produção. 🎯
O problema que ninguém estava falando sobre MCP
O Model Context Protocol, ou MCP, virou um caminho popular para conectar agentes de IA a ferramentas e dados. A ideia é boa: em vez de cada integração ter seu próprio jeito de funcionar, você tem um protocolo comum que qualquer agente pode usar para acessar APIs, bancos de dados, sistemas internos e o que mais for necessário. A Okta cita conexões com o Google Workspace, com o Slack e com servidores MCP internos como exemplos práticos disso. O problema começa a aparecer quando um servidor MCP expõe dezenas ou centenas de ferramentas, e o agente precisa receber a representação de cada uma delas no prompt a cada turno, independentemente de quantas dessas ferramentas ele vai de fato utilizar naquela interação específica.
Essa representação não é curta. Ela inclui o esquema completo da ferramenta, além do nome, da descrição e dos parâmetros. Na prática, o que acontece é o seguinte: imagine um agente configurado para ajudar um time de suporte ao cliente. Esse agente tem acesso a um servidor MCP corporativo que expõe ferramentas de CRM, ferramentas de faturamento, ferramentas de RH, ferramentas de infraestrutura e por aí vai. Quando o agente recebe uma pergunta simples sobre o status de um pedido, ele ainda assim carrega no prompt a descrição de absolutamente todas essas ferramentas, porque o servidor não sabe de antemão o que o agente vai precisar. Esse carregamento indiscriminado é exatamente o que a Okta está chamando de tool tax, e o impacto no consumo de tokens é proporcional ao tamanho da lista de ferramentas disponíveis.
- E-BOOK GRATUITO
Um guia prático para avaliar, comparar e implementar inteligência artificial com clareza — sem desperdício de tempo ou dinheiro.
Pare de contratar ferramentas sem direção. Criamos um método estruturado para decidir qual IA realmente faz sentido para o seu negócio.
Entrega em PDF no seu e-mail · Sem spam · LGPD
🔒 Seus dados são protegidos conforme a LGPD. Você pode descadastrar a qualquer momento.
O que torna esse problema ainda mais delicado é que ele tem duas dimensões que se somam. A Okta descreve como um problema de contagem de ferramentas e também de contagem de usuários. Quanto mais ferramentas integradas ao servidor MCP, maior o custo por chamada. E cada usuário ativo carrega esse overhead de prompt toda vez que seu agente faz uma chamada ao modelo. Então quanto mais gente usando, mais rápido a conta sobe. Não é à toa que equipes de engenharia que trabalham com LLMs em produção começaram a levantar esse ponto como um dos maiores desafios de escalabilidade no uso corporativo de agentes de IA.
O custo aparece antes de qualquer tentativa de uso
Um detalhe importante que a Okta faz questão de reforçar é o timing desse custo. O gasto com tokens acontece antes de o agente sequer tentar chamar uma ferramenta. Isso significa que, se você tem um controle que rejeita uma requisição não autorizada apenas no momento da execução, esse controle não recupera os tokens que já foram consumidos ao processar aquela definição de ferramenta no prompt. O modelo já leu, já processou e já cobrou por aquele conteúdo, mesmo que a ação nunca chegue a ser executada. É aí que mora boa parte do desperdício que a proposta da Okta quer eliminar.
Como a Okta conectou identidade e eficiência de tokens
A solução que a Okta está apresentando parte de um princípio que já existe no mundo da segurança da informação há décadas: o princípio do menor privilégio. A ideia é simples, cada usuário, sistema ou processo deve ter acesso apenas ao que precisa para realizar sua função, nada além disso. Aplicar esse conceito ao contexto de MCP e agentes de IA é o que a Okta está fazendo, e o resultado é que o agente só enxerga as ferramentas que ele tem permissão de usar, com base na identidade do agente e na identidade do usuário humano que está por trás daquela interação.
A empresa posiciona esse recurso dentro do que chama de blueprint para a empresa agêntica segura, uma estrutura que pede às organizações para identificarem seus agentes, suas conexões permitidas e suas ações autorizadas. O pulo do gato aqui é que a Okta estreita a pergunta de acesso: em vez de liberar ou bloquear o acesso a um servidor MCP inteiro, o controle passa a ser feito ferramenta por ferramenta dentro daquele servidor. Um administrador configura no painel da Okta quais ferramentas uma determinada identidade pode usar, e a Okta então devolve apenas esse conjunto reduzido de ferramentas, em vez do catálogo completo do servidor.
Tecnicamente, o que acontece é que antes de montar o prompt e enviar a chamada ao modelo, o sistema consulta as políticas de acesso associadas àquele contexto específico. Se o usuário logado é do time de suporte, ele vai ver as ferramentas de CRM e de gestão de tickets, mas não vai ver as ferramentas de folha de pagamento ou de configuração de infraestrutura. Esse filtro acontece na camada de identidade, usando as permissões que já existem no sistema de controle de acesso da empresa, sem precisar criar regras novas ou manter uma lista separada de o que cada agente pode ou não pode usar. E tem uma segunda verificação importante: a Okta confere o escopo novamente no momento da execução, antes de uma chamada de ferramenta rodar de fato.
O que os números realmente mostram
Para chegar aos números que divulgou, a Okta modelou um único cliente MCP com acesso a um catálogo de ferramentas corporativas e comparou quantas ferramentas ficavam visíveis para o modelo antes e depois da filtragem baseada em identidade. Para estimar a exposição com escopo, a empresa mapeou as ferramentas do Okta MCP Server para os escopos OAuth que as liberam, e então definiu segmentos de usuários representativos.
- Usuários de helpdesk somente leitura
- Operadores de helpdesk
- Administradores de aplicações
- Administradores de marca e e-mail
- Super administradores
Cada segmento recebeu um peso de acordo com uma fatia presumida do tráfego mensal. A redução na contagem de ferramentas foi calculada como um menos a razão entre ferramentas com escopo e ferramentas sem escopo, e alguns cenários removeram mais de 90% das ferramentas visíveis. Como cada ferramenta contribui com nome, descrição e esquema de parâmetros em cada prompt, a Okta afirma que o custo de tokens de esquema acompanha quase linearmente a contagem de ferramentas. Ou seja, cortar 90% das ferramentas corta aproximadamente a mesma proporção de tokens de esquema. A empresa faz a ressalva de que os resultados variam conforme o catálogo de ferramentas, a distribuição de permissões e o modelo escolhido, além do tamanho médio dos esquemas, do volume de requisições e do preço do modelo. 💡
Identidade versus gateways: a diferença que importa
Um ponto interessante da proposta é como a Okta diferencia sua abordagem de identidade dos controles de gateway. Gateways conseguem limitar gastos por chave, por time ou por grupo, e ainda oferecem roteamento e limitação de taxa. Eles medem os tokens que entram e saem do sistema, assim como os valores gastos em dólares. O problema é que esses controles agem depois que uma decisão do modelo já ficou cara.
As permissões de identidade oferecem uma entrada diferente na equação. Elas determinam quais ferramentas estão disponíveis para um agente específico ou para a pessoa por trás dele, atuando individualmente em vez de aplicar informação de acesso apenas no nível de grupo. Como resumiu Paul Webber, analista principal da indústria de cibersegurança na Software Analyst Cyber Research, o controle de custo para agentes é melhor entregue com ferramentas de governança de identidade que oferecem controle mais granular e preciso sem atrapalhar os processos de negócio. Segundo ele, a abordagem da Okta é elegante porque aproveita os mesmos dados de permissão que governam a segurança, e não uma camada de medição separada sem essa visão. Em outras palavras, o gateway controla o que passa por ele, enquanto a camada de identidade filtra o conjunto de ferramentas antes mesmo de elas precisarem ser medidas.
Por que isso importa além do custo de tokens
Falar em redução de custo de tokens já seria motivo suficiente para prestar atenção nessa proposta, mas a dimensão de segurança que vem junto com ela talvez seja ainda mais relevante para empresas que estão em estágios mais avançados de adoção de agentes de IA. Quando um agente tem visibilidade sobre ferramentas que ele não deveria usar, existe um risco real de que, em algum momento, ele invoque uma dessas ferramentas de forma indevida, seja por uma instrução maliciosa no input do usuário, seja por uma cadeia de raciocínio que chegou a uma conclusão errada.
Receba o melhor conteúdo de inovação em seu e-mail
Todas as notícias, dicas, tendências e recursos que você procura entregues na sua caixa de entrada.
Ao assinar a newsletter, você concorda em receber comunicações da Método Viral. A gente se compromete a sempre proteger e respeitar sua privacidade.
Ao limitar a visibilidade do agente apenas às ferramentas que fazem sentido para aquele contexto específico, a Okta está reduzindo o que chama de raio de explosão de uma identidade comprometida. Um agente que não sabe que existe uma ferramenta de transferência bancária não pode ser manipulado para usar essa ferramenta, mesmo que alguém tente induzir esse comportamento por meio de um input cuidadosamente construído. A verificação de escopo acontece em dois momentos, primeiro quando a lista de ferramentas é montada para o prompt do agente, e depois quando o agente tenta executar uma chamada. Isso não resolve todos os problemas de segurança de agentes, claro, mas é uma camada de proteção adicional que vem sem custo extra de implementação, já que é um subproduto natural do controle de acesso baseado em identidade.
Para organizações que estão avaliando como controlar o acesso via MCP, os principais insumos operacionais são o inventário de ferramentas e o mapeamento de permissões. A metodologia da Okta parte justamente daí: mapear as ferramentas do servidor MCP para os escopos OAuth que as liberam e então comparar o catálogo completo com o catálogo reduzido visível para cada segmento de usuário. Em ambientes corporativos regulados, como bancos, empresas de saúde ou qualquer organização sujeita a normas como a LGPD, ter uma trilha clara do que cada agente tinha permissão de fazer em cada interação vai além de boa prática, é requisito de conformidade. 🔐
A combinação de controle de acesso por identidade com filtragem de ferramentas no MCP representa uma das abordagens mais práticas já vistas para tornar o uso de agentes de IA viável em escala dentro de ambientes corporativos.
O que a Okta está mostrando com essa proposta é que os desafios de custo e segurança no uso de agentes de IA não precisam ser resolvidos com soluções separadas e complexas. Às vezes, conectar bem o que já existe, como uma plataforma de identidade madura com um protocolo de integração de ferramentas como o MCP, é suficiente para gerar um impacto significativo em duas dimensões ao mesmo tempo. E no atual estágio de adoção de LLMs nas empresas, onde os custos operacionais estão sob escrutínio constante e as preocupações com segurança estão crescendo na mesma velocidade que o uso, esse tipo de solução tem tudo para ganhar espaço rápido nas discussões de arquitetura de sistemas baseados em IA. 🚀
