News · 2026-10-02

Figma’s remote MCP gate separates user permission from client approval

Figma requires approved clients for its hosted Model Context Protocol server, making application review a separate boundary from a user’s file permissions. The policy drew renewed attention alongside Pi 1.0, but it predates that release, and the specific allegation that Figma rejected Pi could not be fully checked against the original employee statement.

Key facts

• Figma’s current catalog lists supported clients with differing remote, desktop, read, and write access.
• A staff reply described a pause on new public clients on August 27, 2026.
• Remote access uses OAuth and an approved-client connection scope.
• Primary sources are the MCP catalog and Figma staff’s forum explanation.

A user can own a file and still find that a preferred agent cannot connect to the service holding it. That is the disagreement at the center of this story. The tool protocol standardizes communication, while the company operating the server continues to decide which applications may handle delegated access.

Figma documents two server routes in its official setup guide: a remote server and a server through the desktop application. The catalog distinguishes which route a client supports and which capabilities are available. Some listed clients have only local, read-only access. The remote route supports broader functionality, including writing native content to the canvas during the beta.

The security mechanism has two layers. User permissions determine the files available to an account. Client approval determines which application may exercise that account’s access through the hosted integration. A useful analogy is a building badge and an approved delivery company: the badge establishes which rooms a person may enter, while the delivery-company policy decides who can carry goods on that person’s behalf.

Figma staff says review “adds a layer of confidence” when people adopt new applications and workflows. The forum explanation compares it with plugin and widget review. It also describes an approved-client connection scope, with personal access tokens and service accounts unsupported for that remote path. Private internal gateways are treated separately and are reserved for Organization or Enterprise plans.

Those are documented access controls, not proof that an unapproved application is dangerous. Nor does the public record establish that a security incident prompted the gate. Review can provide a place to check application behavior and accountability, but the sources reviewed do not publish comparative findings about approved and unapproved clients or a measured reduction in abuse.

The timing matters. Figma’s earlier policy announcement already described reviewing public integrations. Its August 27 forum reply said it had paused adding new public clients while building a scalable foundation, with no self-service registration. The October catalog contains a changing roster, so the August statement establishes a pause then, rather than proving the pause remained unchanged on October 2.

The Hacker News thread about Pi links to a Figma employee’s social post. That original post was inaccessible in the dossier’s verification. Pi’s absence from the official catalog is observable; absence alone does not establish the details of an application, rejection, or private negotiation. The broader client gate is verified, while the Pi-specific exclusion remains partly verified.

Practitioner objections go beyond Pi. Figma’s own forum includes a user reporting that a cloud variant of Cursor was rejected even though Cursor itself was approved. Other users question why their preferred client requires another approval step when they already control access to their files. These are firsthand complaints about user experience, not evidence that permission checks were bypassed.

The strongest case for review is that the application receiving a user’s access deserves scrutiny as a distinct actor. The strongest counter-argument is that centralized approval can restrict interoperability and make switching or building clients harder. Both positions recognize the same architectural fact: an open communication protocol does not create a right to use every server that implements it.

For developers, the practical issue is whether required tools remain reachable from the intended agent environment. Our lessons on scoped credentials and tool use explain why identity, authority, and connectivity must be checked separately. The existing story on MCP authentication changes provides the wider context.

Figma’s catalog and staff explanations support a consequential access-control story. They do not support claims that Pi caused a new restriction, that every unlisted client is technically blocked in every mode, or that approved clients override users’ file permissions. Keeping those boundaries visible is necessary to judge the policy fairly.

Primary source, verified: read the paper →

Ground Truth. (2026, October 2). Figma’s remote MCP gate separates user permission from client approval. Ground Truth. https://groundtruth.day/news/figma-remote-mcp-client-review-boundary.html

@misc{groundtruth:figma-remote-mcp-client-review-boundary,
  title  = {Figma’s remote MCP gate separates user permission from client approval},
  author = {{Ground Truth}},
  year   = {2026},
  month  = {oct},
  url    = {https://groundtruth.day/news/figma-remote-mcp-client-review-boundary.html}
}

Topics: cybersecurity · ai-security · authentication · access-control · agents · mcp