TL;DR: MCP-UI extends the Model Context Protocol by letting MCP servers return interactive UI components that clients can render in sandboxed iframes or remote DOM, reducing text-only friction for complex tasks and supporting adoption across commerce and workflow tooling, according to WorkOS. The security question is no longer whether agents can talk to tools, but how their interfaces preserve control, trust, and user safety at runtime.
At a glance
What this is: MCP-UI is a framework for rendering interactive user interfaces inside AI agent conversations, with the key finding that richer interaction can improve complex workflows without removing agent-mediated control.
Why it matters: It matters because IAM teams now have to govern not just which tools an AI system can reach, but how interactive components, rendering paths, and delegated actions alter trust boundaries across NHI, autonomous, and human workflows.
👉 Read WorkOS's recap of MCP-UI and the MCP Night 2.0 demo
Context
MCP-UI sits at the junction of AI agent orchestration, workload identity, and user interaction design. The core issue is not prettier chat surfaces, but the governance gap that appears when an agent can present, render, and mediate interactive actions inside a conversation.
For IAM and NHI practitioners, that means the control problem expands from API access alone to the full path between agent intent, tool invocation, and user-visible interaction. When interfaces become part of the execution path, the security boundary must account for rendering context, event handling, and how much authority the agent retains over the final action.
Key questions
Q: How should security teams govern interactive UI inside AI agent workflows?
A: Security teams should govern interactive UI as part of the agent’s execution path, not as a separate front end. That means approving which components can render, validating which intents they may emit, and logging the downstream action chain. If the UI can change state, it needs the same policy discipline as the underlying tool call.
Q: What breaks when agent UIs can trigger actions directly?
A: When UI events can trigger actions directly, the agent loses its role as a policy gate and the interface becomes an uncontrolled execution path. That increases the risk of hidden privilege escalation, untraceable state changes, and confusing accountability. The control failure is not visual complexity, but bypass of the mediated decision point.
Q: How do sandboxed iframes change the risk of MCP interfaces?
A: Sandboxed iframes reduce the chance that remote UI code can reach the host environment, but they do not remove trust in the content being rendered. The client still decides what to display, and the agent still decides what to act on. Teams should therefore govern rendering permissions, not just browser isolation.
Q: What should IAM teams review before adopting MCP-UI at scale?
A: IAM teams should review event logging, confirmation boundaries, data exposure rules, and the identity that signs off on each intent. If a workflow can alter orders, permissions, or records, the approval path must remain explicit and auditable. Scalable adoption depends on proving who authorised each state change.
Technical breakdown
How MCP-UI renders interactive components through MCP resources
MCP-UI lets an MCP server package interactive user-interface elements as MCP Resources, which the client may render in one of three ways: inline HTML in sandboxed iframes, remote resources in sandboxed iframes, or Remote DOM for client-side rendering. The important architectural point is that the interface is delivered as data through the protocol rather than as a free-form browser extension. That keeps the model aligned with MCP’s tool-and-resource pattern while allowing richer experiences than text alone. The agent still sits in the middle of the interaction, but the UI becomes part of the protocol surface rather than an out-of-band front end.
Practical implication: Treat rendered MCP resources as part of the security boundary and review how the client sanitises, sandboxes, and logs them.
Why intent-based messaging matters for agent control
The Monday.com example shows a crucial pattern: a click inside the embedded component does not directly mutate state. Instead, the component emits intents such as add to cart or view details, and the agent interprets them before action proceeds. That preserves agent mediation while avoiding direct browser-to-system writes. In identity terms, this is a delegated action model, not unfettered client execution. The governance question is therefore not whether the UI is interactive, but whether each interaction still passes through a controllable authorisation decision and an auditable execution path.
Practical implication: Map every UI event to an explicit intent-handling policy and verify that no component can bypass the agent-mediated approval path.
Sandboxed rendering narrows, but does not remove, exposure
Sandboxed iframes and client-rendered Remote DOM reduce the blast radius of remote UI code, but they do not eliminate the trust problem. The server still controls the content being rendered, the client still interprets it, and the agent still mediates the workflow. That creates a three-party trust chain across protocol, rendering engine, and identity authority. For security teams, the hard part is not only code execution risk. It is deciding which actions, data fields, and permissions remain acceptable once a conversational interface can dynamically generate the user experience.
Practical implication: Set policy for which MCP resources may be rendered, what data they may display, and which actions must always require explicit user confirmation.
Breaches seen in the wild
- Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
- AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
MCP-UI expands the control surface from tool access to interaction governance. Text-only agent workflows forced practitioners to reason about prompts, tools, and outputs. Once an agent can render interactive components, the security question becomes whether the interaction itself can smuggle authority. That is a different class of governance problem, and it sits squarely in NHI and agentic access control. Practitioners should treat conversational UI as part of the identity perimeter, not a cosmetic layer.
Sandboxing reduces execution risk, but it does not solve trust delegation. Sandboxed iframes and Remote DOM lower the chance of arbitrary code escaping into the host, yet the agent and client still decide what gets shown and acted upon. That means the real issue is not only code safety, but who is allowed to translate user intent into system action. The implication for IAM is that rendering paths now need policy, traceability, and revocation logic alongside the underlying credentials.
Intent-based interfaces create a new named concept: interaction blast radius. When an interactive component can generate multiple downstream actions from a single click, the potential impact of a compromised or misdesigned UI increases sharply. The blast radius is no longer limited to the API call the user can see. It includes the intents an agent is willing to honour, the state changes those intents can trigger, and the data the UI can expose while doing so. Practitioners should evaluate UI-mediated agent flows as privileged pathways, not just usability features.
MCP-UI will accelerate platform consolidation around protocol-native agent experiences. The ecosystem is moving toward standardised interfaces that can travel across clients, which means identity governance teams will see more consistent but also more broadly reusable interaction patterns. That helps portability, but it also means a weak trust model can scale quickly across many deployments. The practitioner takeaway is simple: standardisation does not equal safety unless the policy model travels with it.
This development validates the need for agent-aware governance models that include the human in the loop without assuming the human is the only control. The user may still approve the final intent, but the agent increasingly shapes the options, presentation, and sequencing of those choices. That is enough to alter risk ownership. Teams should re-evaluate where approval actually happens in the flow and whether the current control stack can explain every state-changing action end to end.
From our research:
- 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, sharing sensitive data, and revealing access credentials.
- Forward-looking note: Read Analysis of Claude Code Security for a related view of how agentic execution changes identity and privilege assumptions.
What this signals
Interaction blast radius: MCP-UI turns interface design into a governance issue because the user-visible component can now shape the path to a privileged action. For programmes already stretched by agent adoption, that means workflow design, approval routing, and rendering policy must be treated as one control plane, not three separate ones. Teams that ignore the interaction layer will miss where authority actually accumulates.
With 98% of organisations planning to deploy more AI agents within the next 12 months, according to AI Agents: The New Attack Surface report, interactive protocols will scale faster than the governance models around them. The practical response is to align client rendering rules, intent logs, and privilege boundaries before agent workflows become business critical.
The next programme gap will be proving which interactive elements are allowed to influence state and which are display only. That requires policy over rendered content, not just over credentials, and a review model that can distinguish an informational component from a privileged action surface.
For practitioners
- Define policy for interactive MCP resources Classify which MCP resources may be rendered, what data they may expose, and which actions require explicit confirmation before execution. Treat the rendered component as governed output, not a neutral display surface.
- Audit agent-mediated intents end to end Trace every click, selection, and form submission from the UI event to the downstream system action. Confirm that the agent remains the policy gate and that no rendering path can bypass intent validation.
- Restrict remote rendering paths by risk tier Allow sandboxed iframe or Remote DOM rendering only for use cases with defined data sensitivity and clear audit requirements. Separate low-risk informational flows from workflows that can change entitlements, orders, or records.
- Add logging for UI-driven privilege changes Record which interactive element initiated the action, which identity mediated it, and what state changed. Preserve the linkage between rendered component, intent, and resulting entitlement update.
Key takeaways
- MCP-UI makes conversational interfaces part of the identity and access problem, because rendered components can now influence privileged actions.
- Sandboxing helps contain remote UI code, but it does not remove the need to govern intents, approvals, and audit trails.
- IAM teams should treat interactive agent workflows as controlled execution paths and define policy before the interface becomes the new automation layer.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | Interactive agent workflows can hide tool misuse and intent abuse. | |
| OWASP Non-Human Identity Top 10 | NHI-01 | MCP servers and clients rely on governed non-human identities and secrets. |
| NIST Zero Trust (SP 800-207) | PR.AC-4 | Rendered actions and tool calls need continuous authorization, not one-time trust. |
Map MCP server and client identities, then constrain their privileges to the minimum needed.
Key terms
- MCP Resource: An MCP Resource is a protocol object that can carry data, files, or interface content between an MCP server and client. In an agentic workflow, it becomes part of the controlled delivery path, so it should be treated as governed output rather than a neutral attachment.
- Intent-based messaging: Intent-based messaging is a pattern where a user action or UI event produces an intent that must be interpreted before a system change occurs. For AI agents, this preserves a policy checkpoint between interaction and execution, which is essential when the interface can trigger privileged actions.
- Interaction blast radius: Interaction blast radius is the scope of harm that can follow from a single UI action in an agent-mediated workflow. It includes data exposure, tool invocation, state change, and downstream delegation. The larger the blast radius, the more the interface must be governed like a privileged control surface.
Deepen your knowledge
MCP-UI and agent-mediated action paths are covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are governing interactive AI workflows or workload identities, the course gives you a practical baseline for doing it consistently.
This post draws on content published by WorkOS: MCP-UI: Breaking the Text Wall in AI Interactions. Read the original.
Published by the NHIMG editorial team on 2025-08-27.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org