Notifications
Clear all
Topic starter
07/06/2026 8:09 pm
TL;DR: MCP Apps let developers render interactive app experiences directly inside Claude and ChatGPT, turning AI assistants into a new distribution layer and collapsing context-switching friction for users, according to WorkOS. The shift changes go-to-market, interface design, and approval logic for teams that govern human, NHI, and agentic access.
NHIMG editorial — based on content published by WorkOS: The shift from apps with AI to AI with apps, and why your next app should live inside Claude
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.
Questions worth separating out
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.
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.
Q: What breaks when an app is approved without assistant-specific governance?
A: What breaks is traceability and scope control.
Practitioner guidance
- Map assistant-mediated delegation chains Inventory every MCP App path from user intent to assistant session to embedded app to downstream action.
- Classify embedded actions by privilege level Separate read-only retrieval, interactive dashboard use, and write or approval actions into different control tiers.
- Extend third-party review to assistant-native integrations Add MCP Apps to vendor intake, risk review, and access recertification processes.
What's in the full article
WorkOS' full blog post covers the operational detail this post intentionally leaves for the source:
- Implementation examples for building MCP Apps that render inside Claude and ChatGPT.
- Developer-oriented guidance on getting a first app running and shipping it to the platform directories.
- The article's go-to-market framing for indie builders, startups, enterprise vendors, and agencies.
- Practical build sequencing for teams deciding whether to go MCP-first or add embedded support later.
👉 Read WorkOS' analysis of MCP Apps and AI assistant distribution →
MCP Apps in Claude and ChatGPT: what builders should change?
Explore further
07/06/2026 9:57 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: MCP Apps shift app distribution inside Claude and ChatGPT
