Runlayer Joins Anthropic, OpenAI, & Google as AAIF Founding Member ->
Jan 30, 2026
 • 
Tal Peretz

MCP Apps highlight the power of protocol governance

Yesterday, Anthropic launched MCP Apps. Tools can now return interactive UIs that render directly in the conversation through dashboards, forms, visualizations, and multi-step workflows.

Given that this introduces an entirely new UI surface, security teams might worry that it creates a new attack vector. That concern is reasonable, but it’s rooted in the wrong mental model. If teams already have the correct MCP security practices (e.g. using middleware like Runlayer), then they are covered from the start.

What Are MCP Apps?

MCP apps are not a new application framework or execution environment. It is an official extension, and the first of its kind. To deliver MCP Apps, Anthropic built on the existing MCP-UI community and partnered with OpenAI. This week itself, Claude, ChatGPT, Goose, JetBrains, Google DeepMind and VS Code have all announced support for MCP Apps.

At a high level, MCP Apps let tools return HTML and JavaScript bundles that render rich, interactive interfaces directly inside Claude. This allows tools from partners like Asana, Figma, Slack, and Box to surface dashboards, forms, and other visual interfaces inline, so users can explore data and take action without leaving the app.

Additionally, MCP Apps aren't just static HTML. They're bidirectional. The @modelcontextprotocol/ext-apps SDK gives UI components a set of hooks to communicate back to the host and server (e.g. app.ontoolresult, app.callServerTool() , and app.updateModelContext()). UIs can open links in the user's browser and log events for debugging. All of this happens over JSON-RPC via postMessage, which means every interaction can be traced.

Why This Isn’t a New Security Risk

MCP Apps feel novel simply because of how the resources are presented. However, the mechanics are actually quite similar to what we’re used to. Here’s what happens when an MCP server is extended to support MCP Apps:

  • MCP servers register a tool with _meta.ui.resourceUri pointing to a UI resource
  • The UI is an HTML/JS bundle served via resources/read with a special scheme (i.e. ui://charts/interactive)
  • User interactions within the UI trigger normal tool calls back to the same MCP server

What’s important to note here is that MCP Apps don’t introduce a new execution path. Partners like Asana, Figma, Slack, and Box run their own MCP servers (e.g. mcp.asana.com/sse and mcp.figma.com/mcp), which communicate with Claude over the same MCP protocol and are treated like any other third-party integration.

This means that Runlayer customers are already secure. All tool definitions (including _meta.ui.resourceUri), tool calls from the UI widget, resource fetches for HTML/JS bundles, OAuth tokens, and auth headers are intercepted by Runlayer. MCP Apps didn't change what flows through the protocol; it just shifted the output from plaintext to HTML/JS.

Why Sandboxed iFrames?

MCP Apps render UI from third-party servers in sandboxed iframes with tightly restricted permissions. The UI does not run inside the host application, and therefore, has no direct access to the host's internal APIs.

This is great design. The underlying data remains governed by MCP itself, and the interactive surface doesn’t give access to the host application (e.g. nefarious Javascript cannot “hack” Claude).

Protocol-Level Governance

The immediate security guarantees of MCP Apps is a great demonstration of protocol-level governance. Just because MCP upgraded its output optionality doesn’t mean that the entire ecosystem needs to reinvent security.

For Runlayer customers, they can still use MCP Apps today without worrying about new types of attacks. All of the existing mechanisms (e.g. tool calls, resource fetches) pass through the same controls that are already configured.

What MCP Apps Enable

MCP Apps are most powerful in workflows where users benefit from seeing and navigating structures visually. Operations like filtering data or reviewing documents are inherently more difficult to perform through a text-based interface. MCP Apps address this by allowing MCP tools to become interactive. For example:

  • Data Exploration. A sales analytics tool returns an interactive dashboard. Users filter by region, drill down into accounts, and export reports without translating each action into another prompt.
  • Configuration Tooling. A deployment tool presents dependent form fields. When a user selects “production,” additional security options appear; selecting “staging” updates the defaults directly in the UI.
  • Design UI. A design tool (such as Figma) returns a visual mock-up of a new application view. Users use the prototyping features to walk through the app’s layout (instead of interpreting static screenshots).
  • Document review. A contract analysis tool displays a PDF with highlighted clauses. Users approve or flag sections inline, and those decisions are immediately reflected in the model’s context.
  • Live Metrics. Because MCP Apps support bidirectional hooks, tools can surface real-time data such as live metrics, with updates flowing between the UI and the MCP server.

These interactions reflect the shift we are seeing with MCP apps. Instead of describing what to do, users can simply do it.

What We’re Building Next

Today, Runlayer customers already have full security coverage for MCP apps. Our next steps focus on making that coverage more visible and configurable. Here are some of the enhancements we are working on:

  • Visibility. We’ll make it easy to detect _meta.ui.resourceUri in tool definitions. Servers will be flagged  as "MCP App enabled" in the admin dashboard and UI resource fetches will be logged separately in audit logs.
  • Policy Enforcement. We'll allow IT teams to toggle on/off MCP Apps in admin settings. We’ll also allow users to whitelist specific domains for interactive content (e.g. allow mcp.figma.com but block unknown servers from serving UIs).
  • Content scanning. We'll scan HTML/JS bundles for suspicious patterns before they reach the client. We’ll look for patterns matching for eval(), inline scripts, and external resource loading. While these attack vectors will fall flat given the iframe structure, they can still signal an attempted attack or serve as an early indicator of downstream risks (e.g. a phishing attack).

A Closing Thought

MCP Apps is a meaningful step for the protocol. Interactive UIs inside conversations create better workflows for users and richer context for models.

For security teams, the main takeaway is simple. This is still MCP. The same visibility and control you need for any MCP server applies here. If you're already governing MCP at the protocol layer, you're covered.

Jan 30, 2026
 • 
Tal Peretz
Read more