Okta Revolutionizes AI Cost Management with the MCP Protocol

Okta Innovates with the MCP Protocol to Reduce AI Agent Costs

Okta, a major player in identity management, has recently highlighted an innovative solution to reduce costs associated with artificial intelligence (AI) agents. By utilizing the Model Context Protocol (MCP), Okta aims to decrease the token costs incurred by AI agents. Each model call made by an AI agent includes various elements such as schemas, names, descriptions, and parameters for each tool exposed by an MCP server. This overhead, which the company refers to as the "tool tax," represents the tokens used when the model considers tools, even those it will never use.

Okta explains that these costs arise even before an agent attempts to call a tool. Thus, even if a request is subsequently rejected, the prompt tokens already consumed cannot be recovered. To address this issue, Okta proposes a control that filters the list of tools before it reaches the model, based on the permissions assigned to the agent's identity and the associated user.

Significant Reduction in Visible Tools Through Internal Modeling

In its internal analyses, Okta observed that certain authorization scenarios allowed for a reduction in tool visibility of over 90%. Although the company did not provide absolute figures in terms of tokens or dollar costs, it noted that the costs of tool schemas decreased in similar proportions.

The Prompt Overhead Related to MCP Tool Schemas

MCP servers have become essential for connecting AI agents to various tools and data. Okta cites examples of connections to Google Workspace, Slack, and internal MCP servers. An MCP server can expose a large number of tools, and each available tool is represented in the prompt at each turn.

This representation includes a schema, the tool's name, its description, and its parameters. According to Okta, the cost accumulates when many tools are exposed by a heavily used MCP server. Each active user incurs this prompt overhead every time their agent makes a model call, posing a problem in terms of both the number of tools and users.

The issue is also related to access control. An agent that sees tools outside its authorization scope may attempt to use them. Even if a control rejects the execution, the model has already received the tool's definition and used tokens to process it.

Filtering Tools Before Prompt Construction

Okta positions this capability within its "Secure Agent-Based Enterprise Plan," which requires organizations to identify their agents, their authorized connections, and their permitted actions.

Okta's approach reduces the access connection question from an entire MCP server to individual tools on that server. An administrator configures the tools that a particular identity can use in the Okta dashboard. Okta then returns the targeted set of tools instead of the complete server catalog.

The agent receives this shorter list in its prompt at each turn. Okta claims it rechecks the scope at runtime before an tool call is executed.

This design applies least privilege access at the tool level. The company states that an agent should not be aware of resources, databases, or tools it has not been expressly authorized to use. Removing unavailable tools from the prompt also eliminates their schema cost from the model call.

Okta does not describe any live client deployment in the post. Its evidence for the claimed reduction comes from internal modeling using Okta product data and public vendor documentation, without any customer data used.

Internal Modeling and Representative Roles

Okta modeled a single MCP client with access to a catalog of enterprise tools. It compared the number of tools visible to the model before and after identity-based targeting.

To estimate targeted exposure, the company mapped the tools from the Okta MCP server to the OAuth scopes that unlock them. It then defined representative user segments, including read-only help desk users and help desk operators.

Other segments included application administrators, brand and email administrators, and super administrators. Okta weighted each segment based on an assumed share of monthly traffic.

The company calculated the reduction in the number of tools as one minus the ratio of targeted tools to non-targeted tools. It stated that some scenarios eliminated more than 90% of visible tools. Its post indicates that the token cost of tool schemas follows the number of tools almost linearly, as each tool contributes its name, description, and parameter schema to each prompt.

Okta asserts that actual results vary based on the tool catalog, permission distribution, and selected model. The average schema size, request volume, and model pricing also affect the absolute costs in tokens and dollars.

Comparison Between Identity Rights and Gateway Controls

The post distinguishes identity-based targeting from gateway controls. Okta states that gateways can limit spending by key, team, or group, and can support routing and rate limiting.

A gateway can measure tokens entering and exiting a system, as well as dollars spent. Okta indicates that these controls can limit costs after a model decision has become expensive.

Identity rights provide a different entry point. Okta claims that user and agent rights can determine the tools available to a specific agent or the person behind that agent, rather than applying access information at the group level.

Okta's account presents the gateway as a control for what passes through it. The identity layer filters the entire set of available tools before those tools need to be measured.

Impact on Security and Exposure to MCP Attacks

The post links the same mechanism to security exposure. Okta asserts that removing tools from the view of an unauthorized identity also eliminates the actions that identity could undertake if compromised.

The proposed scope control operates at two points. The first occurs during the assembly of the tool list for the agent's prompt. The second occurs when the agent attempts to execute a tool call.

Okta describes the outcome as a smaller blast radius for a compromised identity. The remaining exposed tools determine the set of available actions for that identity. In the enterprise model, the prompt contains only tools associated with the authorized OAuth scopes of the identity.

For organizations evaluating MCP access, inventorying tools and mapping rights are the primary operational inputs. Okta's methodology maps the tools from the MCP server to the OAuth scopes that unlock them, then compares the complete tool catalog with the targeted catalog visible to each representative user segment.