Without strong sandboxing and pre-declared template review, a malicious or compromised server could try to inject unexpected behaviour into the chat experience. That can expose users to unsafe actions, confuse the trust boundary between host and tool, and make it harder to detect what data moved between components. The risk is control loss, not just visual tampering.
Why This Matters for Security Teams
mcp server UI code sits inside the trust path between users, tools, and data. If that code is not sandboxed and reviewed, the server can shape what users see, what actions they are prompted to take, and how tool outputs are framed. That turns a presentation layer issue into an authority issue. In agentic workflows, trust failures in the interface can become unsafe execution paths, especially when the UI is allowed to influence tool calls or obscure provenance.
This is why the risk is larger than visual tampering. Review and containment failures can blur the boundary between host and tool, weaken operator judgment, and hide data movement across components. NHI Management Group research on MCP security shows how quickly this becomes operational: The State of MCP Server Security 2025 found that 53% of MCP servers expose credentials through hard-coded values in configuration files. The same ecosystem also shows weak permission scoping in practice, which makes UI compromise more dangerous than it looks. In practice, many security teams discover this only after a deceptive server prompt or hidden action has already changed user behaviour.
How It Works in Practice
Properly sandboxed MCP server UI code should be treated as untrusted code, not as a harmless extension of the host experience. The practical goal is to prevent the server from directly controlling navigation, prompting, credential handling, or cross-origin data flows beyond its declared scope. Current guidance suggests using a hardened rendering boundary, strict content restrictions, and pre-declared templates so that the host controls structure while the server supplies only bounded data.
That means the UI should not freely execute arbitrary scripts, reach outside its declared component model, or dynamically rewrite trust cues. The host should also enforce explicit review of server-delivered UI changes, especially when those changes affect action buttons, permission prompts, or data summaries. This aligns with the broader agentic risk model described in the OWASP Agentic Applications Top 10 and the external OWASP Agentic AI Top 10, both of which stress that tool-adjacent presentation layers can become attack surfaces.
- Render server UI in a restrictive sandbox with no ambient access to host secrets or privileged browser APIs.
- Require pre-review of templates and component manifests before any UI path is allowed in production.
- Separate display content from action logic so the server cannot silently change what an operator approves.
- Log rendered UI metadata, tool calls, and user approvals together so investigators can reconstruct the sequence.
Where this guidance breaks down is in highly dynamic plugin ecosystems that allow third-party servers to ship their own interactive components without a stable review gate, because the host loses reliable control over what code executes and how trust is signaled.
Common Variations and Edge Cases
Tighter sandboxing often increases integration overhead, requiring organisations to balance developer agility against stronger control over untrusted UI paths. That tradeoff becomes especially visible when teams want rich, interactive agent experiences but also need deterministic review and containment.
There is no universal standard for this yet. Some environments can tolerate server-rendered markdown with minimal interactivity, while others need stricter isolation for embedded widgets, approval prompts, and data previews. The safest pattern is to treat any UI that can influence agent actions as security-relevant code and to review it accordingly. This is reinforced by the Analysis of Claude Code Security, which highlights how code-facing AI experiences can introduce new trust failures when execution boundaries are weak. It also matches the external OWASP Top 10 for Agentic Applications 2026 view that agent-facing interfaces require explicit abuse-case thinking, not just input sanitization.
Edge cases include internal-only MCP servers, “trusted” developer tooling, and convenience wrappers that teams assume are low risk. Those environments still fail when a compromised server can inject misleading controls, suppress warnings, or steer a user into approving unintended actions. The review burden is lower for static content, but the moment UI can influence authority or execution, it needs the same discipline as any other privileged code path.
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, CSA MAESTRO and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and 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 | A1 | Agent-facing UI can steer tool use and unsafe approvals. |
| CSA MAESTRO | T2 | Trust boundaries around agent tools and interfaces must be enforced. |
| NIST AI RMF | GOVERN | Unreviewed UI code weakens governance over AI-assisted decisions. |
| OWASP Non-Human Identity Top 10 | NHI-05 | Compromised server UI can expose secrets and distort trust boundaries. |
| NIST Zero Trust (SP 800-207) | AC-6 | Least privilege limits damage when a server UI path is compromised. |
Treat agent UI as attack surface and restrict any component that can influence execution or authorization.
