Okta: Identity-Based MCP Tool Filtering Could Cut AI Agent Token Costs by Over 90%

AI agents are becoming more powerful as they gain access to external applications, databases, and enterprise tools through the Model Context Protocol or MCP.

But there is a hidden cost every time an AI agent talks to a model.

Okta calls it the “tool tax.”

According to the identity and access management company, limiting the MCP tools visible to an AI agent based on the identity and permissions of the user could dramatically reduce unnecessary token consumption. In some of Okta's internal modelling scenarios, the number of tools presented to the AI model dropped by more than 90 percent.

The company says the cost of sending tool schemas to the model declined by roughly the same proportion.

What is the MCP “tool tax”?

An MCP server can connect an AI agent to services such as Google Workspace, Slack, enterprise databases, internal applications, and other systems.

But before the AI agent can decide which tool to use, the model may receive information about every tool exposed by the MCP server.

This can include:

• The tool name
• Tool description
• Available parameters
• Input schema
• Other instructions required to call the tool

All of that information consumes tokens.

And it can happen every time the AI agent makes a model call.

The problem becomes bigger when an MCP server exposes dozens or hundreds of tools.

Even worse, the model may be receiving information about tools that the user or AI agent is not actually authorised to use.

Okta describes those unnecessary tokens as the tool tax.

Blocking a tool later does not recover the tokens

Traditional security controls can reject an unauthorised tool call when an AI agent attempts to execute it.

But according to Okta, there is still a cost.

By that point, the model has already received the tool description and schema inside its prompt.

The tokens have already been consumed.

Okta's proposed approach moves the access-control decision earlier.

Instead of showing the AI model every available MCP tool, the system first checks the permissions associated with the AI agent and the person using it.

Only authorised tools are then included in the model's prompt.

Show the AI only the tools it is allowed to use

Under Okta's model, administrators can define which MCP tools a particular identity is permitted to access.

Instead of giving an AI agent access to the entire MCP server catalogue, access can be narrowed down to individual tools.

For example, a helpdesk employee may only need tools for viewing user information or resetting passwords.

An application administrator may require a completely different tool set.

A super administrator could receive broader access.

The AI model would therefore see only the tools relevant to that particular identity.

This results in a much smaller prompt.

And a smaller prompt can mean fewer tokens and potentially lower inference costs.

More than 90% fewer visible tools in some scenarios

Okta tested the concept using internal modelling based on its product information and publicly available vendor documentation.

The company mapped MCP tools to the OAuth scopes required to access them.

It then created representative user categories, including:

• Helpdesk read-only users
• Helpdesk operators
• Application administrators
• Brand and email administrators
• Super administrators

Okta compared the complete MCP tool catalogue with the smaller list of tools that each type of user would actually be authorised to access.

In some scenarios, identity-based filtering eliminated more than 90 percent of the tools presented to the AI model.

Okta said token consumption related to tool schemas decreased by approximately the same percentage because each tool contributes additional names, descriptions, parameters, and schemas to the prompt.

The company did not disclose specific dollar savings or absolute token figures.

Actual savings would depend on several factors, including the number of available tools, average schema size, AI model being used, API pricing, request volume, and permission structure of the organisation.

Security and AI cost control meet at the identity layer

The idea is not only about saving tokens.

It also follows the cybersecurity principle of least privilege.

An AI agent should only have access to the resources and actions required to perform its assigned task.

If an agent does not have permission to use a particular database, application, or tool, Okta argues that the model should ideally never see that tool in the first place.

This creates two potential benefits.

First, fewer tool schemas are placed inside the prompt, reducing token overhead.

Second, the number of actions available to a compromised AI agent or user identity becomes smaller.

Okta proposes checking permission at two stages:

Before prompt construction:
Only authorised tools are included in the tool list sent to the model.

Before execution:
Permissions are checked again when the AI agent actually attempts to call a tool.

This provides another layer of protection before an action is executed.

Identity management could become critical infrastructure for AI agents

As enterprises deploy more autonomous AI systems, identity may become increasingly important.

Companies are no longer managing access only for human employees.

They may soon be managing identities and permissions for:

• Employees
• AI assistants
• Autonomous AI agents
• Agent-to-agent systems
• Enterprise applications
• MCP servers
• Databases and APIs

This means the question is no longer simply:

“Can this AI connect to this MCP server?”

The more important question may become:

“Which specific tools inside this MCP server should this AI agent be allowed to see and use?”

Identity controls versus AI gateways

Okta also distinguishes its approach from AI gateway systems.

An AI gateway can monitor tokens, enforce spending limits, apply rate limits, route model requests, and measure AI usage.

Identity-based controls solve a different problem.

Instead of limiting spending after AI requests occur, identity entitlements can determine which tools are exposed to the model before the request is constructed.

Paul Webber, Principal Cybersecurity Industry Analyst at Software Analyst Cyber Research, described identity governance as a potentially more granular method of controlling agent costs because it can use the same entitlement information already governing enterprise security.

In practical terms, the two technologies could complement each other.

An AI gateway can control how much an AI system consumes.

An identity layer can control what the AI system is allowed to access in the first place.

Why this matters for AI development

MCP is quickly becoming an important architecture for connecting large language models and AI agents with real-world tools.

As organisations connect more applications to their AI agents, MCP servers could eventually contain hundreds or even thousands of available actions.

Sending every tool definition to every agent during every interaction would be inefficient.

Identity-scoped MCP access offers a possible solution.

Instead of asking the AI model to examine everything and decide what it needs, the infrastructure surrounding the model can narrow the choices first.

The result could be:

Fewer tools.
Smaller prompts.
Lower token consumption.
Lower AI operating costs.
Stronger access control.
And a smaller cybersecurity attack surface.