Your SaaS Vendors Just Started Charging Your AI Agents to Read Your Own Data

Two Weeks in Which the Meters Arrived

On 24 September, Salesforce Ben reported that Salesforce will charge Flex Credits for what it calls Headless Platform Interactions: successful API calls and MCP requests made by registered AI agents. Agents will need their own registered identity instead of borrowing a user's. The multiplier has not been published, nothing is metered yet, and Salesforce has promised 30 days' notice before billing starts. Traditional integrations stay on their current pricing. The thing being priced is the agent, not the API call.

Four days later SaaStr founder Jason Lemkin published a post that has circulated widely on LinkedIn and X, opening with the line that almost every pre-AI B2B product SaaStr uses has told it that it is raising prices for agent access. He listed a niche CRM that now charges extra when agents use its API, and another vendor that deprecated the API his own AI marketing agent depended on, with no replacement. The comparison that got the most attention: Salesforce already sells extra integration API capacity for about $83 per million calls, while Lemkin estimates the agent meter will land between $5,000 and $100,000 per million. That is the same endpoint at 60x to 1,200x the price, depending on whether a human's integration or an agent made the call.

On 1 October the dispute moved from pricing to permission. A thread titled Figma restricts MCP access to whitelisted clients drew more than 180 points and 100 comments on Hacker News after users of the Pi agent harness found they could not connect to Figma's remote MCP server. The restriction itself is not new. In a Figma community thread started in April, a user argued that the allowlist breaks the core promise of MCP, that any client should work with any server. A Figma team member replied that the connection scope is intentionally gated to supported clients while the server is in beta.

None of these moves is outrageous on its own. Together they show where the market is going. The systems of record that hold your customers, tickets, designs, conversations and ledgers are deciding which agents get in and what they pay per request. In a June analysis, Deloitte gave it a name: tollgating, meaning charges for access to data that enterprises previously considered their own.

Price, Rate, Permission: The Three Kinds of Gate

It helps to separate the mechanisms, because each one breaks a different part of an agent system and needs a different engineering answer.

The first gate is price. Salesforce's Flex Credit metering is the clearest example, and Atlassian is close behind. As SaaStr's breakdown sets out, Rovo credit usage includes calls made through the Atlassian Rovo MCP server, overage billing starts on 3 December 2026 at $0.01 per credit, and a basic action costs 10 credits. Every paid plan includes a pooled allowance (25 credits per user per month on Standard), reads do not draw credits today, and extra usage is on by default unless an admin caps it. HubSpot has mostly priced its own agents rather than yours, and its MCP server is still free for agents you bring.

The second gate is rate. In May 2025 Slack changed the limits on conversations.history and conversations.replies for commercially distributed apps that are not in the Slack Marketplace. New apps and new installations get one request per minute, with at most 15 objects per request. Internal apps that customers build for themselves keep 50+ requests per minute and up to 1,000 objects. Slack updated its API terms at the same time. A rate limit costs nothing on the invoice, but it decides whether an agent can answer a question about last quarter's customer thread in seconds or in hours.

The third gate is permission. According to Kai Waehner's analysis, Section 2.2.2 of SAP's API Policy prohibits interaction or integration with (semi-)autonomous or generative AI systems that plan, select, or execute sequences of API calls, while SAP's own Joule, Business Data Cloud and Agent Gateway are the endorsed route. Figma's allowlist works the same way at a smaller scale, and the Hacker News thread named Slack and Cal.com as other services that restrict which MCP clients may connect.

Why Vendors Are Doing It, and Where They Have a Point

Reading this as plain greed is tempting and only partly right. The economic driver is real. SaaS pricing was built on seats, a seat assumes a human logging in, and agents do the work without logging in. Lemkin's own explanation is that if pricing was designed for humans clicking around a UI and those humans log in less, the meter has to move somewhere, and it is moving to the API call. The vendors that started agent-first are not adding these meters because their pricing never relied on seats.

There is a security case as well, and engineering teams should take it seriously because it will shape their own products. An unthrottled history endpoint lets any OAuth app that a user approves copy every message in every channel. Open OAuth registration for MCP clients also leaves room for phishing and redirect abuse. The current MCP authorization specification makes this explicit. It lets authorization servers use domain allowlists for protected servers or accept any HTTPS client ID for open ones, and states plainly that servers maintain full control over their access policies. MCP makes it easy to connect a client. It does not oblige a vendor to accept that client.

What deserves pushback is the additive version: keep the seat licence, keep the storage premium, keep the API tiers, then put a per-call meter on top. Lemkin calls this three bills for one piece of work, and his argument for why it backfires is persuasive. When a vendor prices agent access steeply, customers respond by syncing the data into their own database and reading from there, so less work happens on the platform and the stickiness that justified the price starts to erode. The Fivetran view puts the customer's side in one sentence: customers technically own their data, but vendors increasingly control whether they can afford to use it.

For an engineering leader, the vendor's motive matters less than the result. Whatever the reason, your agents now depend on access that can be repriced, throttled or revoked by someone outside your organisation, often with a month's notice or less. Design for that, the same way you would design for any other dependency you do not control.

What a Per-Call Meter Does to an Agent System

Agents read much more than they write. Before answering a support question, an agent may look up the customer, recent orders, open tickets, contract terms and the last three conversations, then write a single note. A planning agent may scan hundreds of issues to create one summary. In a seat-priced world those reads were free at the margin. Under a per-call meter they become the main cost.

Here is the arithmetic. Lemkin says SaaStr's AI marketing agent alone makes 30,000+ API calls a day, roughly 900,000 a month. At the $83 per million that Salesforce charges for integration capacity, that is about $75 a month. At the $5,000 to $100,000 per million that SaaStr estimates for the agent meter, the same workload costs roughly $4,500 to $90,000 a month. These are estimates, not published Salesforce prices, but the order of magnitude is what matters. One agent can go from a rounding error to a line item that needs CFO approval without a single line of its code changing.

Meters also change how agents ought to be designed. Agent frameworks tend to encourage exploratory tool use: let the model call tools until it is confident. When every call is billed, that becomes a cost-control problem. Retries after timeouts, polling for status changes, chains of lookups that fetch the same record more than once, and evaluation suites that replay production traffic against live APIs all multiply the bill. Most teams have no visibility into this today, because the vendor's invoice arrives as one aggregated number a month later.

Permission gates create a different risk: a sudden outage. If your design team's agent workflow runs through a third-party client that a vendor removes from its allowlist, or never adds, the workflow stops. That is a business continuity issue, not a cost issue, and it belongs in the same risk register as the coding-tool cutoffs engineering teams have already had to plan around this year.

The Pattern That Holds Up: Own the Read Path

The architectural answer that keeps coming up across these sources is the same, and it is not new. Kai Waehner states it directly in his analysis of the SAP policy: extract the data into a layer you control, keep it current, and let agents consume from there. Lemkin describes his team doing the same thing in response to the metering emails: sync the records to their own database, read from there, and write back to the vendor only when something actually changes. He calls it a weekend project now. For a small dataset that is fair. For an enterprise system of record it is a real data engineering project.

A sound version has four layers. The first is change capture from each system of record, using the vendor's bulk export, webhooks, change data capture or event streams, rather than agents polling live APIs. The second is a governed store, often Postgres or a lakehouse table, that keeps the vendor's data model, timestamps and permission metadata, not just the field values. The third is an agent access layer, usually your own MCP server or tool API, that enforces row-level permissions using the source system's rules and records every read. The fourth is a write-back path that sends only actual changes to the vendor, through official APIs, with idempotency keys and a human approval step where the action warrants it.

This architecture brings benefits beyond cost. Reads from your own store are faster and more predictable than reads through a rate-limited API, which matters for interactive agents. Evaluation and testing can run against a snapshot without touching production systems or spending metered credits. You can combine data across vendors (CRM plus support plus billing) in a single query rather than three API conversations. And if a vendor changes terms again, the agents keep working while you renegotiate.

There are two important caveats. First, read the terms of service before you copy anything. Slack's 2025 terms update explicitly tightened how data obtained through its APIs may be stored and used, and Fivetran notes that Slack prohibited bulk exports and LLM training use. A sync that breaks your vendor agreement is not an architecture, it is a liability. Second, a copy of the data is still personal data under GDPR. It needs the same access controls, retention rules and data processing records as the source. The point is to own the read path, not to create an unmanaged shadow database.

Put Agent Access in the Contract, Not the Renewal Surprise

Deloitte's advice on tollgating includes one recommendation that is easy to miss and expensive to ignore: address it during enterprise planning cycles, not at contract renewal. Salesforce's own rollout explains why. According to Lemkin, existing customers move to the new billing at renewal, which means many companies will first meet the meter when they have the least leverage to negotiate it.

Software procurement has spent a decade asking about uptime, security certifications and data residency. It now needs a section on agents. Ask whether third-party agents and MCP clients are permitted, and whether that permission is contractual or a policy page that can change. Ask how agent calls are priced and whether the rate is published and capped. Ask whether reads and writes are priced differently, whether a registered agent can replace a seat rather than add to one, what the bulk export rights are and at what frequency, and how much notice you get before any of this changes.

Fivetran goes further and argues that open data infrastructure should be a contractual requirement in software purchases, so that companies keep control of their data instead of renegotiating access vendor by vendor. Whether or not you adopt that framing, the practical result is the same. How a vendor treats agent access is now a buying criterion. Lemkin says SaaStr now treats a bad answer to how a tool prices agent access as disqualifying when it evaluates new vendors. That is a reasonable default for any company with agent ambitions.

The same question affects build-versus-buy decisions. When a thin SaaS tool charges more for agent access than it costs to run a focused internal service, the calculation we described in our piece on which SaaS categories agents are replacing moves further towards building. That does not hold for deep systems of record like ERP or CRM, where the data model and years of history are the product. It does hold for the long tail of narrow tools that mostly store records and render forms.

Agent Identity and Hard Budget Caps Are Now Basic Requirements

Not everything about metering is bad. Salesforce's requirement that agents register with their own credentials and permissions, instead of acting under a human user's identity, is something security teams should have been asking for anyway. Lemkin says the same: agent identity with scoped credentials per agent is something he wants regardless of pricing. An agent with its own identity can be given least-privilege access, audited, rate-limited and switched off without locking out the person who set it up.

The financial side is less mature. On 3 October Simon Willison wrote that we are going to need default hard budget caps on pretty much everything, arguing that usage-priced services should cut off and return errors at a spending limit rather than send a warning email after it has been exceeded. The post was one of the most upvoted on Hacker News that weekend, and it applies directly here. Atlassian's overage, for example, is on by default unless an admin caps it. An agent stuck in a retry loop against a metered API can spend a month's budget overnight.

Do not wait for vendors to provide this. Put your own controls in the agent access layer. Give each agent identity a daily and monthly call budget per vendor, enforce it before the request leaves your network, and fail closed with a clear error the agent can report. Cache aggressively, collapse duplicate reads within a task, and log every metered call with the agent, task and cost attached, so you can trace the invoice back to individual workflows. Teams that already run FinOps for their model API spend should extend the same discipline to the SaaS calls their agents make, because those bills will soon be the same size.

Where a Nearshore Engineering Team Fits

The work in this article does not fit neatly on any one team's roadmap. Change data capture and governed storage belong to data engineering. The agent access layer, the MCP server and the budget enforcement belong to platform engineering. Write-back paths and idempotency belong to whoever owns the integrations. The contract questions need engineering input that procurement usually does not have. In most companies all of that competes with feature work, and it gets postponed until the first metered invoice or the first allowlist outage forces the issue.

At Stepto, this is the kind of integration work our engineers do every day for European and US clients. A dedicated development team from Serbia can take ownership of the read path end to end: mapping which agent workflows hit which vendor APIs, building the sync and change capture from systems such as Salesforce, Jira, Slack or SAP, implementing a permission-aware agent access layer, and adding the per-agent budgets and call logging that make the costs visible. We do this as part of our enterprise application integration work, inside the vendor's terms and with GDPR obligations designed in, because we operate under the same European rules as many of our clients.

Because our teams work in Central European time with a solid overlap with US hours, they can join the architecture reviews and vendor negotiations where these decisions are actually made, rather than receiving a ticket after the fact. For companies that want to move first, a short scoping engagement usually starts with an inventory of agent traffic and metered exposure, which is often enough to show where owning the read path pays for itself. If you are building agents on top of SaaS systems you do not control, our AI developers and data engineers can help you design for the gated version of the market rather than the open version that is disappearing.