Three of the largest enterprise SaaS vendors on the planet just made the same move, and it tells you exactly which decade their internal product roadmaps live in.
Salesforce locked down agent access first. Slack followed a few weeks later. SAP just announced its own version. The framing in each case was a polite mix of security, compliance, reasonable scope, and protecting the platform. The substance of each move was the same: an enterprise was building agentic workflows against the data they were already paying SaaS license fees to access, and the vendor decided to make that harder.
Customers are not buying the framing.
The complaint shows up in every forum and every customer Slack you can find:
“This is our data. We’re already paying you exorbitant rates to use it. And now you want to charge us again — or shut it off — because we want an agent to read it?”
The complaint is correct. The lock-down is not a security move. It is a product failure.
The vendor that has an API product does not panic when agent traffic arrives
There are two ways for a SaaS vendor to wake up one morning and discover that AI agents are starting to call its APIs at scale.
The first way is to look at the traffic, see a new and rapidly-growing class of consumer with predictable patterns, and route it into your existing API product surface. You meter it. You price it. You attach it to a new SKU. You publish an MCP server and an agent-skills bundle alongside the existing SDKs. You give your customers a clean way to declare which agents are allowed to do what. You treat the new traffic as a new revenue stream, because that is what it is. Stripe handled it this way. Twilio handled it this way. The integration platforms that have been API-first since they were founded — Postman, Workato, Tray, Bruno — handled it this way.
The second way is to look at the traffic, panic, and lock the door.
The vendors choosing door number two are not behind because they did not see the wave coming. They are behind because they never built an API product to begin with. They built a SaaS product, and the API was always a side door — a backup interface for the integration partners who needed it, an admin surface for the IT teams who insisted on it. There was no metering. There was no pricing. There was no tiered access model. There was no consumer-aware quota system. The API was infrastructure, not product.
When the new consumer arrives — and the new consumer is an agent that wants to read the same data ten thousand times a day instead of a human that wanted to read it twice — there is no machinery to route them through. There is no SKU to charge them under. There is no way for the customer to declare which agents are allowed. So the only available move is to lock the door, blame security, and buy six months to figure out what to do next.
This is the same response, beat for beat, as the same vendors’ response to the cloud fifteen years ago. Not safe. Not enterprise-ready. Not where serious workloads belong. It bought them six months then, too. It cost them a decade afterward.
Fix the plumbing — and let your customers fix the business problems
A friend reframed this for me recently, and the reframe is the kind of thing I want to put on a wall.
Fix the plumbing. Let us fix the business problems.
It is the politest possible way to say: the customer’s job is not to compensate for your missing API product. The customer pays you license fees in exchange for the platform doing what platforms are supposed to do — providing safe, governed, metered access to the data the customer owns. If you cannot do that for agent traffic, the gap is in your product, not in the customer’s appetite.
The interesting thing is that the playbook for fixing the plumbing is not a mystery. It has been written down many times. A real API product has:
- Metered access. Per-consumer, per-operation, per-environment. So you actually know what is calling what.
- Tiered pricing. Trial, developer, production. So an agent-heavy workload sits in a different price band than a human-heavy one.
- Identity-aware consumer policies. So a customer can say “this agent, owned by my marketing team, can read these objects but not write to those.”
- Allow-listed scopes per consumer. So the customer chooses what an agent can reach, not the vendor.
- A capability surface. So the consumer — agent or human — gets a clean, documented, business-meaningful interface, not a raw resource graph.
- An MCP server alongside the SDKs. Because that is the consumer surface that just arrived, and the vendor that ships it first will define the shape of how their customers’ agents work with their platform forever.
None of this is theoretical. The pieces have existed for a decade. Some of the vendors locking the door today even sell an API management product to their own customers. The reason they cannot use it on themselves is organizational, not technical. The API management team and the SaaS product team have never talked.
The honest read on the lock-down moves
Every wave of platform change creates a moment where the vendors who built for the previous wave have to decide whether to spend the next year building for the new one, or whether to spend the next year defending the old one. Salesforce, Slack, and SAP all picked defense. That is a tell.
It is not a tell about security. It is not a tell about agent risk. It is a tell about which way the product roadmap is pointed.
A vendor with a real API product would have looked at the agent traffic and said: finally, a reason to roll out the consumer-aware pricing model we have been talking about for three years. A vendor without one looked at the same traffic and said: we need to slow this down until we figure out what to do with it.
The customer can tell the difference, even if the press release cannot.
What enterprises should do about it
You are not going to fix your incumbents’ API product strategy. They are going to fix it themselves, or they are going to be replaced by something that did. In the meantime, what you can do is stop architecting your AI initiatives on the assumption that the vendor’s API will be available at the same terms forever.
Run your governance, your capability declarations, your consumption-side metering, and your access policies in your own infrastructure — on top of whatever the vendor lets you reach this quarter. That way, when the vendor moves a goalpost, you move with it instead of being moved. That is the bet Naftiko is built around. It is also the bet every enterprise should be making about every SaaS dependency in their stack right now.
Lock the door, or meter the door. Those are the two responses available to a SaaS vendor when agent traffic arrives. The vendors who picked the lock are telling you exactly which way their product roadmap is going to keep pointing. Plan accordingly.
