The App Can Lock Your Agent Out Tomorrow

This week Figma changed who its MCP endpoint will talk to. Instead of letting any compatible client connect, it now restricts access to a whitelist of approved clients — and at least one widely-used agent tool found itself on the wrong side of that list. Nobody got hacked. Nothing broke. A vendor simply decided, from one week to the next, which software was allowed through the door.

Put that next to the rest of the week. Google quietly walked back a promise to keep Chromebooks updated for ten years. A long-running open-source company faced public questions about being "phased out of existence." Git's move to SHA-256 by default turned out to be more expensive than people expected. And a brand-new PDF, Identity Management for Agentic AI, landed on the front page because more teams are starting to ask the same question: who actually holds the keys to the tools my agents depend on?

None of these are stories about your code being wrong. They're stories about access you don't control.

Your agent's workflow is a chain of borrowed doors

Every useful agent is a chain of tool calls: it reads orders, updates a record, posts a message, checks a status — each step a request through someone else's front door. When you wire that chain together, you tend to think about the logic. You rarely think about the fact that every door in the chain has an owner who can change the lock without telling you.

MCP made this concrete. It promised a clean, standard way for agents to talk to tools, and for a while it looked like plumbing that would just work. Then a major platform restricted who gets to connect, and a popular client got excluded. That's not a bug. That's how a walled garden behaves once it has enough gravity: the endpoint is a policy lever, and policies change.

Three patterns show up over and over:

1. Silent revocation. Access you had today is gone tomorrow — not with an outage page, but with a changelog entry you'll never read. Your agent starts failing at 3 a.m. and nobody knows why.

2. Whitelist gravity. Once a platform can approve who connects, "approved" becomes a negotiation. Smaller clients, self-hosted setups, and cross-border operators with unusual stacks get shut out first.

3. Dependency that looks like a foundation. You built on it because it felt like infrastructure. But infrastructure has contracts and SLAs; a tool API usually has neither.

Why cross-border operators get hit first

If you run a store that spans jurisdictions, your automation is entirely third-party tool calls: a marketplace API, a payments API, a messaging API, a fulfillment API — often across different regions and legal regimes. You don't own any of those doors. And because your agents run unattended, across time zones, you're the least likely person to notice the door got re-keyed until revenue is already leaking.

A domestic team notices a broken integration during business hours and opens a ticket. A three-person cross-border operation notices it when a customer complains three days later — after the orders piled up.

Design for revocation, not for trust

You can't stop a platform from changing its mind. You can make sure a single decision on someone else's side can't take your operation offline:

• Treat every tool API as an SLA-less dependency. No contract, no guarantee, no notice. Plan accordingly, and stop calling it "infrastructure."
• Assume revocation is normal. For any critical path, know what happens when a specific vendor says no. If the answer is "everything stops," that's the risk — not the outage.
• Keep a fallback path warm. A secondary provider, a self-hosted option, or at least a documented manual path. Warm means tested, not theoretical.
• Scope agent credentials to the task. Least privilege isn't just security hygiene here — it means one revoked door doesn't take your whole agent's identity with it.
• Watch for access drift. Monitor who can still connect, not just whether things are up. Silent access changes are the ones that hurt.
• Don't gate revenue on a whitelist. If a platform's approval decides whether your agent can work, you've handed a stranger a kill switch to your income.

The uncomfortable takeaway

In the last three days this series has moved from identity, to permissions, to tokens. This is the layer underneath all of them: the doors themselves, and who owns the lock.

Your agent is only as capable as the access it currently has — and access is a lease, not a deed. Build as if any door could close tomorrow. Keep more than one way in and a way to work without it. The teams that survive platform changes aren't the ones who picked the right vendor. They're the ones who never let a single vendor hold the only key.

Assume the door closes. Know your other way in. Don't rent your last mile.

Part of a series on running a cross-border store without getting captured by it.