MCP Apps shift app distribution inside Claude and ChatGPT

At a glance

What this is: MCP Apps move software interfaces into AI assistants, making in-conversation app use the new distribution model and changing how developers think about product reach.

Why it matters: IAM teams should care because embedded AI experiences will reuse existing identity, consent, and access patterns while creating new NHI and agentic control points that need governance.

By the numbers:

• The median B2B SaaS company now spends $1.32 to acquire $1 of ARR.
• Teams using Asana through MCP Apps report being 40% faster at project updates because they no longer have to context-switch.

👉 Read WorkOS' analysis of MCP Apps and AI assistant distribution

Context

MCP Apps are interactive interfaces that render inside Claude and ChatGPT instead of in a standalone browser or desktop app. The governance question is not whether AI is becoming part of the app, but what identity and access model applies when the app itself is embedded inside an assistant. That matters for NHI and autonomous workflows because the assistant becomes both the interface and the distribution layer.

For practitioners, the risk is that convenience can obscure trust boundaries. When a user invokes a workflow through an AI assistant, the organisation still needs to know which identity is acting, what data it can reach, and whether the action is a simple tool call or a broader delegated workflow. The article frames a real platform shift, and that is the right lens for IAM and security planning.

Key questions

Q: How should security teams govern apps that run inside AI assistants?

A: Security teams should govern assistant-embedded apps as delegated access paths, not as a pure UX layer. That means scoping what each app can read or do, recording the initiating user and assistant session, and reviewing offboarding and recertification the same way they would for other non-human access paths.

Q: Why do embedded AI app experiences change access risk?

A: They change risk because the assistant can collapse discovery, authentication, and action into one conversational flow. Users are more likely to approve access when the app appears native, so teams need tighter scope control, stronger logging, and clearer separation between retrieval and privileged execution.

Q: What breaks when an app is approved without assistant-specific governance?

A: What breaks is traceability and scope control. Teams may know the user, but not the exact assistant-mediated path that exposed data or triggered an action. That leaves audit, incident review, and entitlement cleanup weaker than they appear on paper.

Q: What is the difference between a normal app integration and an MCP App?

A: A normal integration usually lives outside the conversation and requires the user to move between tools. An MCP App renders inside the assistant, so the conversation becomes the operating surface. That changes how identity, consent, and logging need to be designed.

Technical breakdown

MCP Apps as an embedded interface layer

MCP Apps let an application render cards, forms, dashboards, and actions inside a model conversation. That changes the integration point from browser tab or API client to assistant context. In identity terms, the assistant session becomes the execution environment, while the app exposes controlled capabilities into that environment. The technical implication is that app access, data retrieval, and action execution are now mediated by a protocol designed for structured interaction, not just file or API exchange.

Practical implication: treat each embedded capability as an access surface that needs explicit scoping, logging, and review.

Context retention and prompt-to-outcome compression

The article argues that MCP Apps reduce context switching by keeping the task, the data, and the output inside the same conversation. That compression matters because it removes several friction points where users normally re-authenticate, re-open tools, or manually move data between systems. The architectural effect is not just better UX. It creates a tighter coupling between conversational intent and downstream application action, which changes how approval, consent, and traceability should be designed.

Practical implication: map where conversational intent turns into privileged action and require controls at that transition.

Platform distribution and default-choice effects

When the assistant surfaces the app at the moment of need, discovery becomes contextual rather than search-driven. That creates a new distribution layer similar to app stores and platform directories, but with a stronger reliance on relevance ranking and assistant mediation. For security teams, the important point is that approved integrations can gain rapid default status across the enterprise, which compresses evaluation cycles and raises the cost of late governance decisions. In practice, platform approval is now part of application risk management.

Practical implication: add assistant-native integrations to your third-party and NHI review process before adoption scales.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Embedded AI interfaces create an NHI governance problem before they create an application problem. Once an app is callable from Claude or ChatGPT, the identity question shifts from endpoint access to assistant-mediated execution. Existing IAM programmes often govern the user and the app separately, but embedded workflows blur that boundary and make delegated access the real control surface. Practitioners should treat MCP Apps as a new NHI governance tier, not just a new front end.

Context-rich assistants increase the likelihood of over-broad trust decisions. The article is right that users may already trust the assistant, but trust transfer is not the same as authorisation. When an app appears native inside the conversation, people are more likely to approve access without re-evaluating the scope of data exposure. The implication is that consent, entitlement scope, and auditability need to be designed for conversational decision paths, not only traditional login flows.

Category ownership will now depend on identity and access readiness, not only product features. Platform shifts reward the teams that can ship integrations quickly, but enterprise adoption will only sustain that advantage if the embedded app can be governed cleanly. This is where NHI controls, approval workflows, and lifecycle oversight become part of go-to-market execution. Practitioners should expect procurement to ask the same questions about embedded assistants that they already ask about APIs and service accounts.

Assistant-native access should be treated as a controlled delegation chain. The user intent, assistant session, embedded app, and downstream tool action form one governance path. That chain needs traceability across who initiated the request, what data was exposed, and what action actually executed. For identity teams, the practical conclusion is that MCP Apps belong in delegated access reviews, not in a separate innovation bucket.

Identity blast radius expands when the assistant becomes the router. A named concept worth carrying forward here is identity blast radius, the amount of access and data a single conversational workflow can reach once the assistant brokers the interaction. The more the app is embedded, the more difficult it becomes to separate harmless retrieval from privileged execution. Practitioners should evaluate this as a measurable governance boundary, not an abstract UX effect.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• Only 44% of organisations have implemented any policies to govern AI agents, even though 92% agree governance is critical to enterprise security.
• For teams building assistant-native workflows, the next step is to pair embedded-app governance with the OWASP Agentic AI Top 10 so tool use, delegation, and privilege are reviewed together.

What this signals

Identity blast radius is the right lens for assistant-embedded software. When a single conversation can reach multiple tools, the governance challenge is no longer app onboarding alone, but how far an approved workflow can spread across data, action, and privilege boundaries.

The next programme-level shift is to treat assistant-native integrations as a formal category in access reviews, vendor intake, and audit evidence collection. Teams that already manage non-human identities should be able to extend that control plane to MCP Apps without inventing a separate model for conversational execution.

The broader market signal is that AI platforms are becoming distribution systems as well as control surfaces. That will reward organisations that can measure scope, trace execution, and prove offboarding across embedded workflows before the category fills with opaque integrations.

For practitioners

• Map assistant-mediated delegation chains Inventory every MCP App path from user intent to assistant session to embedded app to downstream action. Record where authentication, consent, and policy checks occur so you can see which steps are implicit and which are enforced.
• Classify embedded actions by privilege level Separate read-only retrieval, interactive dashboard use, and write or approval actions into different control tiers. Require higher assurance for any action that can change records, trigger workflows, or expose regulated data.
• Extend third-party review to assistant-native integrations Add MCP Apps to vendor intake, risk review, and access recertification processes. Evaluate data scope, logging, and offboarding the same way you would for APIs and service accounts, because the governance problem is the same even if the interface feels new.
• Define logging for conversation-driven actions Make sure audit trails capture the user request, assistant context, embedded app invoked, and final action taken. Without that chain, incident review cannot distinguish user intent from assistant mediation or downstream execution.

Key takeaways

• MCP Apps move application access into AI conversations, which makes delegated identity and scope control the main governance issue.
• The article's distribution argument is real, but the security consequence is a larger identity blast radius whenever an assistant can route to tools and data.
• IAM and NHI teams should extend approval, logging, and recertification to assistant-native integrations before those workflows become default paths.

Key terms

• MCP App: An MCP App is an application experience that renders inside an AI assistant conversation instead of a separate interface. In practice, it turns the assistant into the delivery surface for data, dashboards, and actions, which means identity, scope, and audit controls must follow the conversation path.
• Delegated access chain: A delegated access chain is the sequence from a user request through an intermediary system to a downstream action. For assistant-embedded workflows, that chain includes the assistant session and the app it invokes, so governance must prove who initiated the request, what was exposed, and what executed.
• Identity blast radius: Identity blast radius is the amount of data, tools, and actions that a single identity path can reach before control boundaries stop it. In embedded AI workflows, the blast radius can expand quickly because the assistant can route a user request into multiple systems within one conversation.

Deepen your knowledge

MCP Apps and assistant-mediated delegation are covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are extending identity governance into AI assistant workflows, it is worth exploring.

This post draws on content published by WorkOS: The shift from apps with AI to AI with apps, and why your next app should live inside Claude. Read the original.