When Vendors Start Choosing Which Agents Can Call Them

When Vendors Start Choosing Which Agents Can Call Them

You have an agent that does your design handoffs. It opens Figma, grabs the right frame, exports it, and drops it into your Slack thread. One morning it fails. The agent loaded the page, logged in, and then Figma said no. Not because your credentials were wrong. Because the agent itself was not on the list.

This is happening now. A Figma employee confirmed in September 2026 that their remote MCP server only accepts clients from a supported list, and a popular agent called Pi was not on it. The employee directed the user to a form to request future addition. David Soria Parra, who created the MCP protocol, responded publicly that he found the restriction sad and contrary to the open ecosystem he envisioned. Another commenter put it bluntly: why should the specific evaluation setup someone uses matter to the server? That is like making sure only Firefox can access your website.

The immediate problem is obvious. Your agent broke because a vendor decided your agent was the wrong brand. But the longer term problem is worse. If every SaaS vendor publishes an allowlist of approved agents, then agents no longer act on your behalf. They act on the vendor's terms. The vendor decides which capabilities you can automate, which agents get to see your data, and presumably which customers pay extra for access.

The browser is what the website sees

One project called dots takes a different approach. Its readme states a blunt thesis: every AI agent is a model and a browser, and you can swap the model with one flag. The browser is what the website sees. Dots ships a real Firefox engine patched in C++ so that the fingerprint is decided inside the engine, not painted over with JavaScript that a page can inspect. One identity per seed. No WebDriver flag, no DevTools protocol, no automation globals in the page. The pointer travels to what it clicks and keys are pressed one at a time, so every event the page receives is a trusted one.

The project describes itself as open source dots for the web: an AI agent with its own browser, one that does not get blocked. It was created on September 29, 2026, one day before the Figma exchange.

That timing is not a coincidence. The blocker came first. The bypass came the next day.

What the vendor sees matters more than what the agent is

Think about what Figma's restriction actually checks. It looks at the client identifier that the agent sends when connecting to the MCP server. The agent announces itself: "I am Pi", or "I am Claude Code", or "I am a custom tool you have never heard of." If the vendor has not added that identifier to a list, the connection is refused.

A vendor could say this is about security. They want to vet agents for proper authentication, rate limiting, safe parsing of responses. That is a real concern. But the mechanism is also a perfect gate for commercial control. The allowlist is a pricing lever. If you want your agent on it, you negotiate. If you are a customer who built a custom agent, you ask nicely. If the vendor decides to launch their own agent next quarter, your third party one gets deprioritized.

The dots approach sidesteps the entire question. It does not care what the agent calls itself because the server does not talk to the agent at all. It talks to a browser. The browser is a real browser. The website sees Firefox, not an automation tool. There is no client identifier to check. There is no MCP handshake to approve. The agent operates through the same interface a human would use, and the vendor has no technical basis to distinguish them.

This is not about bypassing security

Let me be clear about what I am not saying. I am not arguing that vendors should accept arbitrary automated traffic without safeguards. Rate limits, authentication, and idempotency are real requirements. A vendor is right to protect their API from abuse.

The question is whether the client identity is the right control point. If Figma wants to ensure that automated connections are authenticated and rate limited, it can do that with API keys and tokens. It does not need to inspect the agent name. If it wants to ensure that connections come from approved browser environments, it can check for specific security properties.

The allowlist is a business decision dressed as a technical one. Treat it accordingly.

What to do on Monday

If you run agents that touch vendor systems, you need to know which vendors use allowlists and which do not. That information is not published. You will find it when something breaks. But you can test it proactively. Set up a test agent with a non standard identifier and see what happens. If it gets blocked, you have your answer.

Two responses make sense. The first is to ask for inclusion on the allowlist. This works if you are a large customer or if the vendor is small enough to care. The second is to run your agents through a browser environment that the vendor cannot distinguish from a human. That is what dots does. It is not a hack. It is treating the browser as the boundary it always was.

The deeper lesson is about architectural trade-offs. If your agent relies on a vendor's MCP server, the vendor controls your uptime. If your agent relies on a browser that renders the vendor's web application, the vendor controls the design of that application but they cannot control how you access it. The trade is reliability versus integration depth. A direct API is faster and more structured. A browser is slower and more fragile. But the browser is also harder to block.

Pick the architecture that matches your tolerance for being told no.