Every SaaS Shipped an MCP Server. None of Them Shipped an Identity.
Ask an agent to clean up the duplicate rows in your CRM base. It is a boring task, it is exactly the kind of thing you bought an agent for, and the two things that go wrong are both structural.
The first is that it will be slow in a way that looks like a bug. Airtable's API allows five requests per second per base, record creation through its MCP server is capped at ten records per request, and going over the limit returns a 429 with a mandatory thirty-second penalty. Nothing about that is unreasonable for an integration that syncs your CRM every fifteen minutes. It is a strange budget to hand something that was told to touch two thousand rows right now.
The second is worse, and nobody notices it because nothing breaks. For the entire duration of that job, the agent holds every permission you hold. Airtable's own documentation is admirably direct about it:
Your MCP permissions mirror the same permission level(s) that you have been granted in Airtable.
You asked it to deduplicate one table. It can delete every base you can see.
Both of those come from the same place. In the last year essentially every serious SaaS product shipped an MCP server so that agents could act inside it. Not one of them shipped an agent — a principal with its own name, its own scope, and its own budget. The agent is wearing your badge and drinking from your straw, and those two facts are the entire problem.
The obvious answers, and why they are not answers
"Add retry with backoff." Every competent client already does. Backoff converts a failure into a delay, which is the correct handling and completely irrelevant to the second problem. No amount of retry logic makes the agent's blast radius smaller. And the delay is not free: at Airtable's five-per-second per-base ceiling, a bulk job is competing with your Zapier automations, your dashboard, and any other agent you happen to be running, because they are all drawing from the same bucket.
"Buy a bigger plan." This works, sort of, and it is instructive to look at what you actually buy. Shopify's GraphQL Admin API moves you from 100 points per second on a standard plan to 1,000 on Plus and 2,000 on enterprise. That is a real difference. It is also indivisible: you cannot allocate 200 of those points to an agent and keep the rest for your storefront, and you cannot say that this agent may spend points on reads but not on mutations. You upgraded the whole account's ceiling, which is a blunt instrument aimed at a targeting problem.
"Scope the OAuth grant." This is the right instinct, and it is where the gap is most visible. Notion's authorization model is page-level: during the OAuth flow a user selects which pages a connection may touch, and can revisit that selection later. Genuinely useful — it is more than most vendors offer. But the granularity runs along exactly one axis. There is no way to grant an integration read-only access, or to restrict it to a data type, or to say "this connection may create but never delete." You pick the pages. Everything the integration is capable of, it is capable of doing to those pages.
Notice that all three answers treat the agent as a slightly awkward integration. That is the actual mistake, and it is upstream of every symptom.
What these APIs were built for
The rate limits make complete sense once you see what they were designed around.
| rate budget | what it is scoped to | |
|---|---|---|
| Airtable | 5 req/s per base; 50 req/s per user or service account | the base, and the human's token |
| Notion | ~3 req/s average per connection, bursts allowed; workspace pool shared across connections, scaled by plan | the connection, and the workspace |
| Shopify | 100–2,000 points/s by plan, leaky bucket, single query capped at 1,000 points | the app, and the shop |
Three requests per second is a perfectly generous allowance for a piece of software that runs on a schedule. It is roughly what a nightly sync, a webhook consumer, or a dashboard needs, and the leaky-bucket shape that Shopify uses tells you the design intent precisely: absorb small bursts, punish sustained load, assume the caller is a steady background process.
Notion's payload caps say the same thing from another direction. A single request tops out at 1,000 blocks or 500KB, and a rich text field at 2,000 characters. Those are shapes fitted to a page being edited by a person, one page at a time.
None of that is wrong. It is a coherent design for the caller it anticipated: one application, installed once, doing a predictable amount of work forever. The security model matches — you trust an app the way you trust a vendor, once, at install time, and the trust does not vary by task because the app's job does not vary by task.
An agent violates every assumption in that sentence. It is not one application; you may be running six. Its work is not predictable; it is whatever you asked for this morning. And the trust you want to extend to it is entirely task-dependent — you would happily let it reorganise one table and you would not let it near billing, and those are the same agent five minutes apart.
What MCP did and did not change
MCP is a genuine advance and I do not want to undersell it. Before it, connecting an agent to a SaaS product meant someone writing and maintaining a bespoke tool wrapper per product. Now there is a protocol, Notion runs a hosted remote server, Airtable runs one at mcp.airtable.com, and Shopify has built commerce data access on the same standard. The integration problem is largely solved.
But look at what sits underneath. Airtable states it plainly:
MCP uses our public API under the hood and will count against any existing API rate limits.
MCP standardised the interface and inherited the substrate unchanged. The transport is new; the authentication is the same OAuth grant designed for installed apps, and the metering is the same bucket sized for a background sync. Notion's MCP documentation does not discuss rate limits or per-agent isolation at all — not as an omission, but because there is nothing separate to discuss. Shopify's positions MCP as a standard way to reach commerce data, and treats agents as a feature enabled through ordinary integration rather than as a new kind of caller.
So the door is new and the key is the old one. Every vendor built the door.
The gap, stated plainly
Line up what an agent needs against what is actually purchasable today.
| identity of its own | scope narrower than the human | budget of its own | revocable per task | |
|---|---|---|---|---|
| Airtable | ❌ inherits yours | ❌ mirrors your permission level | ❌ shares your API limits | ❌ |
| Notion | ❌ the connection is the principal | ⚠️ page-level only, no capability scoping | ❌ shares the workspace pool | ⚠️ per-connection, not per-task |
| Shopify | ❌ the app is the principal | ⚠️ app scopes, fixed at install | ❌ shares the shop's bucket | ❌ |
Four columns, and the strongest cell in the table is a partial. That uniformity is the interesting part: these are three well-run platforms with good API teams who all shipped agent access within about a year of each other, and all three shipped the same shape. When everyone converges on the same gap, it is rarely because they all missed it. It is because the missing piece is expensive and nobody wants to be first.
I have written before about the four problems that separate an agent runtime from an agent framework, and the fourth of them was identity and money — an agent having no way to say I am this agent, acting for this person, within these limits. The payment half of that problem has attracted standards, foundations and a great deal of money. This is the same problem on the access side, and it has attracted nothing, despite being the half that is already blocking ordinary work today.
What would fill it
The shape of the answer is not mysterious, because we have built it before for a different caller.
A principal per agent, not per human and not per app. A delegated credential, minted by the user, that the audit log can distinguish from both. This is the piece everything else hangs off, and it is close to what Cloudflare's virtual wallets do for spending: an account you own, sub-identities you delegate to individual agents, and policy evaluated at each hop.
Capability scoping, not just object scoping. Notion's page picker gets the object axis right and stops there. The missing axis is what may be done — read, create, update, delete as separately grantable verbs. Every database system solved this decades ago. It is not novel; it just was not needed when the caller was an app you vetted once.
A metered budget attached to that principal. Not a bigger shared bucket, a separate one, that the user sizes. This one has an appealing property the others do not: it is a product. Agent traffic is new revenue, arriving on infrastructure the vendor already runs, from a caller with a legitimate need for burst capacity that the existing plan tiers do not serve. Selling a token bucket to an agent is a better business than selling a plan upgrade to a human who only wanted one job to finish faster.
Task-scoped, expiring grants. The trust an agent needs is bounded in time and purpose. Everything above is static; this is the piece that makes the model actually match how agents are used, and it is the furthest from anything shipping.
Why it has not happened
Being honest about the difficulty, because the gap has a cause and it is not incompetence.
Every item above requires touching authentication and metering — the two subsystems where a mistake is a breach or an outage, in products where both are load-bearing for revenue. The upside is speculative and the downside is a headline. MCP was a comparatively safe thing to ship precisely because it changed the transport and left those two alone.
There is also a genuine chicken-and-egg problem. A per-agent principal is only useful if agent frameworks know how to request one, and frameworks will not implement a flow that one vendor supports. This needs either a standard or a platform large enough to impose one, which is exactly the dynamic that produced x402 and AP2 on the payments side — and payments had the advantage of a clean greenfield, whereas this has to be retrofitted into OAuth grants that millions of existing integrations depend on.
And the counter-argument deserves stating: perhaps this belongs in the MCP client rather than the server. Let the runtime hold the human's credential and enforce scope and rate limits locally. That works, it is what careful implementations do today, and it fails on the only question that matters — the vendor's audit log still shows you deleting those rows, and the vendor's rate limiter still counts against your bucket. Client-side policy is a seatbelt. It is not an identity.
I expect the first mover here to be a platform that already sells identity rather than one that sells the underlying tool, for the same reason payments got solved from the rails outward. But the thing worth watching is narrower and easier to check: the first vendor whose audit log can tell you which agent did it. Everything else follows from being able to answer that question, and today not one of them can.
Rate limits, permission semantics and MCP documentation checked against each vendor's own published docs on 22 August 2026. Limits and pricing on all three platforms change frequently; verify before relying on any number here.