"The Tool Tax": Why AI Agents Waste Tokens
Every call to a large language model involves not just the request itself, but also the entire context that goes into it. When an agent is connected to Model Context Protocol (MCP) servers, the model receives the full catalog of available tools at each step: their names, descriptions, parameters, and schemas. Even if the agent never uses most of them, the tokens for processing them are already spent — before the model even decides to call anything. At Okta, this effect is called the "tool tax," and it grows with the number of tools and users.
The problem isn't just about money. The agent sees definitions of all tools, including those it doesn't have access to. An attempt to use such a tool will be blocked at execution time, but the tokens for processing it in the prompt are already consumed — they can't be returned. So from both a security and an economic standpoint, you need to cut off the excess before the information reaches the model.
How Okta Proposes to Cut Costs
Okta's solution is built on restricting the tool list based on identity. Instead of giving the agent the entire MCP server catalog, an administrator specifies via the Okta dashboard which tools are allowed for a specific agent or the user behind it. Okta returns only this reduced set, and that's what goes into the model's prompt at each step. Additionally, the system checks permissions at execution time, right before the actual call.
Essentially, this is applying the principle of least privilege at the tool level. The agent shouldn't know about resources, databases, or actions it doesn't have explicit permission for. And since a tool doesn't make it into the prompt, no tokens are spent on its schema. Compared to the previous approach, where access could only be restricted to an entire server, this narrows the scope to individual tools within a server. For example, with integrations for Google Workspace, Slack, or internal MCP servers, an agent could be given read-only access to email but not permission to send messages.
What the Modeling Showed and How the Approach Differs from Gateways
Okta hasn't yet released data from real deployments — the estimates are based on internal modeling. Inside the company, they assembled a catalog of enterprise tools, mapped them to OAuth scopes, and divided users into typical roles: from support specialists with read-only rights to superadmins. In some scenarios, the number of visible tools was reduced by more than 90%, and the cost of their schemas dropped by roughly the same proportion. Absolute values in tokens or dollars aren't disclosed, because the outcome heavily depends on the catalog, permission distribution, average schema size, request volume, and the pricing of the specific model.
Identity-based scoping should be distinguished from gateway cost controls. Gateways can limit budgets by key, team, or group, and provide rate limiting and routing, but they kick in after the model has already made an expensive decision. Identity-based permissions determine the very set of available tools in advance, at the agent and user level, rather than for a group as a whole. This not only saves tokens but also removes from the agent's view everything it shouldn't have access to.
It seems that Okta sees this mechanism as part of a broader strategy for secure agentic environments. How effective it will be in practice will become clear after pilot projects with clients, but the idea itself — removing the excess from the prompt before you pay for it — looks like a logical step in the fight against bloated AI agent contexts.
