Between October 2025 and late May 2026, OpenAI moved ChatGPT apps and MCP from early product material into something companies can actually deploy. On October 6, 2025, OpenAI introduced apps in ChatGPT and the Apps SDK on top of the Model Context Protocol. On December 17, 2025, it opened app submissions for review and publication. And as of June 1, 2026, OpenAI’s help documentation says full MCP support, including modify and write actions, is rolling out in beta to ChatGPT Business, Enterprise, and Edu. That shifts the real question. It is no longer whether ChatGPT can connect to internal systems. It is which systems, which actions, which users, and under what controls.
This Is No Longer A Read-Only Demo
The important change is not simply that ChatGPT can call a tool. It is that OpenAI now supports internal custom apps and full MCP access inside workspace plans where employees can use them against live business systems. The help documentation is explicit: custom MCP apps can do more than search and fetch. They can start workflows, create project management tasks, update a CRM, and orchestrate across multiple apps. The developer-mode guide says the same thing more plainly: developer mode supports all tools, both read and write.
That is where governance enters the picture. Search-oriented integrations mostly raise questions about retrieval quality and inherited permissions. Write-capable integrations are different. If a model can create a task, update a customer record, or trigger a workflow, the problem is no longer technical connectivity. The problem is whether that action should be available at all, who should be allowed to use it, and what happens when the model suggests the wrong move.
OpenAI’s own documentation leans into that risk. The developer-mode guide warns about prompt injection, malicious MCP servers, and model mistakes on write actions that could destroy data. The help center says admins see risk warnings when enabling write-capable apps, and ChatGPT shows confirmation prompts before consequential write actions. Useful safeguards, yes. But they do not replace internal decisions about scope, approval, and fallback.
The Project Scope Is Permissions, Actions, And Change Control
In practice, a serious rollout has four governance tracks.
First, someone needs to decide which systems should be exposed in the first place. OpenAI-built apps are search-only today, while custom MCP apps are the path to write and modify capabilities. So the work starts before publication. You pick one or two workflows where conversational action is genuinely helpful, instead of exposing a broad administrative surface just because the API allows it.
Second, the action surface has to be defined precisely. OpenAI’s help documentation says Enterprise and Edu admins can configure which actions an app is allowed to take before publishing, and newly discovered actions are disabled by default when the app is refreshed. It also says approved MCP apps run from a frozen snapshot of tools and inputs until an admin reviews and republishes changes. Operationally, that matters a lot. It means every exposed tool needs an approval path, connector changes need a review path, and rollback has to be planned before anything reaches users. On Business plans, the model is stricter still: apps cannot be updated in place after launch and must be recreated and republished to change tools or metadata.
Third, the team has to decide who may build, publish, and use the app. The help article says only admins and owners can publish. In Business workspaces, only admins and owners can enable developer mode for themselves. In Enterprise and Edu, admins can use RBAC to grant developer-mode access to a smaller group and can separately control which users get access to each vetted app. That is not a minor implementation detail. It is the operating model for internal AI change management.
Fourth, identity and session durability need an owner. OpenAI’s help documentation warns that if an OAuth setup does not provide refresh-token capability such as offline_access, ChatGPT may lose access after the original authorization expires and users may need to authenticate again. In other words, OAuth design belongs in the initial project scope, not on the cleanup list after launch.
Tool Design Is Part Of The Control Surface
OpenAI’s developer documentation makes another practical point: tool metadata affects how safely the model behaves. OpenAI recommends action-oriented tool names and descriptions, Use this when guidance, disallowed cases, parameter descriptions, and enums that help the model choose correctly between similar tools. The guide also recommends server-level instructions for shared constraints and sequences, and notes that tools without the readOnlyHint annotation are treated as write actions.
For internal apps, that means vague tools like update_record or run_workflow are not just messy design. They create avoidable risk. If two systems overlap, OpenAI explicitly suggests telling the model which source is authoritative and which tool should be avoided. So the control surface is not only RBAC and OAuth. It is also the precision of the tool contract itself. Narrower tools, sharper descriptions, and testing against ambiguous prompts are governance work as much as engineering work.
Submission And Policy Expectations Raise The Bar Further
OpenAI’s December 17, 2025 announcement confirmed that developers can now submit apps for review and publication, track approval status in the OpenAI Developer Platform, and provide MCP connectivity details, testing guidance, directory metadata, and country availability settings. Even if a company begins with an internal-only app, a live submission and review path changes expectations. Apps are no longer side experiments. They are a managed product surface with documentation, QA, and release requirements.
OpenAI’s product pages and App Developer Terms reinforce that. The product announcement says the strongest apps are tightly scoped, intuitive in chat, and built around real user intent. It also says developers must include clear privacy policies, request only the information needed to make the app work, and let users review what data may be shared when they connect an app. The App Developer Terms go further: app requests may only be processed as necessary and in accordance with law; developers are responsible for required rights, consents, notices, and disclosures; and OpenAI may review, test, reject, or remove apps. The terms also draw clear boundaries by prohibiting apps from creating or processing HIPAA-regulated protected health information or PCI-regulated payment card data through this surface.
That matters for internal governance even if publication is not the immediate goal. If the first use case touches regulated health data, payment card data, or a high-risk write path with weak review controls, the better decision is usually to redesign the use case before rollout.
What A Paid Governance Project Actually Includes
For a company that wants ChatGPT connected to its CRM, project stack, or ticketing flow, the sensible first engagement is not a broad platform rollout. It is a tightly scoped governance-and-pilot project.
In practice, that usually means inventorying candidate systems and choosing one workflow where the value is obvious and the risk is contained. It means exposing only the actions needed for that workflow, not mirroring an entire API because it is available. It means setting up authentication properly, deciding who can publish and who can use the app, and testing how confirmation behaves on write actions. It also means documenting how tool refreshes are approved, how frozen snapshots are updated, and how the team rolls back if a tool definition changes or the wrong action is exposed. For Enterprise and Edu clients, it can also include planning around RBAC and the Compliance API visibility OpenAI makes available for app-involved conversations.
That is why internal tool exposure now looks like a paid governance project. The scarce work is not just connector code. It is deciding what should be exposed, constraining it, piloting it safely, and creating an approval model the business can actually live with. GrN’s role in that kind of engagement is practical: inventory candidate systems, expose only the actions that are safe and commercially relevant, build or adapt the MCP app, wire OAuth and RBAC, pilot one internal workflow, and document approval and rollback steps before a wider rollout.
Need help with this kind of work?
If you want to prove one controlled ChatGPT workflow before opening up more systems, Greg can scope the permissions, pilot, and rollback path. Get in touch with Greg.