By Greg Nowak. Last updated 2026-07-22.
ChatGPT apps have crossed an important line: they can now do more than find information. With full Model Context Protocol (MCP) support, a custom app can create tasks, update records, start workflows, and combine actions across business systems.
As of July 22, 2026, full MCP support remains a beta rolling out to ChatGPT Business, Enterprise, and Edu on the web. OpenAI has also moved app discovery into its Plugin Directory. The terminology can be confusing, but the distinction is useful: a plugin packages workflow capabilities, while an app provides the connection to external data and actions. Installing a plugin and authorising its underlying app are separate governance decisions.
For a business owner or operations lead, the question is no longer, “Can we connect ChatGPT to our systems?” It is, “What should it be allowed to do, for whom, and how do we recover when something goes wrong?”
Govern the workflow, not just the connector
A broad instruction such as “connect ChatGPT to the CRM” is not a workable project scope. A better starting point is one specific job with a visible beginning and end: retrieve the relevant record, prepare a proposed change, let an authorised person review it, and then submit the approved update.
That workflow should be documented before anyone builds the MCP server. Record:
- which system is authoritative;
- what information ChatGPT may read;
- which fields or objects it may change;
- who may invoke each action;
- which actions require confirmation or a second approver;
- how errors are detected, reversed, and reported.
This prevents a technically successful integration from quietly becoming an uncontrolled administrative interface.
| Workflow type | Sensible first release | Minimum controls | Decision |
|---|---|---|---|
| Search or summarisation | Read-only pilot | Source permissions, data boundaries, answer testing | Good place to start |
| Reversible internal update | Small pilot group | Named tool, confirmation, audit trail, rollback procedure | Proceed with controls |
| External communication | Draft before send | Recipient preview, explicit approval, restricted roles | Keep a human checkpoint |
| Deletion or irreversible action | Read-only or dry-run version | Separate approval, narrow scope, tested recovery | Defer until justified |
Separate access, actions, and approvals
These are three different controls. Access decides who can use an app. Action control decides what the app can do. App permissions influence when ChatGPT asks before using an action. Treating them as one setting leaves gaps.
Enterprise and Edu administrators can use role-based access control and, where supported, allow all actions, read-only actions, or a custom set. They can also decide how newly discovered actions should be handled. Business workspaces have a more admin-led developer-mode model, and OpenAI currently says a published custom app must be recreated and republished when its tools or metadata change.
Defaults also differ: plugins and apps are enabled by default in Business, while Enterprise and Edu start with them disabled. Do not assume the product default matches the company’s risk appetite. Establish an approved-app owner, a user group, and an action policy before inviting a pilot team.
Tool design is part of governance
The MCP tool contract strongly affects which action the model selects. OpenAI recommends one job per tool and separate read and write tools. A focused tool such as crm.get_account or projects.create_task is easier to test and govern than a vague update_record endpoint.
For each tool, define:
- an action-oriented name and a description beginning with clear “Use this when” guidance;
- explicit input and output schemas, including enums and safe ranges;
readOnlyHintwhen it cannot change state;destructiveHintwhen it can delete, overwrite, or cause an irreversible outcome;openWorldHintwhen it can affect public or external systems.
These annotations must describe actual behaviour. A reassuring description does not turn a state-changing tool into a read-only one. Test direct prompts, ambiguous prompts, and prompts that should not invoke the tool at all.
Authentication needs an operational owner
Authentication is not finished when the first OAuth login succeeds. Confirm that the identity provider can issue refresh tokens; for OpenID Connect, this commonly involves the offline_access scope and matching discovery metadata. Otherwise, access may expire and users may have to authenticate again unexpectedly.
Also test the user’s permissions in the source system. Enabling an app in ChatGPT should not grant access to records, files, or channels that the user cannot access directly. Domain restrictions and narrowly scoped OAuth permissions can help keep personal accounts and unnecessary data outside the workflow.
Plan releases and rollback before launch
OpenAI’s controls reduce risk, but confirmation prompts are not a substitute for a release process. Some consequential actions may require approval, while particularly risky actions may be blocked. Your own plan still needs named owners, test cases, monitoring, and recovery steps.
Maintain a tool register containing the tool name, owner, data touched, write behaviour, authentication scope, approved roles, and rollback method. Review changes to MCP tool definitions as API changes. For public distribution, OpenAI scans the tool metadata and keeps a published snapshot; changed tool contracts must be rescanned, reviewed, and published before users receive them.
What a useful first engagement looks like
A sensible consulting engagement is a governance-and-pilot project, not an organisation-wide connector rollout. It should select one valuable workflow, map its data and authority boundaries, design the smallest useful tool set, configure authentication and access, and test the workflow with a limited group.
The final handover should include an access matrix, tool register, prompt test set, approval rules, deployment procedure, rollback plan, and recommendations for the next release. That gives the business something it can operate—not merely a demonstration that worked once.
Start with one controlled workflow
If you are considering a ChatGPT app for a CRM, project platform, content operation, or internal service desk, Greg can help turn the idea into a scoped pilot with clear permissions and a workable release plan. Talk to Greg about your workflow.
Related on GrN.dk
- ChatGPT apps need a permissions map before they touch company data
- Background AI Tasks Need Queues, Not Just Longer API Calls
- AI agents need a browser policy before they start clicking around
Need help with this kind of work?
Plan a controlled ChatGPT workflow with Greg Get in touch with Greg.
