Why AI agent access decisions must come before pricing

Agent-access pricing comes third

A customer can stop opening your application while still depending on your platform to get work done. For a software vendor, that change can strengthen the business or weaken its competitive position, depending on which asset it keeps under its control. So the first decision is what the business needs to retain: proprietary data may justify restricted access, while workflow execution may gain value from broader, governed access.

Model Context Protocol (MCP) makes this decision more urgent by giving AI agents a standard way to connect securely to enterprise software and data. Agents are software that can retrieve information and take actions; MCP servers provide their connections. Since its launch in late 2024, MCP has moved toward becoming the default standard, reaching more than 20,000 servers less than two years later.

Figure 1. “Model Context Protocol server growth signals its rise as the new default for agentic access to data.”
Sources: MCP.so (a server registry); Glama.ai; PulseMCP.

Wider adoption makes agent access commercially important, but each vendor still sets its own access policy. Before setting a price, a company needs to identify which data and workflows it should make available to software, then decide whether MCP is the right connection mechanism. Monetization comes third. The earlier decisions determine what the vendor retains and how customers will depend on it.

Protect the asset that differentiates the business

To set that boundary, start with the asset that gives customers a reason to depend on the company. LinkedIn treats its professional graph as its core competitive asset and tightly limits programmatic access, meaning access by software. ServiceNow takes a different approach: it makes governed workflows broadly available through MCP, charges for usage, and keeps operational data within its platform. Both companies have a commercial stake in these choices because access affects the assets and activity they can monetize.

For LinkedIn, restrictions protect the proprietary data behind its advantage. Easier access could let customers or competitors use the professional graph while relying less on LinkedIn’s interface. ServiceNow benefits when external agents use its workflows because it still supplies execution and governance, earns usage revenue, and retains operational data. So the strategic effect of access depends on what remains essential after the customer moves to another interface.

These examples give software leaders a test: identify the asset behind the advantage, then assess how exposure changes customer dependence on it. If proprietary data is central, examine the value of retaining control; if workflow orchestration, the coordination of work across steps, and governance are central, examine whether wider access strengthens those functions. Workflow access and permission to retrieve operational data need separate decisions. Each strategy can fit its business without establishing a universally better financial model.

Starting with pricing can obscure this assessment because it assumes easier access will benefit the business. For a vendor whose revenue depends on controlling proprietary data, wider availability may weaken the asset it sells. The assessment therefore needs to cover individual data categories: customer records, proprietary analytics, benchmark data, schemas, credentials, and workflow metadata. A schema describes how data is organized, while workflow metadata describes how work proceeds; each category has its own strategic value and risk.

Reviewing each category can also reveal where exposure would strengthen the business. Customers increasingly expect access to a provider’s data, and supplying it can make the provider a more deeply embedded part of their workflows. Their dependence can grow as they build processes around the available data and actions. Where customers are willing to pay, access creates a revenue opportunity around something they already value.

Greater dependence comes with operating costs and risks, however. Customers and competitors may bypass the provider’s interface, while read and write permissions increase vulnerability by allowing agents to retrieve and change information. More automated activity can raise infrastructure costs and telemetry costs, the expense of collecting and processing information about system activity. Data-sharing arrangements also bring regulatory considerations that belong alongside the commercial benefits in this assessment.

These consequences become harder to change once customers and partners build systems around the available data. Withdrawing access can disrupt their processes, so an integration offered today can create a lasting commitment. Before encouraging such dependencies, the vendor needs to decide which ones it wants to support. That decision sets the boundary within which an agent connection should operate.

MCP can reduce interface use while keeping the platform essential

Once the exposure boundary is clear, the next question is how agents should connect. Traditional application programming interfaces, or APIs, let software request data or actions, but developers must build integrations for each interface and its specific request points. MCP standardizes how agents find and use an application’s data and actions, reducing the need for a custom integration for every vendor. As adoption grows, this common approach lowers the cost of bringing enterprise software into agent workflows.

Lower connection costs can encourage adoption because customers have less integration work to do before their agents can use a platform. They can also finish tasks without opening the vendor’s application. This is interface bypass: the platform still performs the work while the customer interacts elsewhere. For a business built around governed execution, the interface can lose traffic while the platform remains central to operations.

The commercial risk changes when agents perform the work through another provider, a shift called platform displacement. Refusing MCP access can limit one route around the application interface, but it can also make the platform harder for agents to use. Traditional APIs remain available, though they still require integration work. A vendor must therefore weigh the benefits of easier participation against the risk that customers choose a more accessible alternative.

Restricted access can thus lead agents to route around a vendor, even when the restriction protects a valuable dataset. The assessment must weigh disintermediation, the loss of direct interaction with customers, against exclusion from agent ecosystems, the agents, platforms, and connections through which customers organize work. Reviewing data categories separately makes this trade-off more precise. A vendor can then consider governed workflow access while retaining control over valuable data.

External access also leaves room for a vendor to offer its own agent experience. A company can support MCP connections for agents built elsewhere while developing first-party agents, meaning agents built on its own platform. Customers then have both a vendor-built experience and access through other agents. The company can compete for the customer-facing interaction while supporting customers who choose a different agent.

Atlassian’s investment in Rovo illustrates the first-party side of this approach alongside its participation in external agent ecosystems. Atlassian has a commercial interest in retaining users through its own agent experience while keeping its platform available to agents developed elsewhere. The investments serve different purposes: external connections make the platform easier to use, while Rovo gives customers a reason to choose Atlassian’s agent. So continued relevance also depends on the quality and value of that first-party experience.

Price agent access against the whole revenue portfolio

With exposure and connection decisions made, pricing becomes a question of how agent access fits the business. Vendors are still experimenting. Bain, a consultancy with a commercial interest in advising companies on pricing and strategy, describes several approaches: usage- or outcome-based charges, fees for added capacity or higher rate limits, and charges for access itself.

Bain’s approximate proportions describe charging approaches rather than mutually exclusive market shares. Usage pricing charges for activity, while outcome pricing charges for the result delivered. Capacity fees let customers use more of a service, and higher rate limits increase the number of requests allowed within a period. With an access fee, the availability of the connection becomes part of what the customer buys.

Beyond these approaches, most vendors apply similar pricing principles to MCP and traditional APIs, though many, particularly AI-native companies whose businesses are built around AI, vary charges by the action performed. What an agent does therefore matters to the price. A vendor can charge for access, activity, results, added capacity, higher request limits, or different action types. The choice should reflect customer use and its effect on the existing business.

That effect can be unfavorable even when the access offer attracts customers. Consider a vendor that sells licenses for individual users, commonly called seat licenses, and introduces inexpensive MCP access. Customers could shift work from licensed users to agents, cutting seat revenue while increasing programmatic activity. Because standardized connections make agent workflows easier to adopt, they can accelerate both platform use and this transfer of work.

The resulting revenue shift needs to be assessed across the vendor’s portfolio. More access revenue may come with lower spending on other products, so adoption alone does not establish commercial success. Agent-access pricing must account for what customers continue to buy and how their purchasing behavior changes. What matters is the effect on the whole business.

Who pays also affects that outcome because the payment arrangement shapes the customer relationship. Charging end customers maintains a direct commercial connection with the organization using the platform. Charging developers or ecosystem partners can reduce friction for those customers, but it may weaken the vendor’s ownership of the relationship over time. Choosing the payer therefore determines both where the charge sits and who manages the ongoing commercial connection.

Once developers have integrated with an interface, changing charges or restrictions also changes the economics of systems customers already rely on. Such changes have repeatedly triggered customer backlash and, in some cases, regulatory scrutiny. This concern is separate from the regulatory issues associated with sharing particular data categories. It arises when a vendor revises established access arrangements after others have built around them.

Established dependencies also affect how easily access and pricing decisions can be reversed. Exposed data, built integrations, and the vendor’s role in agent workflows can be difficult to withdraw, while pricing can evolve as the market matures. Customer reactions still constrain how quickly prices can change. A necessary change to access or pricing is therefore generally better introduced through a phased transition that gives customers and developers time to adapt their systems and processes.

Key takeaways for decision-makers

• Set access policy before pricing: Software vendors need to decide which data and workflows to expose, then choose the connection mechanism and commercial model. These decisions shape customer dependence and create commitments that become harder to reverse once customers build integrations.
• Protect the asset behind customer dependence: Proprietary data may justify restrictions, while governed workflow execution may gain value from broader access. Product and security teams need separate policies for workflow actions and individual data categories, accounting for competitive value, operating costs, and regulatory risk.
• Keep the platform essential as interfaces change: MCP can help agents use a platform even when customers stop opening its application. Platform owners need to weigh that opportunity against the risk that restricted access sends customers to more accessible alternatives; first-party agents offer another way to retain direct interaction.
• Price against the whole revenue portfolio: Finance and product teams need to assess whether agent-access revenue offsets changes in seat licenses and other purchases. The choice of payer also shapes the customer relationship, while phased pricing changes give customers and developers time to adapt established integrations.