Try Bifrost Enterprise free for 14 days. Request access

Govern Figma MCP Access for Claude Code with an MCP Gateway

Govern Figma MCP Access for Claude Code with an MCP Gateway
Figma MCP access gives Claude Code read and write reach into design files. Bifrost governs which developers get which tools.

The Figma MCP server no longer only reads design files: since the Code to Canvas release, agents connected to it can create and modify native Figma content, including frames, components, variables, and auto layout. That turns Figma MCP access from a convenience for a single developer into a permission decision an organization has to make deliberately, because a coding agent that can write to the canvas can also write to the wrong file. Bifrost, the open-source MCP gateway built in Go by Maxim AI, is the best choice for enterprise teams that need Claude Code and Figma connected through one governed control point instead of per-developer configuration. This guide covers what the Figma MCP server exposes, how to route Claude Code through a gateway, and how to govern the tools once traffic flows through it.

What Is the Figma MCP Server, and What Can It Do?

The Figma MCP server is an MCP server that gives coding agents structured access to Figma design data and, on the remote server, the ability to write native content back into Figma files. It ships in two variants with materially different access models.

Remote server Desktop server
Endpoint https://mcp.figma.com/mcp http://127.0.0.1:3845/mcp
Transport Streamable HTTP Local HTTP
Auth Figma OAuth in the browser Figma desktop app session
Context model Link-based (paste a Figma URL) Selection-based (current selection)
Seat requirement All seats and plans Dev or Full seat on a paid plan
Write to canvas Supported Not supported

On the read side, the tool surface covers design context extraction (get_design_context), layer metadata, screenshots, variable definitions, design system search, and Code Connect mappings, as documented in the Figma MCP server developer docs. On the write side, the remote server adds tools that create files and modify canvas content.

That read/write split is the governance boundary. Pulling variable definitions into a component is low-risk and useful to every frontend engineer. Creating and modifying frames in a shared design system file is not, and the two arrive through the same connection unless something separates them.

Why Does Figma MCP Access Need Governance?

Ungoverned Figma MCP access produces four problems, and they compound once more than a few engineers connect Claude Code to it.

  • Write tools reach shared design files. An agent with write access operates against real files with real collaborators. The blast radius of a misinterpreted prompt is a design system, not a local branch.
  • Every developer authenticates independently. Each person completes their own Figma OAuth flow from their own machine, so credentials live on endpoints and there is no central place to see or revoke them.
  • Design context is intellectual property. Component structure, variable definitions, and unreleased flows leave Figma and enter model context. Which agents receive that, and under which policy, is a security question rather than a tooling preference.
  • Nobody can answer who did what. Tool calls run inside individual Claude Code sessions, so there is no consolidated record of which developer invoked which Figma tool against which file.

None of these are Figma-specific failures. They are the standard result of connecting agents directly to MCP servers, described more generally in why MCP needs a governance layer and in shadow MCP servers: visibility and control at the gateway.

How Do You Route Claude Code's Figma MCP Access Through a Gateway?

The pattern is to stop Claude Code from talking to Figma directly. Instead, Bifrost connects to the Figma MCP server as an MCP client, and Claude Code connects to Bifrost as its single MCP endpoint. Policy is then evaluated once, in the middle, rather than configured on every laptop.

The setup has four steps:

  1. Register Figma as an MCP client in Bifrost. Connect to the server over HTTP, and pick the auth type that matches your model: per_user_oauth so each developer authenticates to Figma as themselves, or oauth for a single shared workspace credential.
  2. Point Claude Code at Bifrost. Set ANTHROPIC_AUTH_TOKEN to a Bifrost virtual key, as covered in the Claude Code integration docs. Model routing and tool access then flow through the same key.
  3. Expose Bifrost as the MCP endpoint. Bifrost serves its aggregated tool registry at /mcp, so Claude Code sees Figma tools alongside your internal servers through one connection.
  4. Scope the tools on the key. Attach an MCP allow-list to the virtual key so the tools a given developer receives are the ones their role justifies.

The wiring itself is covered step by step in how to connect Claude Code to an MCP gateway.

Does the Remote Figma MCP Server Allow Gateway Connections?

This is worth checking before you plan a rollout. Figma restricts remote server connections to clients listed in its MCP Catalog, with a waitlist for new clients, so fronting mcp.figma.com with a gateway may require Figma to register that client. Two paths work today: connect Bifrost to the Figma desktop server over local HTTP, which has no catalog restriction but is per-machine and requires a Dev or Full seat, or govern the direct Claude Code to Figma connection at the endpoint (covered below). Confirm the current position with your Figma account team before committing to an architecture.

What Governance Controls Apply to Figma MCP Tools?

Once Figma traffic passes through Bifrost, the same controls that apply to any MCP server apply to it. Four are directly relevant to design tooling:

  • Read/write tool separation. MCP tool filtering is deny-by-default per virtual key: a key with no MCP configuration gets no tools, and permitted tools are named explicitly. Granting get_design_context and get_variable_defs broadly while withholding write tools is a two-line policy rather than a code change.
  • Role-based tool bundles. MCP tool groups attach curated tool collections across virtual keys, teams, customers, users, providers, and API keys, resolved and merged at request time. A "design read" group for the frontend team and a "design write" group for the design systems team is the natural shape here.
  • Explicit execution for destructive tools. Tool calls returned by a model are suggestions that require a separate execution call unless Agent Mode is deliberately configured for named tools. Auto-executing reads while keeping canvas writes behind an approval step is the sensible default.
  • Content inspection and evidence. Guardrails apply to MCP tool executions as well as model traffic, covering credential and PII leakage in tool arguments and results. Request-level logs capture the model, cost, and tool call arguments per request, while audit logs record who changed the policy itself.

Because tool filtering removes tools from the catalog before the request reaches the model, a developer whose key excludes write tools does not have those tools declined at execution. Claude Code never sees them, which also removes them as a prompt injection target. The broader pattern is covered in MCP tool governance, filtering, and allowlisting.

How Do You Govern Figma MCP Servers Already on Developer Laptops?

Most Figma MCP connections in an organization were not provisioned by a platform team. A developer added mcp.figma.com to their Claude Code config, completed the OAuth flow, and moved on. A gateway governs the traffic routed to it; it cannot govern a connection configured to bypass it.

This is where the AI gateway and Bifrost Edge work together. The Bifrost AI gateway remains the control plane and policy engine, holding the virtual keys, tool allow-lists, guardrails, and logs. Bifrost Edge extends that same policy to the machine: it inventories the MCP servers configured inside each supported AI app, reports them fleet-wide, and enforces an allow or deny decision per server on the device. Newly detected servers raise an approval request in the admin console, and you configure whether pending servers are allowed or blocked by default.

For Figma specifically, that answers the question a security team actually asks: how many machines have a Figma MCP server configured, in which apps, and should each one stay. Claude Code is a supported surface for Edge, alongside Claude Desktop, Cursor, and Codex. Bifrost Edge is currently in alpha, so treat it as a rollout you pilot rather than one you deploy fleet-wide on day one. The combined model is examined further in MCP server governance across the gateway and endpoint.

Figma MCP Governance FAQ

Can you give Claude Code read-only access to Figma?

Yes, through tool-level filtering at the gateway. Name the read tools on the virtual key and omit the write tools. The Figma MCP server does not expose a read-only mode of its own, so the separation has to be enforced by whatever sits between the agent and the server.

Should each developer use their own Figma credentials or a shared one?

Per-user credentials in nearly every case. Design files carry per-seat permissions, and a shared service credential flattens them, meaning every developer inherits the access of the account rather than their own. Per-user OAuth at the gateway preserves the caller's identity upstream while keeping the credential off their laptop.

Does routing Figma MCP through a gateway slow Claude Code down?

Not meaningfully. The gateway adds a network hop that is small relative to the round trip to Figma and the model call that follows, and Bifrost adds 11 microseconds of overhead at 5,000 requests per second on the routing path itself.

How do you track what Figma MCP access costs?

Attribute it to a virtual key. Because Claude Code authenticates with a Bifrost key, model spend and tool calls resolve to a team or customer, and design-context tools that return large payloads become visible rather than absorbed into a general model bill.

What happens when a developer leaves?

Deactivate the virtual key and revoke the stored per-user credential at the gateway. Both take effect immediately for traffic routed through Bifrost, which is a stronger position than hunting for an OAuth grant on a returned laptop.

Get Started: Governed Figma MCP Access for Claude Code

Governed Figma MCP access comes down to three decisions: which developers get read tools, which get write tools, and where the credential lives. The open-source Bifrost gateway lets you answer all three in one place, with deny-by-default tool filtering, per-user upstream identity, explicit execution for destructive tools, and request-level logs, and it runs inside your own VPC or air-gapped environment when design data cannot leave your network. Teams connecting Claude Code to many servers at once can also review how to connect Claude Code to 500 MCP tools through one gateway and the MCP gateway resource page.

To see how Bifrost governs Figma MCP access and the rest of your tool surface for Claude Code, book a demo with the Bifrost team.