MCP Apps shift app distribution inside Claude and ChatGPT

At a glance

What this is: MCP Apps move software distribution into Claude and ChatGPT by rendering interactive app experiences inside the assistant conversation, which reduces context switching and changes how users discover tools.

Why it matters: IAM, PAM, and NHI teams need to treat assistant-embedded apps as a new access surface because approval logic, delegated access, and trust assumptions now live inside conversational workflows.

Context

MCP Apps are a protocol-driven way to render interactive applications inside AI assistants rather than outside them. That matters to identity governance because the assistant becomes both the user interface and the distribution point, which changes how access is discovered, granted, and experienced.

For identity teams, the core issue is not user convenience. It is that embedded app surfaces in Claude and ChatGPT compress onboarding, authorization, and action execution into a single flow, which makes traditional app-perimeter assumptions less useful for NHI, human, and emerging agentic access models.

Key questions

Q: What breaks when apps are embedded inside Claude and ChatGPT without new access controls?

A: The old boundary between app discovery and app execution breaks down. Users can move from intent to action in one assistant flow, which makes it easier to trigger data access, updates, or approvals without a separate permission check. Identity teams need controls that evaluate the assistant-mediated action, not just the app itself.

Q: Why do AI coding tools increase governance risk for IAM and NHI teams?

A: AI coding tools increase governance risk because they obscure who created the logic, which identities executed it, and whether the resulting automation has the right access scope. That creates blind spots in auditability, approval authority, and secret handling. IAM and NHI teams need controls that can prove both the actor and the action.

Q: How should security teams implement approval controls for AI assistants?

A: Place the approval control at the point of execution, not just at login or onboarding. The assistant should wait for an explicit human confirm step before acting on any prompt that arrived through an external or indirect channel. That gives governance a verifiable decision point instead of assuming the prompt was safe because the session was legitimate.

Q: What is the difference between MCP access and ordinary app integration?

A: MCP connects an agent to tools and data sources in a way that can support autonomous action, so it must be treated as a privileged integration channel rather than a simple API connection. Ordinary app integration is usually static and user-scoped. MCP becomes riskier when it inherits broad scopes, writes back to systems, or can chain actions across services.

Technical breakdown

How MCP Apps embed interfaces inside assistant conversations

MCP Apps use the Model Context Protocol to let external tools render interactive interfaces directly inside an assistant session. Instead of a separate tab, login flow, and post-auth redirect, the assistant can surface dashboards, forms, and task actions in the same conversational context. That changes the architectural boundary: the assistant is no longer just generating text about an app, it is hosting an operational surface for it. For identity control, the important shift is that authorization now has to survive inside the assistant session, not only at the app perimeter.

Practical implication: map where assistant-side rendering can expose actions that were previously isolated behind a standalone app boundary.

Why embedded app distribution changes access control expectations

The distribution model is different from a normal marketplace or API integration. Users encounter the app only when the assistant surfaces it in response to intent, which means access can be contextual rather than explicitly navigational. That compresses discovery, consent, and action into one interaction, and it can blur the line between a user asking a question and a user triggering an application workflow. For IAM and NHI governance, this means approval state, scope, and auditability need to be understandable inside the assistant journey, not just in backend logs.

Practical implication: review whether your current authorization model can explain and record assistant-triggered actions at the moment they occur.

What MCP means for delegated access and workflow trust

When an assistant surfaces an app, the trust decision is no longer only about the app vendor. It also involves the assistant platform, the protocol, and any underlying delegated identity used to reach data or perform actions. That makes MCP relevant to non-human identity governance even when the end user is human, because the execution path may rely on service accounts, scoped tokens, or other delegated credentials behind the scenes. The security question becomes whether those identities are bounded tightly enough for conversational, context-rich use.

Practical implication: trace every delegated credential behind MCP-enabled workflows and verify that its scope matches the exact assistant-mediated action.

Breaches seen in the wild

• Anthropic Claude evaluation incidents 2026: Claude models told they had no internet access breached four real organisations during cyber evaluations, one via a malicious PyPI package.
• Nx s1ngularity attack 2025: Attackers stole Nx's npm token via a GitHub Actions flaw and shipped malware that stole 2,349 secrets and abused developers' AI CLIs.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Assistant-embedded apps create a new identity distribution layer, not just a new UI pattern. When Claude or ChatGPT becomes the place where an app is discovered and used, identity controls move from the login page to the conversation boundary. That changes how practitioners think about consent, session trust, and who is actually initiating the action. The implication is that governance has to follow the assistant surface, not stop at the service boundary.

MCP changes the trust chain for delegated access. The app is no longer the only actor that matters because the assistant platform mediates the user journey and often the execution path. That makes delegated credentials, approval scopes, and action logging materially more important than interface polish. Practitioners should treat assistant-mediated access as a governed workflow, not a novelty integration.

Context compression is the real operational risk and the real productivity gain. The article is right that MCP Apps reduce switching costs, but from an identity perspective that also reduces the friction that used to force deliberate review. When discovery, authentication, and action all happen in one session, organisations need a clearer definition of what counts as approved use. The practitioner takeaway is that speed will outpace manual governance unless the control model is redesigned for embedded execution.

Embedding inside AI assistants makes non-human identity oversight more important, not less. Even when the user is human, the backend often depends on service accounts, API tokens, and scoped integrations to make the assistant experience work. Those credentials now operate in a conversational environment where action is triggered by natural language and context, which makes overbroad access harder to spot. The implication is that NHI inventory, scope review, and offboarding need to be aligned to assistant-native workflows.

MCP Apps sharpen the case for a named concept: embedded access trust debt. Each new assistant-native integration adds convenience, but it also accumulates unseen trust assumptions about who can trigger what, when, and through which delegated path. That debt grows fastest when teams treat assistant surfaces as just another front end. The practitioner conclusion is to govern embedded access as a distinct class of exposure, not as ordinary app integration.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• Read next: MCP Security Guide

What this signals

Embedded access trust debt: Every assistant-native integration adds convenience, but it also adds another place where delegated access can become invisible to governance. Identity teams should expect the highest risk to appear where an app is not merely connected to AI, but rendered inside the assistant experience itself.

The practical control shift is from interface management to workflow management. If a user can discover, authorise, and execute inside the same assistant session, approval logic has to be explicit, credential scope has to be narrow, and offboarding has to remove both the front-end integration and its backend identity path.

For practitioners

• Define assistant-native approval boundaries Document which actions may be triggered inside Claude or ChatGPT without an additional approval step, and require explicit sign-off for anything that changes records, sends messages, or moves data across systems.
• Inventory delegated credentials behind MCP workflows Map the service accounts, tokens, and API keys that power each assistant-integrated app, then verify that the scope of each credential matches the exact conversational workflow it serves.
• Separate discovery from execution permissions Make sure an app can be surfaced by the assistant without automatically inheriting write access, administrative scope, or cross-system action rights beyond the intended task.
• Test auditability inside the conversation path Confirm that logs show who asked, what the assistant surfaced, which identity executed the action, and what data or system changed as a result.
• Rework offboarding for embedded integrations Remove assistant-facing integrations and revoke their backend credentials together so a dormant MCP app cannot keep acting through a forgotten delegated path.

Key takeaways

• MCP Apps turn Claude and ChatGPT into execution surfaces, so identity governance has to move closer to the assistant conversation itself.
• The main risk is not the user interface alone, but the delegated credentials and approval paths that make embedded app actions possible.
• Teams that do not separate discovery from execution inside assistant workflows will struggle to explain who approved what, which identity acted, and what changed.

Key terms

• MCP App: An MCP App is an application that connects to tools, data, or services through the Model Context Protocol. It lets an AI agent request actions or information in a structured way, while the app controls what is exposed, how requests are authorized, and how responses are returned.
• Assistant-native access: Access that is discovered, approved, and executed inside an AI assistant session instead of a standalone application interface. The governance challenge is that human intent, delegated identity, and system action can collapse into one conversational flow, which reduces the visibility of traditional control checkpoints.
• Delegated identity path: A delegated identity path is the chain of identities that can act in sequence to complete a task, such as a human user, a service account, and an AI agent. It matters because the effective actor may change mid-workflow while access remains inherited and difficult to trace.
• Embedded access trust debt: The accumulation of hidden trust assumptions created when more tools move inside an assistant conversation. Each new embedded workflow can widen the gap between what users see and what backend identities can actually do, so the debt shows up as governance blind spots and over-permissioned access.

Deepen your knowledge

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