MCP Apps expand the attack surface by moving from text and tool calls into interactive UI rendered inside the assistant. That creates new trust decisions around sandboxing, message flow, and host permissions. Organisations need to assume that any embedded interface can influence user actions, so governance must extend beyond data access into UI behaviour and action approval.
Why This Matters for Security Teams
MCP Apps raise the stakes because the assistant is no longer only making tool calls. It is rendering interactive application content inside a trusted workflow, which means the security boundary now includes what the user sees, clicks, approves, and copies back into the session. That shifts risk from backend permissions alone into UI trust, message integrity, and host-level permissions. Guidance on OWASP Top 10 for Agentic Applications 2026 and NHIMG’s OWASP Agentic Applications Top 10 both point to the same issue: autonomous or semi-autonomous interfaces can influence decisions in ways traditional API governance does not cover.
For security teams, the practical problem is that embedded UI can disguise intent, prompt unsafe actions, or present data that causes a user to grant broader access than intended. The assistant may also inherit trust from the host application even when the embedded component should be treated as untrusted. Current guidance suggests that organisations should treat MCP Apps as an interactive trust boundary, not just an integration pattern. In practice, many security teams discover this only after an embedded app has already influenced a privileged approval or a sensitive data flow.
How It Works in Practice
Secure deployment starts by separating three layers: the assistant host, the MCP App runtime, and the underlying tools or secrets the app can reach. The host should enforce sandboxing, explicit user intent, and scoped permissions so the embedded interface cannot silently expand its privileges. The app should only receive the minimum data needed for the current task, and any action that changes state should require a clear approval step tied to the exact operation.
In practice, this means security teams should evaluate:
- Whether the MCP App can render content that mimics trusted system prompts or approval dialogs.
- Whether message flow between the assistant and the app is authenticated, integrity-protected, and bounded to a single session.
- Whether host permissions are short-lived and task-specific rather than broad and persistent.
- Whether secrets, tokens, and downstream tool access are isolated from the UI layer entirely.
That design aligns with the direction of NIST SP 800-53 Rev 5 Security and Privacy Controls, especially for least privilege, input validation, and separation of duties, but the implementation challenge is sharper in agentic systems because the interface itself can shape behaviour. NHIMG’s Analysis of Claude Code Security and LLMjacking: How Attackers Hijack AI Using Compromised NHIs show how quickly identity abuse and exposed credentials become operational risk once an assistant can act on behalf of a user. These controls tend to break down when the MCP App can request follow-on actions in the same session because the user loses visibility into which step actually triggered privilege use.
Common Variations and Edge Cases
Tighter isolation often increases friction for users and developers, so organisations have to balance safe interaction design against workflow speed. There is no universal standard for MCP App approval prompts yet, and best practice is still evolving around how much context the user needs before authorising a tool action or UI-driven state change.
Several edge cases deserve special attention. First, an MCP App that only displays data can still be dangerous if it shapes the user’s next click, especially in finance, admin, and code execution workflows. Second, if the assistant host shares browser-like privileges with the app, the boundary becomes easier to blur and harder to audit. Third, when an integration handles secrets or OAuth tokens, the risk moves from visual deception into credential abuse and lateral movement, which is why NHIMG’s Vercel Context.ai OAuth Supply Chain Breach remains a relevant cautionary example.
The operational takeaway is simple: treat every embedded interface as capable of steering trust, not just consuming data. Organisations that assume “read-only” means “low risk” tend to miss the moment when the UI becomes the control plane for unsafe approvals, especially in environments where users are already conditioned to trust the assistant.
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 CSA MAESTRO address the attack and risk surface, while NIST AI RMF, NIST CSF 2.0 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 | A03 | Covers prompt, UI, and tool abuse in assistant-driven workflows. |
| CSA MAESTRO | MA-02 | Addresses trust boundaries and runtime governance for agentic applications. |
| NIST AI RMF | GOVERN | Requires accountability and oversight for AI system behaviour in context. |
| NIST CSF 2.0 | PR.AC-3 | Supports access control and least-privilege enforcement for integrations. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero trust isolation is relevant when embedded apps can influence host actions. |
Review embedded MCP App flows for deceptive UI, unsafe approvals, and tool escalation paths.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
