MCP Apps changes how enterprise agents handle complex workflows

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Willow's blog post: MCP Apps Extension standardises interactive UI delivery for MCP servers so enterprise AI agents can handle approval, configuration, analytics, and audit tasks through structured interfaces rather than chat.

Why it matters: It matters because identity teams now have to govern not only what an AI agent can do, but also how the interface mediates approval, logging, and tool invocation across MCP-connected workflows.

Context

Chat is a poor fit for many enterprise workflows because complex decisions are easier to review in structured views than in linear text. That matters for MCP security because the protocol has now moved from simple tool invocation to interactive UI delivery, which changes where governance has to operate.

The underlying problem is not just usability. When an AI agent can present forms, dashboards, and approval screens inside the workflow, the security boundary shifts from the chat thread to the UI resource, the host application, and the action the UI initiates.

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: Why do interactive agent interfaces create new governance risk?

A: They shift decision-making into a richer surface where defaults, field order, and prompts can influence outcomes before policy is applied. That makes it easier for users to approve complex actions without fully reconstructing dependencies. The risk is not only bad UX, but delegated authority expressed through an interface that can obscure impact.

Q: What should teams do first when an agent can initiate UI-based actions?

A: Start by inventorying which workflows can trigger tool calls from the interface itself. Then classify the approval point, the logging requirement, and the policy check that must happen before the action is allowed to proceed. If those three are not explicit, the workflow is not governable yet.

Q: What is the difference between a chat-based agent workflow and an interactive UI workflow?

A: A chat workflow relies on linear text exchanges, while an interactive UI workflow uses structured fields, dashboards, and approval surfaces to present state and trigger actions. The latter can improve comprehension, but it also introduces another control layer that must be reviewed, logged, and bound to the right identity and permission scope.

Technical breakdown

Why MCP Apps changes the protocol boundary

MCP originally standardised how agents connect to tools and data through structured messages. MCP Apps adds interactive UI resources, which means the protocol now carries not only requests and responses but also human-facing control surfaces. That matters because the UI becomes part of the execution path, not a cosmetic layer. If the interface can trigger tool calls, then review, approval, and logging need to cover the UI resource itself, the transport between host and iframe, and the downstream action. The governance question changes from whether a tool is exposed to whether the presented interaction is safe, reviewable, and bound to the right principal.

Practical implication: Treat UI delivery as part of the agent trust boundary and review it with the same discipline as tool access.

How sandboxed interactive UI supports auditable approvals

The extension’s sandboxed iframe model and JSON-RPC over postMessage create a more inspectable interaction pattern than free-form chat. In practical terms, the host can separate rendering from execution, and can require explicit approval before a UI-initiated tool call proceeds. That gives security teams a way to distinguish what the agent showed from what it actually executed. The important detail is that auditability now depends on preserving the relationship between the declared UI resource, the approval event, and the subsequent tool call. Without that linkage, the interface becomes another place where context can be lost.

Practical implication: Require approval records to bind the UI resource, the user decision, and the resulting tool invocation.

Why structured interfaces matter for identity governance

Interactive UI is not just a productivity feature for AI agents. It is a governance mechanism for multi-step enterprise actions such as access requests, infrastructure changes, and audit review. Those workflows often fail in chat because humans have to mentally reconstruct dependencies, policy implications, and downstream impact from text alone. A structured interface reduces ambiguity, but it also concentrates authority: the presented fields, defaults, and disabled choices shape what the agent can do next. For identity programmes, that means the control surface is now part of the authorisation model. If the UI can mislead, over-simplify, or obscure dependencies, the governance process can still fail even when the backend policy is sound. See the AI Agent Authorisation Guide.

Practical implication: Review interactive workflows as authorisation artefacts, not just user experience components.

NHI Mgmt Group analysis

Interactive UI becomes part of the authorisation plane: MCP Apps does not merely improve presentation for AI agents. It moves policy-relevant decisions into a richer control surface where approvals, defaults, and action triggers can influence what gets executed. For identity governance, that means the reviewed object is no longer just the tool call. The UI resource, the host, and the approval pathway all become part of the trust model, and practitioners need to treat them as such.

Structured interaction reduces ambiguity, but it does not remove delegated risk: A dashboard or form can make a multi-step workflow easier to understand, yet it also creates a new place where users can approve complex actions without fully tracing the consequences. The governance challenge is not whether the interface is clearer. It is whether clarity is sufficient when the underlying actor is still an AI agent operating through delegated authority. The implication is that control design has to account for both comprehension and delegation.

Pre-declared UI resources create a reviewable surface for identity teams: The strongest design feature here is not the visual layer itself but the fact that UI resources can be declared before execution. That creates a chance to review how actions will be framed before they are operationalised, which is especially important for approval workflows and compliance evidence. Identity teams should see this as a way to move some controls earlier in the lifecycle, closer to presentation and initiation rather than only at execution time.

Interactive interfaces will widen the gap between capable agents and governable agents: The market will increasingly ship richer agent experiences, but governance maturity will lag unless teams can inspect UI resources, approval flows, and tool-call provenance together. A workflow that looks safer because it is visual can still be poorly governed if the identity model behind it is loose. Practitioners should assume adoption pressure will outpace policy clarity and plan for that gap now.

From our research library:

• 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
• Read next: MCP Security Guide

What this signals

Interface governance will become an identity problem: As agents move from chat into structured workflows, the control question shifts from what the agent said to what the interface allowed it to do. That means security teams will need to review UI resources, approval paths, and delegated action boundaries together, not as separate concerns. AI agent authorisation becomes the right lens when the interface itself can initiate change.

Pre-declared interaction surfaces are the real policy opportunity: If interactive UI resources are defined before execution, organisations get a chance to inspect the workflow shape before it reaches production. That is useful because many agent failures will come from ambiguous presentation rather than obviously malicious behaviour. The programme implication is to move review earlier, where the interface and the authorisation decision can still be changed.

Structured approval workflows will define adoption quality: Enterprises will not only ask whether an agent can do the task. They will ask whether the task can be reviewed, evidenced, and constrained in a way that satisfies operations, security, and audit. Teams that can tie interface design to governance evidence will have a clearer path to safe adoption than teams treating UI as a cosmetic layer.

For practitioners

• Review UI resources before allowing execution Assess declared ui:// resources as part of pre-production control review, including what the interface can display, request, and trigger.
• Bind approvals to the presented interface Require approval records to capture the exact UI resource, the decision made, and the downstream tool call so auditors can reconstruct the path.
• Separate rendering from execution authority Ensure sandboxed iframes cannot silently expand privilege and that any UI-initiated tool call requires explicit policy evaluation.
• Map interactive workflows to identity controls Classify each interactive agent flow by who or what can act, which permissions are exposed, and where consent or approval is enforced.

Key takeaways

• MCP Apps extends the protocol into interactive interfaces, which means governance now has to cover UI resources, approvals, and the resulting tool calls.
• The main benefit is not prettier chat, but a more reviewable way to handle complex enterprise workflows that do not fit linear text.
• Identity and access teams should treat interface design as part of the authorisation model, because presentation choices can shape delegated action.

Related NHI Mgmt Group resources: AI Agent Authorisation Guide · Agentic AI Identity Guide · AI Agent Observability, Audit and Incident Response Guide · MCP Security Guide

Key terms

• Interactive UI Resource: A structured interface component that an MCP server exposes to a host application for use inside an agent workflow. It is not just presentation. It becomes part of the control path when it can shape review, approval, or tool execution.
• App-Initiated Tool Call: A tool invocation started by an MCP App rather than a direct user request. The call still traverses the normal governed execution path, so security teams should treat it as a standard authorisation and audit event even when the user interface is rendered inside trusted client chrome.
• Delegated Authority Model: A delegated authority model defines who is allowed to approve, review, or execute control-related decisions across the enterprise. It helps ensure requests reach the correct responsible party, especially when control owners, managers, and process owners sit in different teams, regions, or systems.
• Approval Workflow: An approval workflow is the governed sequence that determines whether a request becomes active access. It usually combines routing, policy checks, and evidence capture. For identity teams, the important question is not how fast it runs, but whether each decision remains attributable and reviewable.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.