Which OpenAI Integration Surface Fits Your Team? A 2026 Buyer’s Guide to ChatGPT Apps, Company Knowledge, Codex MCP, and the Responses API

Five branching pathways connect one secured data vault to a conversation space, a shared knowledge table, a managed tool station, a developer workbench, and an application control room.

October 2, 2026

Evidence checkpoints

Documented point: As reviewed on 2 October 2026, the connected-app guidance states that app availability depends on the app, plan, region, workspace, role, model and interface; connecting an app does not grant additional source permissions. Do not promise any app to every subscriber or imply that installing an app bypasses provider authorisation, workspace approval, or third-party data terms. [official source 1]

Documented point: As reviewed on 2 October 2026, Company Knowledge is available in eligible Business, Enterprise and Education workspaces when the plugin, supported source and necessary administrator and provider permissions are present. It respects existing source permissions and is not a universal company-data index; plugin installation does not itself connect every provider account. [official source 1]

Documented point: As reviewed on 2 October 2026, developer-mode guidance describes full Model Context Protocol (MCP) support, including some modify/write actions, as beta for eligible Business, Enterprise and Education workspaces, with administrator publication and role/action controls. The documentation has plan/surface distinctions and beta language; qualify full-MCP availability and verify the live tenant rather than publishing a universal entitlement matrix. [official source 1]

Documented point: As reviewed on 2 October 2026, Codex desktop, command-line and integrated-development-environment surfaces share same-host MCP configuration and support local standard-input/output and streamable Hypertext Transfer Protocol servers, with scope and approval controls. Local Codex MCP configuration is not automatically a workspace-published ChatGPT app; hosted plugin capabilities can differ. [official source 1]

Documented point: As reviewed on 2 October 2026, the Responses API remote-MCP guidance shows approval requests before sharing data by default and application-managed approval responses, alongside third-party-server and data-control caveats. An application programming interface (API) application must own and implement its identity, approval, logging, and remote-server diligence; OpenAI API data controls do not dictate a third-party MCP server’s retention or residency. [official source 1]

Documented point: As reviewed on 2 October 2026, ChatGPT Business is separate from the API platform and API usage is separately billed; the Business workspace requires at least two seats and displayed seat prices vary by country and currency. Business seats are not API credits or a permanent price commitment. Current pricing and the account contract govern a real purchase. [official source 1]

Your team has one authorised data source or tool: perhaps a customer relationship management system, a document repository, a codebase utility or a remote service exposed through Model Context Protocol. The immediate question is not which model to use. It is where the integration should live, whose permissions should govern it and who will operate its controls. The five candidate surfaces in this guide are an existing ChatGPT app, Company Knowledge, a custom remote MCP app in ChatGPT, Codex MCP and an application-owned Responses API integration.

Apply the smallest appropriate surface rule: choose the least expansive surface that places the work where its intended user already works, uses the correct authoritative identity, exposes only the required read or action capability, and has a named owner for approvals and operation. Do not introduce custom MCP infrastructure when an approved existing app can perform the authorised read. Do not place a repository-local utility in a general ChatGPT workspace when it belongs in a developer’s Codex project. Do not adopt the Responses API merely because a ChatGPT subscription exists; use it when the organisation must own the customer experience, identity, approval flow, orchestration and API billing.

This is a lane-selection rule, not a claim that the smallest surface is always the cheapest or easiest. A narrower existing app can reduce implementation ownership but leave capability and availability dependent on the app provider and the user’s ChatGPT context. An application-owned integration provides more control over the experience but transfers more operational responsibility to the application team. The correct decision is the narrowest lane that still meets the task’s authority, control and deployment requirements.

The decision in one page

Live-tenant verification of each surface’s actual availability, plan, region, admin settings, data permissions and supported actions is required before a team commits to an integration. A documentation example does not grant access in a reader’s account.

Start by describing a single authorised task rather than asking for “integration with” an entire service. “Let sales staff find source-linked account guidance” is bounded. “Connect the whole company drive” is not: it leaves the intended users, source permissions, required actions and operating owner unspecified. Likewise, “let a developer run a repository-local test utility” is more useful than “add MCP”, because MCP describes a protocol rather than the proper user surface or authority.

For the scorecard below, an authoritative principal is the person, service or application identity whose permissions decide what the tool may access. The approval owner decides whether access or a consequential action is permitted. The operating owner maintains credentials, tool definitions, logs, provider dependencies and incident procedures after launch. Those roles may belong to different teams and should not be collapsed into “the technology team owns it”.

Integration Surface Scorecard
Surface and user location	Authoritative principal and tool location	Suitable task shape	Approval owner and operating owner	Decisive rejection condition
Existing ChatGPT app Individual or workspace user in a ChatGPT conversation.	The user authorises the provider account, subject to source permissions and any workspace restrictions. The app is supplied through ChatGPT and its provider rather than deployed as the customer’s local process.	Conversational search, retrieval, summarisation, source use, interactive experiences or supported actions already offered by an approved app. Prefer this lane when existing capability meets the bounded task.	The user and workspace administrator govern permitted use; the app provider operates its external service. A source owner should confirm that the requested data is authorised.	Reject if the necessary app, capability or authorisation is unavailable for the exact plan, region, workspace, role, model or interface, or if the provider’s terms and data handling are unacceptable.
Company Knowledge Eligible member asking organisation-specific questions in a managed ChatGPT workspace.	The connected source’s existing permissions remain authoritative. Company Knowledge operates through supported sources and the managed workspace; it is not a universal copy of company data.	Finding and synthesising organisation knowledge with source links for review, where each user should see only material already available to that user.	Workspace administrators enable the relevant capability and source; source-system administrators and data owners retain responsibility for underlying access. A knowledge owner should review source coverage and quality.	Reject if the task requires a customer-facing experience, an unsupported source, broad access beyond existing source permissions, or consequential write operations rather than knowledge answering.
Custom remote MCP app in ChatGPT Managed-workspace user invoking a bespoke tool in ChatGPT.	The remote MCP service and its authentication determine source authority, while workspace publication controls who can use the app. The server is remote; it is not the same deployment as a local Codex process.	A vetted, user-facing tool absent from the existing app catalogue, especially where ChatGPT is the intended interaction surface. Read-only, minimum-data tools are the safer starting shape; write capability requires a separate gate.	A named workspace administrator or owner vets and publishes it. The service team operates the remote server, credentials and tool contract. Security, privacy and source owners review consequential scope.	Reject if no team will operate the remote service, if local-only execution is required, or if beta or tenant-dependent capability cannot meet production requirements.
Codex MCP Developer working in Codex desktop, command-line interface or integrated development environment on a Codex host.	The developer’s local or remote MCP configuration and project context govern use. Codex supports local standard input/output servers and streamable Hypertext Transfer Protocol (HTTP) servers; configuration can be scoped to a trusted project.	Repository-local development utilities, code-related retrieval or developer tools that benefit from terminal, project or local-process context, with explicit tool allow/deny and approval choices.	The developer or engineering team approves project use; the repository or platform owner defines permitted tools. The engineering team operates local configuration and any remote service.	Reject if the intended users are general ChatGPT members or external customers, or if the organisation requires a centrally published ChatGPT app rather than developer-host configuration.
Responses API with remote MCP Employee or customer uses the organisation’s own application or workflow.	The application owns user identity, policy and state; the remote MCP server enforces its own credentials and source access. API Platform membership and billing are separate from ChatGPT workspaces.	Programmatic products and workflows requiring an organisation-owned interface, identity mapping, orchestration, approval experience, logging and tool policy.	The application owner implements approval handling and logging. API, source, security, privacy and service owners must agree the control boundary and remote-server diligence.	Reject if the team cannot own identity, approval, audit, billing and service operations, or if an existing authorised ChatGPT surface already satisfies the task without application development.

Use a decisive rejection condition before comparing secondary conveniences. For example, a customer-facing workflow rejects all user-in-ChatGPT lanes even if they can reach the same source, because the company’s customer is not meant to enter a managed ChatGPT conversation. A repository-local utility rejects Company Knowledge because its job is to act in a trusted development project, not answer organisation-wide knowledge questions. This procedure prevents a familiar feature or existing subscription from overriding the actual deployment requirement.

Four distinctions that stop category errors

Capability: what the surface can do

A capability is a function documented for a surface, such as searching through an app, answering from supported company sources, exposing an MCP tool, starting a local standard input/output process or handling a remote MCP approval in an API application. Capability alone does not show that a particular user can use it. It also does not establish who can authorise the underlying source.

For example, the official Connected apps in ChatGPT Help Centre article, checked on 2 October 2026, documents that app availability depends on the app, plan, region, workspace, role, model and interface. That does not mean every app offers every function. The practical test is: write down the exact operation—such as “search approved account guidance and return source links”—then confirm that the particular app documents that operation. Reject the lane if the task depends on an unsupported action rather than assuming that “connected” means full access.

Entitlement: whether this account and context expose it

An entitlement is the right or technical eligibility to use a capability in the exact live context. According to OpenAI’s connected-app documentation as checked on 2 October 2026, availability can depend on the app, ChatGPT plan, region, workspace, role, model and interface. Provider authorisation and workspace permission are additional gates. An app permission does not grant new rights in the source system.

The decision rule is therefore: never turn documentation-level capability into a procurement assumption. Test entitlement in the intended tenant, with the intended role and client, before approving a lane. If a pilot administrator can see an app but the intended user cannot, record an entitlement failure; do not infer that buying a different unrelated membership will resolve it.

Deployment: where the tool actually runs

Deployment identifies the operational home of the integration. An existing ChatGPT app depends on the app supplied through ChatGPT and its provider. Company Knowledge works through supported sources in a managed workspace. A custom ChatGPT MCP app relies on a remote MCP service. Codex can use a local standard input/output server or a streamable HTTP server from its host configuration. A Responses API application calls a remote MCP server as part of an application-owned workflow.

This distinction decides who must patch, monitor and recover the integration. A local Codex MCP configuration is not automatically a workspace-published ChatGPT app. Conversely, a remote app published for ChatGPT users is not a repository-local process merely because both use MCP. If the team cannot name the runtime, service owner and credential store, the deployment design is not ready for selection.

Commercial membership: which product relationship pays for and admits the user

Commercial membership concerns seats, workspace membership, API organisation membership and separate billing—not the abstract capability. OpenAI’s ChatGPT Business overview, checked on 2 October 2026, states that ChatGPT Business is separate from the API Platform and that API usage is billed separately. It also documents a minimum of two Business seats. OpenAI’s Enterprise documentation likewise treats ChatGPT workspace membership and API Platform organisation membership as separate systems: a person may belong to either or both.

A Business seat is not an API credit. A ChatGPT Enterprise workspace does not automatically place its members in an API organisation. API organisation membership does not automatically grant access to a managed ChatGPT workspace. Codex access or configuration must also be assessed in its documented host and workspace context rather than treated as a bridge between these systems.

The procurement procedure is simple: create one line item for the user-facing membership and another for any API organisation, budget and billing account. Record the named owner of each. If the proposed business case says “we already pay for ChatGPT, so the API is included”, stop and correct it before evaluating implementation.

For a separate application-cost evaluation rather than a combined subscription ledger, GPT-6 Sol and Luna rollout experiment metrics describes a proposed shadow-traffic test that records usage, latency, cached tokens, and estimated task costs. The protocol does not equate ChatGPT subscriptions, Codex access, and API billing; verify each account’s real usage controls separately.

Keep the four commercial and operating domains separate

Domain	Typical user context	What membership establishes	What it does not establish	Verification action
Consumer ChatGPT	An individual using their own ChatGPT account and settings.	Access to features available for that account, plan, region, model and interface.	It does not establish managed-workspace approval, Company Knowledge access, API organisation membership or rights to data in a third-party provider.	Check the intended account, app availability, provider authorisation and consumer data settings. Do not place organisational secrets into an unmanaged prompt.
Managed ChatGPT workspace	Business, Enterprise or Education member operating under workspace settings.	A seat and role in that workspace, subject to its enabled features and controls.	It does not create access to every app, every source, full MCP, API credits or API organisation membership. Workspace approval cannot enlarge source-system permissions.	Have an administrator verify the exact user role, source, app, model, interface and rollout state in the live tenant.
Codex host	Developer using a supported Codex client with host and project configuration.	Access to the Codex functions and limits available in that context.	It does not publish a local MCP server to ChatGPT, confer general workspace access or create API Platform membership. Hosted and local capabilities can differ.	Confirm the intended client, trusted project scope, server transport, permitted tools and approval mode on the actual host.
API Platform	Developers and applications operating within an API organisation and project.	Separately governed API access, project controls and billing.	It does not provide a ChatGPT seat, reproduce ChatGPT’s interface approvals or dictate a third-party MCP server’s retention and residency.	Verify organisation and project membership, billing ownership, data controls, endpoint eligibility and the application’s approval and logging design.

Do not use “OpenAI account” as the sole evidence of access. Ask which account, organisation, workspace, project and host are involved. This matters when the same employee uses consumer ChatGPT, a company workspace, Codex and an API project: those contexts may have different administrators, policies, source credentials and records.

Name the five surfaces precisely

1. Existing ChatGPT app

An existing ChatGPT app connects an available provider experience to a ChatGPT conversation. Depending on the particular app, it may support search, source retrieval, summaries, an interactive experience or actions. It is the first lane to inspect for a conversational task because it avoids creating a bespoke tool when supported capability already exists.

Its limiting principle is inherited authority. Enabling or selecting an app does not grant source permissions the user lacks. The provider may require separate authorisation, and data shared with the app is also subject to that app’s terms and privacy policy. Choose this lane only after the source owner confirms that individual authorisation is appropriate and the app’s documented scope is sufficient. Reject it when the workflow needs company-owned customer identity or when the external app’s handling is incompatible with the intended data.

2. Company Knowledge

Company Knowledge is a managed ChatGPT knowledge-answering surface for organisation-specific information from supported sources. OpenAI’s Help Centre documentation, checked on 2 October 2026, describes it for Business, Enterprise and Education where the plugin, a supported source and necessary app or administrator authorisation are available. It respects existing permissions in connected sources; readers should check the source record and permissions before relying on the answer.

It is not a universal corporate index, an automatic connection to every provider account or a means to override source access. The fitting task is “help authorised members answer questions from material they can already access”, not “make all company information visible to everyone”. If the task is to mutate records, serve customers through the company’s own product or invoke a local development tool, reject Company Knowledge even if the source itself is supported.

3. Custom remote MCP app in ChatGPT

A custom ChatGPT MCP app puts a bespoke remote tool into the ChatGPT user experience. It is appropriate only when the managed workspace needs that user-facing capability and no approved existing app provides the bounded operation.

OpenAI’s developer-mode Help Centre material, checked on 2 October 2026, describes full MCP, including modify and write actions, with beta and tenant-dependent language for Business, Enterprise and Education. It also describes workspace vetting and publication by administrators or owners, with role-based access control and action controls documented for Enterprise and Education. Other OpenAI documentation makes plan and capability distinctions. Do not flatten those differences into an evergreen entitlement table: inspect the live tenant.

A write-capable tool must pass a separate decision gate from a read tool. Human reviewers must approve security, privacy, financial, employment, government and other consequential actions. Workspace publication and user confirmation do not eliminate prompt-injection risk or the possibility of an erroneous or harmful write. Keep untrusted data and secrets out of prompts, minimise tool inputs and reject the lane if source content can steer an unsafe action without adequate isolation and review.

4. Codex MCP

Codex MCP places tools in a developer’s Codex work context. OpenAI’s Codex MCP documentation, checked on 2 October 2026, states that Codex desktop, the command-line interface and integrated development environment extension can share MCP configuration on the same host. It supports local standard input/output servers and streamable HTTP servers, together with project scope, tool allow/deny lists and approval controls.

This is the fitting lane when the utility belongs beside a trusted repository, terminal or development process. Its benefit is contextual fit, not portability to other OpenAI products. Select tools explicitly and scope them to the trusted project. Reject Codex MCP when non-developers need a centrally managed conversational app or when customers must use the capability through the organisation’s product.

5. Application-owned Responses API MCP integration

This surface belongs to an organisation building and operating its own application or workflow. The application uses the Responses API and can permit a model to call a remote MCP server. OpenAI’s connector and remote MCP guide, checked on 2 October 2026, says approval is requested by default before data is shared with a connector or remote MCP server and documents application-managed approval responses and tool restrictions.

The application team owns the parts that ChatGPT would otherwise supply: user interface, user identity, authorisation mapping, approval interaction, application state, orchestration, logging, billing and error handling. It must also assess the remote MCP server. OpenAI API controls do not determine that third party’s retention, residency or downstream handling.

Select this lane when those responsibilities are requirements rather than accidental implementation work. Reject it if the sole need is an employee’s authorised conversational lookup that an existing ChatGPT app or Company Knowledge already satisfies. Conversely, do not force customers into an employee workspace merely to avoid building the identity and approval layer a customer-facing product requires.

Once your team has deliberately chosen an application-owned integration, The Complete ChatGPT API Integration Masterclass: Building Production Applications with the Responses API in 2026 examines production patterns for Responses API authentication, streaming, function calling, schemas, error handling, deployment, and observability. Its examples reflect July 2026 SDK conventions, so verify current API behaviour before implementation.

The four-question decision sequence

Question 1: Where does the work occur?

Write down the intended user, not merely the integration owner.
Name the place where that user should complete the task: ChatGPT conversation, managed knowledge session, developer repository or company application.
Reject surfaces that require the user to move into an inappropriate product or account context.

If an employee already works conversationally and needs an available app’s supported search, begin with that app. If a managed-workspace member needs organisation knowledge across supported authorised sources, assess Company Knowledge. If a developer needs repository-local tooling, assess Codex MCP. If a customer must remain in the company’s application, assess the Responses API. Consider a custom ChatGPT MCP app only when ChatGPT is the correct location but the required remote tool is absent from the approved app set.

Question 2: Whose permissions govern?

Identify the source-system principal: individual user, workspace-connected identity, developer or application service identity.
Confirm that this principal has only the required source rights.
Separate source authorisation from permission to invoke the tool in ChatGPT, Codex or the application.
Reject any design that relies on a broad shared credential merely to avoid proper identity mapping.

An app can be allowed in a workspace while a user remains unable to read a particular document. That is correct behaviour, not an integration fault. Equally, a remote MCP server may possess a powerful service credential even when its ChatGPT audience is narrow. The invocation audience and source authority must both be reviewed; controlling only one leaves an unexamined path.

Question 3: Is read/search enough, or is consequential action required?

Describe the minimum verb. “Find”, “summarise” and “cite” usually point towards a read/search lane. “Change”, “send”, “approve”, “delete”, “merge” and “purchase” indicate actions with external consequences. Do not select full MCP merely because it can write if the accepted task is retrieval.

For a write requirement, document the proposed parameters, affected system, preview, confirmation point, audit record and recovery path. Require human review for actions affecting security, privacy, money, employment, government services, health or other consequential interests. If the team cannot provide a meaningful confirmation that shows what will happen, retain a read-only lane or reject the integration.

Question 4: Who owns controls after launch?

Name people or teams for five duties: source access, surface administration, runtime operation, approval policy and incident response. Then ask who rotates credentials, reviews changed tool definitions, monitors provider availability, handles revoked access and preserves the necessary records. “The vendor” is not a complete answer where the organisation still configures identities or approves actions.

The public OpenAI status page can inform a rollout check, but its aggregate status does not prove availability for a particular tier, model or feature. At launch, check the status page and the live tenant; do not convert a healthy snapshot into an uptime guarantee.

Three compact worked examples

Sales knowledge lookup

Bounded task: authorised sales staff need source-linked answers from account guidance they can already read. The work occurs in the managed ChatGPT workspace; existing source permissions should govern; retrieval is sufficient; workspace and source administrators can own access.

Provisional lane: Company Knowledge, if the source and plugin are available in the live tenant. An existing ChatGPT app may instead be smaller when there is one approved source and its search capability fully meets the task. Reject a custom MCP app unless a required function is genuinely absent. Reject the Responses API unless this lookup must be embedded in a company-owned customer or employee application. Example acceptance evidence would include a user seeing permitted source links while a deliberately unauthorised document remains unavailable; this is a suggested check, not a guaranteed product result.

Repository-local developer utility

Bounded task: developers need a trusted project tool to inspect repository metadata and invoke a local read-only utility. The work occurs in Codex beside the repository; developer and project permissions govern; local execution is intentional; engineering owns configuration and review.

Provisional lane: Codex MCP with project scope, a minimal allow-list and an explicit approval policy. A local standard input/output server fits the deployment shape described by the Codex documentation. Reject Company Knowledge because this is not organisation knowledge answering. Reject a custom ChatGPT MCP app because local Codex configuration is not a workspace-published ChatGPT app. If the utility later becomes a service for non-developers, restart the decision rather than treating the local configuration as portable.

Customer-facing workflow

Bounded task: customers use the company’s portal to retrieve an account-specific record and may submit a consequential change after reviewing it. The customer must remain in the portal; the application’s identity and policy layer govern; the company must own the confirmation screen, logs and recovery process.

Provisional lane: an application-owned Responses API integration with a remote MCP service, provided the API organisation, budget, identity mapping and remote-server diligence are separately approved. The application should restrict tools and implement the approval response rather than expecting ChatGPT’s interface to appear in the portal. Human review is required where the change has consequential effects. Reject an employee ChatGPT app even if it reaches the same source: the authoritative principal, user location and operating owner are different.

Facts to verify in the live tenant

The exact app or plugin appears for the intended account, workspace, role, region, model and interface.
The provider permits the intended user to authorise the source, and the provider’s current terms and privacy policy are acceptable.
The app exposes the required operation; do not infer write capability from search capability.
Company Knowledge is enabled, the intended source is supported and each user’s source account is properly connected where required.
A Company Knowledge result supplies reviewable source links and does not imply access beyond the user’s existing source permissions.
The tenant’s actual developer-mode and full-MCP capability matches current documentation. Treat beta, rollout and plan language as volatile.
The named administrator or owner can vet and publish a custom ChatGPT app, and the intended audience can actually access it.
The Codex client and host support the intended local or HTTP server configuration, project scope, tool list and approval behaviour.
The API user belongs to the correct API organisation and project; billing ownership is recorded separately from ChatGPT seats.
The Responses API application implements its own identity, approval, logging and state handling.
The remote MCP server’s retention, residency, authentication and incident arrangements have been reviewed independently of OpenAI’s API controls.
No claim of “not used for training by default” has been rewritten as zero retention, Zero Data Retention, guaranteed residency or blanket compliance. OpenAI’s API data documentation describes default abuse-monitoring retention of up to 30 days and makes Zero Data Retention and Modified Abuse Monitoring subject to approval and feature or endpoint caveats.
Untrusted source content and secrets are kept out of prompts wherever they are not strictly necessary. Tool inputs are minimised, and indirect prompt-injection exposure is reviewed.
Security, privacy, financial, employment, government and other consequential decisions retain an accountable human reviewer.
Current OpenAI documentation, contract terms, tenant access and service status are rechecked at rollout.

The most volatile phrases are “available”, “included”, “supports”, “beta”, “rollout”, “limits” and plan or role labels. In this guide, product statements reflect official material checked on 2 October 2026. They are not permanent guarantees. Recheck the live tenant and current first-party documentation before publication, procurement and launch.

Record a provisional lane, not a purchase recommendation

Complete the first pass with one sentence: “For named user performing bounded task in location, governed by authoritative principal, requiring read or action scope, and operated by named owner, the provisional lane is surface; reject it if decisive condition fails.”

Examples are: Company Knowledge for permission-respecting sales lookup, subject to supported-source and tenant verification; Codex MCP for a trusted repository-local developer utility, subject to project and tool controls; and the Responses API for a customer-facing workflow, subject to separate API ownership and an implemented approval loop. This records the lane that deserves deeper validation. It does not recommend a subscription, promise entitlement or authorise data access.

Existing ChatGPT apps and Company Knowledge: use the supplied lane before building one

The first lane contains two related but distinct choices. An existing ChatGPT app connects a supported third-party service to conversations. Confirm the particular app’s documented functions and permissions in the intended account rather than treating every possible capability as universal. Company Knowledge is a managed-workspace feature for answering organisation-specific questions from supported, authorised sources. Both keep the user in ChatGPT, but they solve different problems and have different prerequisites.

Decision rule: choose an existing app when one approved source is sufficient and the app already supplies the required read or action capability. Consider Company Knowledge when eligible managed-workspace members need source-linked answers across organisation material available through supported sources. Do not build a custom MCP app merely to reproduce an existing, adequate read/search integration.

These are conditional choices, not features that follow automatically from having a ChatGPT subscription. OpenAI’s connected-apps Help Centre article, opened on 2 October 2026, says availability can depend on the particular app, ChatGPT plan, region, workspace, role, model and interface. A procurement list that says only “the team has ChatGPT” therefore omits several independent gates.

Separate availability, workspace permission and source authorisation

Begin by checking three conditions for an existing app. First, establish whether the app is exposed in the intended account, workspace, region, model and client. Secondly, establish whether workspace policy permits that app for the relevant users. Thirdly, establish whether each user or service identity can lawfully authorise the underlying provider account. Passing one check does not imply that the others pass.

Product exposure: confirm that the exact app and capability appear in the intended live tenant and interface. Do not infer this from another plan, role or user’s account.
Workspace permission: obtain the applicable workspace approval where the workspace controls which apps members may use.
Provider authority: authorise only an account whose existing source permissions match the intended task.
Capability check: distinguish search and retrieval from actions. An app being present does not prove that every operation described by its provider is available in the chosen ChatGPT context.
Terms and data review: review the particular app’s terms and privacy policy before sending data to it.

The important authority rule is simple: an app setting can govern when ChatGPT may use an app, but it cannot create access inside the source service. If a user cannot open a restricted document in the provider’s own service, enabling or selecting the app must not be treated as a way to obtain that document. Conversely, broad provider credentials should not be justified merely because the initial prompt asks for a narrow result.

Example: suppose a sales manager needs summaries from an authorised document repository. If a supported ChatGPT app is available, the workspace permits it and the manager’s provider identity can access the relevant folder, the existing app is the smallest candidate. It should be rejected if the required repository is unsupported, the live tenant does not expose the app, workspace policy blocks it, or the only available authorisation would grant materially broader access than the task requires.

This procedure also prevents a common category error: workspace approval is not provider authorisation. An administrator may permit members to use an app without giving those members rights to every item in the connected service. Equally, a user’s ability to authorise a provider account does not override a managed workspace’s decision to disable the app.

Apply a context and data-handling test before routine use

Connected-app decisions require a separate context and permission review. Check what conversational context may accompany a particular app request in the intended workspace, and verify the current product and provider documentation before routine use. Do not assume that a source permission automatically authorises combining records from different contexts.

A practical review should classify both the source data and the surrounding conversation. Keep secrets, credentials, private keys and untrusted data that is not needed for the task out of prompts. Do not paste a larger record set simply to make retrieval easier. If a conversation already contains unrelated confidential material, start from a context appropriate to the task rather than assuming app authorisation isolates every piece of conversational information.

Data-handling terms differ across accounts, providers and connection types. Before sending any record, verify the current terms and controls for the specific account, app and provider; do not infer zero retention, a particular residency arrangement or universal compliance from a product name. The provider’s own terms remain relevant when data is shared with that app.

Decision rule: reject the existing-app route if the team cannot explain which identity supplies source access, which information may enter the conversation, which third party receives data and which current terms govern that transfer. Convenience is not a substitute for a documented data boundary.

Layered gates separate an individual key, an administrator checkpoint, a local project boundary, an application policy hub, and an external service boundary. — Authorisation is layered rather than transferable: provider access, workspace policy, local configuration, application approval, and third-party handling remain separate decisions.

Company Knowledge is source-respecting answering, not universal indexing

Company Knowledge deserves a separate evaluation because it is not merely a synonym for connecting one app. OpenAI’s Company Knowledge Help Centre article, opened on 2 October 2026, documents it for Business, Enterprise and Education workspaces when the plugin is enabled, at least one supported source is available, and the necessary app or administrator authorisation is in place. Those prerequisites are cumulative. A workspace label alone does not establish live access.

The feature is designed to answer organisation-specific questions from connected sources while respecting the permissions already present in those sources. “Respects permissions” means the source’s access model remains authoritative; it does not mean that Company Knowledge becomes a new organisation-wide entitlement service. A member should receive answers based on material that the connected identity may access, not everything the employer stores.

Use this assessment:

Confirm the managed-workspace prerequisite. Verify the exact Business, Enterprise or Education tenant rather than a personal account with a similar email address.
Confirm that Company Knowledge is enabled. Do not infer enablement from the presence of ordinary connected apps.
Identify supported sources. Record which source is expected to answer each question rather than referring vaguely to “company data”.
Map source identities. Document whether access depends on each member’s provider connection, administrator authorisation or another supported arrangement described for that source.
Review source links. Treat linked evidence as material for verification, not decorative citation.

Source-link review is particularly important when an answer will inform a consequential decision. The reviewer should open the cited material, confirm that it supports the stated conclusion, check whether it is current and determine whether the answer has omitted a relevant restriction. For security, privacy, money, employment, government, healthcare and other consequential matters, a qualified human must review the underlying sources and retain decision responsibility.

Example: an employee asks, “What is our current travel approval policy for international conferences?” A suitable Company Knowledge result would direct the employee to authorised organisational material and provide links that can be checked. The employee should inspect the policy date, scope and exceptions before booking. Company Knowledge should not be represented as having certified that every policy repository was searched or that the answer overrides the organisation’s formal approval process.

Plugin installation must not be described as universal account connection. Enabling the Company Knowledge plugin does not, by itself, authorise every provider account, expose every repository or index every item held by the organisation. This distinction matters in federated companies where departments use separate accounts, inherited access groups or repositories with materially different retention and confidentiality rules.

Nor should “Company Knowledge” be interpreted as a conventional enterprise indexing project whose operator copies all corporate content into one exhaustive corpus. The official description supports source-respecting answers from supported, connected material. It does not support a promise of complete discovery, universal synchronisation or coverage of unsupported systems.

Trade-off: Company Knowledge can offer a more organisation-oriented answering experience than selecting one app ad hoc, but it remains bounded by eligible workspace access, supported sources, authorisation and source permissions. If the requirement is to execute a proprietary workflow, expose a source that has no supported connection or impose custom action semantics, this lane may be too small. If source-linked read answers are sufficient, those limitations are a reason to prefer it over a bespoke write-capable service.

For a concrete interface-migration audit, custom GPT plugin portability audit inventories instructions, files, apps, actions, access dependencies, and acceptance checks. It does not show that a Custom GPT becomes a Codex MCP server or carries over workspace entitlements; verify both surfaces in the actual tenant.

Custom remote MCP apps in ChatGPT developer mode: a managed publication lane

A custom ChatGPT MCP app is appropriate when managed-workspace users need a ChatGPT-facing tool that the existing app catalogue and Company Knowledge do not supply. MCP is a protocol through which a host can discover and invoke tools exposed by a server. The protocol name does not decide where that server runs, who may publish it, what credentials it uses or whether it may write.

OpenAI’s developer-mode Help Centre guidance, opened on 2 October 2026, describes full MCP support including modify or write actions as a beta capability for Business, Enterprise and Education, with custom apps vetted and published by workspace administrators or owners. It also describes role-based access control and action controls for Enterprise and Education. The associated documentation contains plan and surface distinctions and beta language. Because those descriptions should not be flattened into a permanent entitlement table, a team must verify the exact live tenant, role and supported capability before making a purchase or launch commitment.

Treat vet, test and publish as distinct governance decisions

The managed path has three conceptual stages. These are selection and governance gates, not setup instructions.

Vet: identify the server operator, its data practices, authentication model, exposed tools and source systems. Review each tool’s input, output and authority. A recognised developer name is not enough if the connected source can contain malicious or untrusted instructions.
Test privately: expose the smallest useful read-only tool set to designated reviewers. Use representative but non-secret data and verify the intended authorisation boundary in the live tenant.
Publish deliberately: a named administrator or owner decides which workspace population may use the app and under which controls. Publication should follow acceptance of the tool definitions and operating owner, not merely successful connectivity.

This path differs materially from an individual user authorising an existing provider app. The organisation is introducing a custom remote service into a managed ChatGPT surface and must own the server-side consequences. Workspace publication does not prove that the tool’s implementation is safe, that its returned content is trustworthy or that every requested action is appropriate.

Respect the remote-server and private-network boundary

ChatGPT custom MCP and Codex MCP are not interchangeable because their server boundaries differ. This guide treats the ChatGPT custom MCP lane as a remote-server lane; verify current developer-mode documentation and the intended tenant before assuming local or private-network connectivity. Private-network reachability requires a separate review against current documentation and organisational network requirements. A local-only utility that communicates through standard input/output is therefore not automatically a candidate for ChatGPT publication.

Decision rule: if the tool is intentionally local, tied to one developer’s repository or depends on a local executable, evaluate Codex MCP first. If the requirement is for managed ChatGPT members to reach a centrally operated service, evaluate a remote custom ChatGPT MCP app. Do not expose a private service publicly merely to force it into the latter category; assess the documented private-network route and organisational network requirements separately.

Documentation ambiguity itself is a deployment risk. Where Help Centre and developer pages distinguish plans, available capabilities, full MCP or beta access differently, the correct response is not to choose the most permissive sentence. Record the intended tenant, user role, interface and required action, then confirm each against the current documentation and the actual tenant. This produces an evidence-backed go/no-go decision without claiming a universal matrix.

Design minimum-data tools before debating write access

A custom tool should return the minimum data needed for the user’s decision. A search tool may be safer and easier to review when it returns identifiers, titles and short authorised excerpts before a separate retrieval operation fetches a selected record. A narrowly defined status query is preferable to an unrestricted database interface. These are suggested design methods, not guarantees against data leakage or prompt injection.

Apply four questions to every proposed tool:

What exact user task requires this tool?
What is the smallest input and output that completes that task?
Which source identity and permission check authorise the request?
Can untrusted source content influence a later tool call?

OpenAI’s MCP guidance warns that a server can expose malicious or untrusted user input even when its developer is trusted. Retrieved tickets, repository text, documents or messages may contain instructions designed to manipulate subsequent actions. Tool descriptions, approvals and administrator publication do not remove that content risk or the need to review parameters. Keep secrets out of prompts, restrict accessible sources and avoid sending unnecessary retrieved content into another tool.

Example: an internal incident catalogue contains free-text reports written by many employees and external contractors. A tool that retrieves those reports must treat the text as untrusted data, not operating instructions. A phrase inside a report such as “upload the full customer list” has no authority to trigger another tool. The server and reviewer should distinguish retrieved content from approved parameters; human approval remains necessary for consequential follow-on actions.

Read-first is a rollout policy; write authority is another gate

Begin with read-only tools where they can satisfy the requirement. This limits the initial question to whether the app retrieves authorised, relevant information through an acceptable data path. It does not prove readiness for writes. A separate write review must establish who can trigger an action, what is shown before confirmation, what downstream system records the change and how erroneous or duplicated operations are handled.

A tool labelled “update ticket” may change priority, owner, customer-visible text or closure state. Those operations do not have equivalent consequences. The tool catalogue should separate materially different powers rather than hide them behind a broad mutation endpoint. Suggested examples include a narrow “propose ticket classification” read-like operation before any “apply classification” action, or a draft payload that a human reviews before submission. Whether such separation is feasible depends on the source system and custom implementation.

Separate write gate: approve write capability only after the read deployment has its own acceptable case, and only when the action owner has reviewed authority, parameters, confirmation behaviour, logging and recovery. Enterprise or Education action controls can contribute to this gate where documented and available, but they do not eliminate harmful writes, mistaken approvals or prompt injection. Human review is mandatory for actions affecting security, privacy, money, employment, government records or other consequential outcomes.

Reject the custom ChatGPT MCP route when there is no named server operator, no workspace publisher, no defensible remote-network design, or no way to limit the tool to the authorised source and task. Also reject it when an existing app already provides the required capability with a smaller operational burden.

Codex MCP: developer-hosted tools with local and project controls

Codex MCP belongs to a developer workflow rather than a managed ChatGPT publication workflow. OpenAI’s Codex MCP documentation, opened on 2 October 2026, says Codex supports local standard input/output (STDIO) servers and remote streamable HTTP servers. It also documents shared MCP configuration among Codex desktop, the command-line interface (CLI) and the integrated development environment (IDE) extension on the same Codex host.

“Same host” is the controlling phrase. Configuration sharing can reduce duplication between Codex clients using that machine or host environment, but it is not workspace publication and does not migrate configuration to ChatGPT web. A server listed for a local Codex CLI must not be described as an installed ChatGPT app. Hosted tools may also expose different capabilities from local clients.

Choose STDIO or streamable HTTP by operating boundary

A local STDIO server runs as a process with communication through standard input and output. It suits a tool whose intended boundary is the developer’s machine or project environment. A streamable HTTP server is reached over a network and introduces a remote endpoint, network authentication and server operation into the decision.

Decision rule: prefer local STDIO when local execution is intentional, the relevant resources are local and the team accepts the machine-level trust boundary. Prefer streamable HTTP when the tool must be centrally operated or shared independently of a local process. Do not call HTTP inherently safer or STDIO inherently private: each inherits the permissions, credentials and data exposure of its actual host and implementation.

Project scope matters because a developer may trust a tool for one repository but not for every project opened on the same machine. OpenAI documents project-scoped configuration. Confirm the relevant project trust and approval settings locally before allowing a tool to run. Use the narrowest suitable scope. A repository-specific build or code-navigation utility should not become globally available merely for convenience if its assumptions or commands are safe only in that repository.

Use allow lists, deny lists and approvals as separate controls

Codex documents tool allow and deny lists plus default and per-tool approval modes. These answer different questions:

Allow list: which tools from the server may be exposed at all?
Deny list: which discovered tools must remain unavailable?
Default approval mode: what confirmation behaviour applies unless a narrower rule overrides it?
Per-tool approval mode: which individual operations require different handling because their consequences differ?

A useful review starts by denying or omitting every tool that the project does not need. It then assigns approval behaviour according to consequence rather than server reputation. A read-only symbol lookup and a command that publishes artefacts should not inherit identical authority merely because the same MCP server exposes both.

Trusting a project or server is not approval of every output or operation. Repository content may be untrusted; build scripts may have side effects; retrieved issue text may contain indirect instructions. Review requested parameters and retain human control over consequential actions. Keep credentials and unrelated secrets out of prompts and tool arguments.

For a deliberately narrow control example, Configure Touch ID Verification for Codex MCP Requests: Permission Boundaries, Workspace Identity, Approval Evidence, and Recovery explains Touch ID verification for MCP requests in supported local macOS Codex TUI sessions, alongside workspace identity, approvals, server trust, and recovery. Treat it as version-specific: biometric presence is not portable authorisation or a policy decision.

Any client-specific approval or identity control discussed in adjacent material is evidence only for that documented client, platform and version. It must not be presented as proof that ChatGPT developer mode, another Codex host or an application using the Responses API supplies the same control.

Comparison: three user-facing and developer-hosted lanes

Decision dimension	Existing app or Company Knowledge	Custom ChatGPT MCP app	Codex MCP
Primary user location	ChatGPT conversation; Company Knowledge is for eligible managed-workspace knowledge questions.	ChatGPT in a managed publication context.	Developer workflow in Codex desktop, CLI or IDE on the same host.
Smallest suitable use	An existing approved integration supplies enough search, retrieval, source-linked answering or supported action capability.	A managed ChatGPT audience needs a custom remote tool unavailable through existing apps.	A developer needs local or remote tools in repository, terminal or IDE work.
Authoritative access	Provider authorisation and existing source permissions, plus applicable workspace permission.	Custom server identity and source checks, constrained by workspace publication and user access.	Local or remote server credentials and the developer host’s project and trust boundary.
Deployment boundary	Supported third-party app or supported Company Knowledge source.	Remote MCP service; private-network reachability requires separate review against current documentation and organisational network requirements.	Local STDIO process or streamable HTTP server.
Governance path	Check exposure, workspace permission, provider authorisation, terms and source links.	Named administrator or owner vets, tests and publishes; full MCP and writes remain tenant-dependent and documented as beta.	Configure the intended host and project; restrict tools and choose approval behaviour.
Main mistaken assumption	Enabling an app grants source access or Company Knowledge indexes everything.	Any subscriber can publish any local MCP server with write access.	A Codex configuration automatically appears as a ChatGPT app.
Reason to reject	No supported app/source, excessive authorisation, missing citations or unsuitable third-party terms.	No remote operating owner, no managed publication route or unnecessary write scope.	The intended users are non-developers in ChatGPT, or the tool requires workspace-wide publication rather than project-local use.

Worked rejection analysis: one internal engineering tool

Consider a proposed internal engineering tool that reads a checked-out repository, searches local build logs and can optionally restart a development service. The immediate user is a software developer working in an IDE. The repository and logs remain on the developer’s machine, and the restart command affects only that local development environment.

Existing ChatGPT app: reject. The requirement is not to query a supported third-party service through an existing conversational app. Moving local repository content to a broader provider integration would not be justified merely to avoid a local tool boundary. Reconsider only if the real requirement changes to a supported hosted source and its existing app supplies the necessary capability.

Company Knowledge: not a fit for this requirement. This is not an organisation-wide, source-linked knowledge question. Company Knowledge should not be stretched into a local process runner or represented as an index of each developer’s working tree. Even if design documents elsewhere could support a related knowledge question, they would be a separate use case.

Custom ChatGPT MCP app: reject for the stated requirement. The intended resources and effects are local. ChatGPT custom MCP is a remote-service publication lane, and exposing or tunnelling each workstation solely to recreate local IDE behaviour would add an operating and network boundary without serving the stated audience. It would also require managed vetting and publication that do not convert the local restart command into an appropriate workspace-wide action.

Codex MCP: provisional fit. Local STDIO matches the intended execution boundary, while project scope can keep the tool associated with the relevant repository. The team should expose only the repository search and local-log tools initially. It should place the restart operation behind a distinct approval policy rather than treating it as equivalent to reading a file.

The provisional choice is not an assurance that the tool is safe. Before adoption, a human owner should review which paths it can read, whether symbolic links or generated files expand that boundary, what commands the restart operation can execute and which credentials the local process inherits. Repository and log content must be treated as untrusted input. Secrets not required for the task should remain outside prompts and returned tool content.

Write rejection within the chosen surface: selecting Codex MCP does not require approving the restart tool. If repository search and log inspection satisfy the initial need, deploy only those read capabilities. Add the restart action only after a separate human review of parameters, approval mode and recovery. If restarting can affect shared infrastructure rather than a local development process, reject the local-action assumption and reassess the service boundary and accountable operator.

Portability conclusion: no part of this analysis establishes that the Codex configuration can be transferred to ChatGPT. A later request from support staff to use the same tool in ChatGPT creates a new selection decision: remote operation, managed publication, user identity, source permissions and action controls would all need to be evaluated again.

When the Responses API is the right lane

Choose the Responses API only when the organisation is building and operating its own product or workflow. In this lane, the user works in an interface controlled by the organisation rather than in ChatGPT or a local Codex host. The organisation therefore accepts responsibility for identity, user experience, orchestration, approvals, audit evidence, API billing, application state and diligence on every remote MCP server.

This is an ownership test, not a test of whether an engineer can make an API request. A team may need an application-owned surface when customers use its product, when employees work in an established internal portal, or when its policy engine must decide whether a proposed action may proceed. Conversely, the need to search one authorised source does not by itself justify an API application. An existing ChatGPT app, Company Knowledge or a locally configured Codex MCP server may meet that narrower requirement with less software and operational ownership.

As documented in OpenAI’s Responses API MCP guidance checked on 2 October 2026, the API can call a connector or remote MCP server when the model chooses an available tool. Approval is requested by default before data is shared with that connector or server, and the application can submit an approval response. The same guidance exposes application-managed choices including allowed tools and approval requirements. These mechanisms are building blocks: they do not supply the organisation’s identity model, approval interface, policy, evidence retention or downstream accountability.

Decision rule: select this lane only if the product must have an organisation-owned interface or policy path and the organisation can name owners for all of those controls. If the team expects ChatGPT to provide identity, confirmation screens, conversation management and workspace administration, it is describing a ChatGPT surface rather than an application-owned API integration.

A small read-only parcel moves through five controlled stations before reaching either an expansion path or a rejection return path. — A defensible pilot begins with narrow access and records evidence at each gate before a team expands authority or rejects the integration.

Apply the operating-ownership test before discussing implementation

Document the proposed integration in one sentence: “An authenticated user class may ask our application to use named tools against one authorised source, subject to named approval policy.” This forces the team to identify the principal—the person or service whose authority is being exercised—and prevents “the model can access it” from substituting for an access-control design.

Name the user population. Distinguish customers, employees, administrators and service identities. Do not treat possession of a ChatGPT seat, Codex access or API organisation membership as interchangeable proof of application authority.
Name the authoritative identity system. Decide how the application maps its signed-in user to source permissions. If a remote MCP server uses a shared credential, record that it is service authority rather than the individual user’s source authority.
List the minimum tools. Separate search, read and write operations. “Customer relationship management access” is too broad; “find an account by an approved identifier” and “change an account owner” have different consequences.
Assign approval ownership. State which proposals require a person, which may be decided by a policy, and which are forbidden. A default API approval request is not a complete organisational policy.
Assign evidence ownership. Specify which application component records the proposal, displayed parameters, decision, actor, execution response and review outcome.
Assign financial ownership. Identify the separately governed API organisation and budget. A ChatGPT workspace subscription does not provide API credits or API organisation access.
Assign server diligence. Name the owner who evaluates the remote MCP operator’s authentication, data handling, retention, residency, tool definitions and change process.

Example: an internal purchasing portal needs to let an authorised employee draft a request and, after review, submit it to a procurement system. The application-owned lane may fit because the existing portal must authenticate the employee, apply purchasing policy, display the proposed supplier and amount, collect the appropriate decision and preserve evidence. It does not fit merely because the procurement system can expose an MCP server. If employees can complete the actual requirement through an approved existing ChatGPT app with an adequate approval path, building another application may be unnecessary.

Design the approval sequence as an application feature

Do not assume that confirmation behaviour observed in ChatGPT will transfer to a Responses API application. The surfaces have different owners and user experiences. In an API product, the application must present, interpret and record the decision process it intends to rely on. OpenAI’s documented default approval request before sharing data with a connector or remote MCP server is an important boundary, but it does not decide whether a particular employee is authorised to disclose the data or perform the resulting action.

A reviewable conceptual sequence is:

Tool proposal. The system identifies a proposed tool call rather than executing it silently. Record the exact tool identity and the server to which it belongs. Reject a proposal for a tool outside the application’s current allow-list.
Parameter display. Show the reviewer the material parameters in understandable form. For a message action, that could include recipients, destination, subject and content; for a record update, the record identifier, fields and proposed values. Do not reduce the display to “allow tool”.
Human or policy decision. A person approves or rejects consequential work, or a documented policy makes a bounded decision for a low-risk class. The decision must be tied to the authenticated actor, current permissions and displayed proposal.
Application-recorded response. The application records the decision and sends the corresponding approval response through the API flow. The evidence should distinguish user approval, policy approval, rejection, expiry and technical failure rather than storing all non-executions as one state.
Execution. Only the approved proposal proceeds. If material parameters or the selected tool change, obtain a new decision rather than treating approval as transferable.
Result review. Present the actual result, including partial failure or an unexpected server response. For consequential writes, verify the downstream state rather than relying solely on a generated description of success.

Decision rule: require a fresh review whenever the destination, data scope, authority, monetary amount, affected subject or write effect changes. A prior approval may support an identical bounded operation only if the organisation has deliberately defined that policy; it should not become blanket consent for later model-selected actions.

Example approval display: “Proposed action: update account 4821. Field: account owner. Current value: Team North. Proposed value: Team West. Destination: the organisation’s approved customer-record server. Requested by: signed-in operations user.” This is an example of an application design, not a guarantee that the API or remote server will generate this wording. The application must obtain trustworthy current values and render the review itself.

Default approval requests and application-managed controls solve different problems

The Responses API MCP guide documents that approvals are requested by default before sharing data with a connector or remote MCP server. It also documents controls for limiting allowed tools and setting approval requirements. Treat allowed tools, approval requirements and approval responses as three distinct decisions.

Control	Question it answers	What it does not establish	Practical procedure
Allowed tools	Which tools may be considered in this application context?	That every permitted call is safe, necessary or authorised for every user	Start with the smallest named set, separate read from write and review the set whenever the server’s tool catalogue changes.
Approval requirement	Must a proposed call pause for an approval response?	Who may approve, what they must inspect or whether disclosure is lawful and appropriate	Map tool classes to human approval, bounded policy approval or prohibition. Keep consequential writes in the human-review class.
Approval response	Did the application permit or reject this specific proposal?	That parameters remained unchanged, execution succeeded or the downstream effect was correct	Bind the response to the proposal, record the actor and time, then compare the executed call and result with what was approved.

A broad allow-list with approval on every call creates reviewer burden and can encourage superficial clicking. A narrow allow-list with no approvals may still be unsuitable if even one permitted operation can disclose sensitive records or cause a consequential write. The preferable combination depends on tool impact: minimise the catalogue first, then apply approval to the residual risk rather than using confirmation as compensation for excessive capability.

Example: a support application may permit a tool that retrieves one case by an identifier already visible to the signed-in agent, while forbidding bulk case export. It may separately require review before sending a response to a customer. This separates retrieval scope from communication authority. It does not establish that customer data may be disclosed to any remote server; that question belongs to the data-boundary assessment.

Map the data boundary layer by layer

“The API does not train on our data by default” is not a complete data map. OpenAI documents that API Platform inputs and outputs are not used for model training by default. Its API data-controls documentation also states that abuse-monitoring logs are retained for up to 30 days by default. Zero Data Retention (ZDR) and Modified Abuse Monitoring require prior approval and are subject to feature and endpoint limitations. These statements concern eligible OpenAI API processing; they do not govern the application’s database, the source system, a remote MCP server or the effect of a downstream write.

Boundary layer	Authority or control	Evidence to collect	Failure to avoid
Source authorisation	The source system decides what the user or service credential may access.	Credential type, granted scopes, user-to-source mapping, source owner and revocation procedure	Assuming that an API tool grant creates source permission or narrows an over-privileged shared credential
OpenAI API controls	The API organisation’s approved data-control configuration governs eligible OpenAI processing.	Current organisation setting, eligible endpoints and features, contract record, documented retention mode and date checked	Equating non-training with no retention, or assuming ZDR applies before approval and compatibility have been verified
Application state	The organisation controls its prompts, request records, approval evidence, caches, transcripts and operational logs.	Data inventory, purpose, access rules, retention schedule, deletion path and logging redaction rules	Claiming ZDR while retaining the same sensitive content indefinitely in application logs or analytics
Remote MCP server	The server operator controls its own receipt, processing, logs, subprocessors, retention and residency unless contractually constrained.	Operator identity, server endpoint, terms, privacy documentation, retention, residency, authentication and incident contact	Assuming an OpenAI API setting controls a third-party server
Downstream write effects	The destination system determines the durable business effect and available reversal mechanisms.	Before-and-after values, transaction or record identifier, approving actor, execution response and recovery procedure	Treating an accepted tool call as proof of a correct, complete or reversible outcome

Use this table as a release gate. For every row, name an accountable owner and attach current evidence. If the team cannot determine where the remote MCP server retains requests, it has an unresolved boundary rather than ZDR coverage. If the source uses a shared service account, record the resulting authority explicitly instead of presenting the action as user-scoped.

Interpret non-training, retention and ZDR narrowly

Four terms must remain separate:

Non-training by default means OpenAI says API inputs and outputs are not used to train its models by default. It is not a statement that no data is retained or processed.
Default abuse monitoring concerns logs retained for up to 30 days under the documented API default. It is distinct from the application’s own logs and the remote server’s records.
Modified Abuse Monitoring is a separately approved control with eligibility and implementation conditions. Do not present it as an automatic setting available to every organisation or compatible with every feature.
Zero Data Retention is also subject to prior approval and endpoint or feature limitations. Its name must not be extended to components outside the eligible OpenAI API boundary.

Before selecting a data-control posture, inventory every API endpoint and feature the proposed workflow will use and compare that inventory with OpenAI’s current data-controls documentation and the organisation’s approved configuration. Repeat this compatibility check when the design changes. Do not infer coverage from an approval applying elsewhere in the organisation.

Decision rule: if the business requirement says that no intermediary may retain specified data, the team must validate that condition independently for the OpenAI API, its own application and every remote MCP or downstream service. One compliant layer cannot cure an unknown or incompatible layer.

Example: an application approved for ZDR sends a customer document to a third-party remote MCP server for retrieval or processing. The OpenAI API control does not determine whether that server stores the document, records request parameters, uses another region or keeps operational backups. The application owner must assess those behaviours separately. If they cannot be reconciled with the requirement, reject that server or redesign the workflow; do not cite API ZDR as blanket coverage.

Gate the design against indirect prompt injection

Indirect prompt injection occurs when content retrieved from a source contains instructions intended to manipulate the model or its tool use. OpenAI’s MCP safety guidance warns that trusting the server developer is not sufficient when accessible content can contain malicious or untrusted user input. A trusted document repository can still contain an untrusted document, issue comment, message or webpage.

Do not place untrusted data into prompts as if it were authoritative instructions. Treat retrieved text as data and keep it separate from application policy. Never place passwords, API keys, signing secrets, private tokens or unnecessary personal data in prompts, tool descriptions or approval displays. Secrets should be handled by the application’s credential mechanisms and disclosed only to the component that needs them.

Apply these threat-driven gates:

Content-origin gate. Identify who can create or modify the source content. If external users, customers or broad employee groups can write it, classify it as untrusted even if the repository and MCP operator are approved.
Tool-reach gate. Ask what a manipulated response could cause. A read-only lookup with narrow output differs from a tool that can export records, send messages or alter permissions.
Data-minimisation gate. Reject requests for “all records”, broad folders or full histories unless that scope is demonstrably necessary. Prefer an identifier, bounded filter and limited fields.
Parameter-review gate. Display destinations, identifiers, filters and write values. Do not approve generated arguments solely because the selected tool name appears benign.
Least-privilege gate. Give the application and remote server only the source scopes and downstream permissions required for the chosen task. Separate credentials for read and write where the source design permits it.
Write-review gate. Require careful human review for writes that affect security, privacy, money, employment, government services, health, legal position or other consequential interests. Verify the result in the authoritative downstream system.

Approvals reduce risk only when the reviewer can understand the action and has sufficient context to reject it. They do not remove prompt injection, exfiltration, mistaken parameters or harmful writes. A policy that automatically approves every call from a “trusted” server removes the very checkpoint the design claims to provide.

Reject excessive data requests before they reach approval

An approval screen should not become the first and only defence against oversized retrieval. Constrain each tool’s schema and application policy so the model cannot routinely request a complete repository when one record is enough. Where a tool offers both search and full-content retrieval, permit search first and fetch only selected results required for the user’s task.

Procedure: define the smallest acceptable input, maximum useful result scope, allowed fields and prohibited filters for each tool. Test the policy with a request that is broader than necessary. The expected design response is rejection or narrowing, not a lengthy confirmation prompt asking a user to bless indiscriminate access.

Example: “Find the latest approved travel policy for the user’s country” may justify a bounded search and retrieval of one selected policy. It does not justify sending every human-resources document to the model or remote server. If country or employment status is consequential to the answer, the application must obtain and validate it through an authorised source and require human review before relying on the result for an employment decision.

Preserve audit evidence without turning logs into a second data leak

Application-owned auditing is a trade-off. Too little evidence makes it difficult to reconstruct an approval and downstream effect; indiscriminate logging duplicates sensitive prompts, documents and credentials. The team should record what is necessary to establish the decision while minimising copied content.

A useful event record may include a stable proposal identifier, authenticated actor, tool and server identity, material parameters or a suitably protected reference to them, policy version, approval outcome, approving actor, execution status, downstream record identifier and review status. This is a suggested evidence design, not an OpenAI-provided audit guarantee. Retention and access must follow the organisation’s own requirements.

Never log API keys, bearer tokens or source credentials. Consider whether full retrieved documents are needed for evidence; often a source identifier, version and integrity reference are more appropriate. Where reviewers must inspect sensitive values, restrict who can view the evidence and define deletion and incident procedures before launch.

Decision rule: if an auditor could not tell what was proposed, who authorised it and what actually happened, the evidence is insufficient. If the log reproduces every secret and source document regardless of purpose, it is excessive. Security and privacy owners must review this balance; generated recommendations cannot make that consequential decision.

Anti-pattern one: buying ChatGPT Business for API capacity

Do not buy ChatGPT Business solely to obtain Responses API capacity. OpenAI’s Business overview, checked on 2 October 2026, says the ChatGPT Business subscription is separate from the API Platform and API usage is billed separately. ChatGPT Enterprise workspace membership and API Platform organisation membership are likewise separate systems. A person may belong to either or both, but one does not establish the other.

Correct procedure: first decide whether users should work in a managed ChatGPT workspace or in the organisation’s own application. If the latter is required, verify the API organisation, membership, billing owner, usage controls and contract separately. Buy Business seats only for a justified Business workspace use case, not as a proxy for API access.

Example rejection: “We need an API-backed customer portal, so we will buy two Business seats” fails because seats do not fund API requests or create the required application controls. The procurement record should instead identify the separate API relationship and application operating budget. If employees also need a Business workspace, assess that as another purchase with another purpose.

Anti-pattern two: choosing custom MCP because API ZDR may be available

Do not select a custom remote MCP architecture merely because the API organisation may qualify for ZDR. ZDR requires prior approval, has endpoint and feature limits, and governs only eligible OpenAI API handling. It cannot dictate a third-party MCP server’s retention, residency, logging or downstream processing.

Correct procedure: begin with the user and capability requirement. If a supplied ChatGPT app or direct bounded API tool can meet it, do not add a custom server solely to support a data-control label. If remote MCP is functionally necessary, assess the server as its own processing boundary and verify compatibility with the intended OpenAI control.

Example rejection: a team proposes sending regulated records through an unfamiliar remote server because its API organisation has ZDR approval. Reject the rationale until the team has established the server operator, data locations, retention, authentication, tool scope and contractual position. Human security, privacy and legal reviewers must decide whether the complete arrangement is acceptable.

A worked surface-selection decision

Consider an organisation that has one authorised case-management source and wants customers to request changes through its existing service portal. The source contains customer-authored text, and some requests could change payment details.

User location: customers must remain in the service portal, not ChatGPT or a developer’s Codex client. This supports an application-owned lane.
Authority: the portal authenticates the customer, while the source exposes a service credential. The application must map the customer to permitted cases and cannot rely on the service credential’s broad reach.
Capability: reading case status is lower risk than changing payment details. Split these into separate tools and do not expose the write tool to users or workflows that only need status.
Approval: display the target case, current destination and proposed replacement. Require human review under the organisation’s policy for money-related changes; do not let source text instruct the model to bypass it.
Evidence: record the proposal, authenticated customer, reviewer, approved parameters, downstream transaction and verified result without recording credentials.
Data boundary: assess source access, API handling, portal logs, remote MCP processing and the durable case-system write independently.

The Responses API lane is provisionally justified because the portal must own identity and interaction. Remote MCP is justified only if it is the necessary tool boundary; the choice of the API does not itself require MCP. If a direct application integration can provide a narrower authorised tool, compare that design before exposing a general remote server.

Release checklist for an application-owned lane

The requirement states why users cannot complete the task appropriately in an existing ChatGPT app, Company Knowledge or Codex MCP.
The API organisation, billing owner and budget are separate from ChatGPT workspace procurement.
Every tool is named, bounded and classified as search, read or write.
The authoritative user and source identities are mapped, including any shared service credential.
Allowed tools and approval requirements are explicitly configured and reviewed.
The application displays material parameters and records the decision before execution.
A material parameter change invalidates the earlier approval.
Untrusted source content is treated as data, not policy or executable instruction.
Secrets and unnecessary sensitive data are excluded from prompts and logs.
Source, API, application, remote-server and downstream-write boundaries each have an owner.
Non-training, default retention, ZDR or Modified Abuse Monitoring claims have been checked against current documentation and the organisation’s approved configuration.
The remote MCP server’s retention and residency are assessed independently of OpenAI API controls.
Consequential actions receive human review and downstream verification.
Rollback, credential revocation and incident contacts are documented.
Current service status, tenant access, feature compatibility and applicable terms are rechecked at rollout.

All availability and data-control statements here reflect the cited OpenAI documentation checked on 2 October 2026. Before publication and deployment, recheck the live API organisation, current endpoint eligibility, remote-server documentation, contract and OpenAI status information. Aggregate service status does not prove that a particular feature, model, tier or account is available.

After documenting that an application-owned API is necessary, How to Build Custom AI Agents with OpenAI’s Responses API: From Single-Turn Chat to Multi-Step Autonomous Workflows provides Python-oriented steps from minimal Responses API calls through tool registration, multi-step loops, validation, deployment, and monitoring. It was published in July 2026; recheck SDK syntax, tool semantics, and production controls before adopting its examples.

Implementation should begin only after this selection record is approved. A tutorial can show mechanics, but it cannot decide the organisation’s identity authority, acceptable data boundary or approval policy. Those decisions require accountable human owners, especially where security, privacy, money, employment, government, health, legal rights or other consequential outcomes are involved.

For a scoped Assistants-to-Responses migration, How to Migrate from the OpenAI Assistants API to the Responses API: A Complete Developer Guide with Code Examples maps assistant configuration, conversation state, tools, streaming, file-search patterns, tests, and rollout work into a staged plan with Python and TypeScript examples. Published in July 2026, it needs a current documentation recheck before treating any architecture pattern as authoritative.

Migration is optional post-selection context, not evidence that the Responses API is the correct surface. An existing API implementation should still pass the same user-location, authority, capability, operating-ownership and data-boundary tests before it is moved or extended.

Run the pilot, preserve the evidence and record the decision

A procurement pilot should answer whether one proposed integration can be operated within the team’s actual permissions, contracts and support model. It should not attempt to rank the five surfaces through a synthetic benchmark. Response quality, latency and feature availability can vary with the source, account, model, region, client and service condition; a small internal exercise cannot establish a universal comparative score.

The protocol below is a suggested documented-review method. It has not been run for the scenarios in this guide, produces no comparative score and makes no claim about measured performance. Its output is an evidence pack and a decision: approve, approve with restrictions, defer pending evidence or reject. Re-run the relevant gates in the live tenant immediately before rollout.

Set the pilot boundary before anyone connects a source

Write a one-sentence use case naming the user, source, permitted operation and operating location. For example: “Authorised support staff may search their existing document permissions from a managed ChatGPT workspace and must receive links that allow them to verify the source.” This is testable. “Connect company data to artificial intelligence” is not.

List the prohibited operations separately. If the pilot is read-only, prohibit create, update, delete, send, publish, approve, purchase and permission-changing operations. Do not rely on a participant remembering that intention: remove or disable write-capable tools where the selected surface permits it, and record any capability that cannot be technically removed.

Use non-sensitive test material that reproduces the required permission boundaries without including secrets, production credentials, payment details, private personnel records or untrusted content in prompts. A test corpus might contain an ordinary document, a document visible only to a second test identity and an intentionally absent document. It must not contain concealed instructions intended to imitate a security assessment unless the organisation has separately authorised and designed that assessment.

Name the evidence custodian before testing. This person stores screenshots or exports permitted by organisational policy, configuration records, contract references, source-owner confirmations and dated observations. Evidence should identify the account, workspace or API organisation tested without copying tokens, credentials or unnecessary source content.

A documented-review protocol, not a benchmark

Confirm entitlement in the exact operating context. Record the plan or commercial arrangement, workspace, user role, region, selected interface and relevant administrator setting. For a connected app, also record the particular app and provider-authorisation state. OpenAI’s connected-app documentation, opened on 2 October 2026, says availability can depend on the app, plan, region, workspace, role, model and interface. A feature seen by one administrator therefore does not prove availability for the intended users.

Decision rule: stop if the buyer cannot demonstrate the capability with the intended account and client, or obtain current contractual confirmation. Do not infer entitlement from another ChatGPT plan, a Codex seat, workspace membership or API organisation membership.
Verify source authorisation. Identify the person or service account presented to the provider, who can grant or revoke it, and what source permissions it already holds. Test with at least two authorised identities whose source access differs. Ask each identity for the same known item and record whether the source’s existing access boundary is preserved.

Decision rule: reject the pilot if installing or enabling the integration is being treated as permission to access material that the principal could not otherwise access. OpenAI documents that app permissions grant no new source access and that Company Knowledge respects existing source permissions.
Inspect least privilege. Enumerate every requested provider scope, exposed MCP tool and operation. For each, map the minimum data required, the source object accessed and whether the result is returned to the model, user or another system. Remove unused scopes and tools before continuing.

Example: a document-finding pilot may need search and fetch but not sharing, deletion or folder administration. If one broad provider scope bundles those powers, record the excess privilege as unresolved evidence rather than describing the integration as least-privileged.
Prove the read-only boundary. Inspect the provider scopes, server implementation and exposed tool definitions; do not accept a user-interface label as the sole evidence. Attempt only approved, harmless operations using the test corpus. Confirm that write-capable tools are absent, denied or otherwise unreachable for the pilot identity.

Decision rule: a read-only pilot fails if a participant can invoke a consequential write, even when a confirmation screen appears. Approval is a control on execution, not evidence that write authority is absent.
Review approval visibility. For every tool that can share data externally or alter a system, document what the user sees before execution: tool identity, destination, parameters, affected object and proposed action. In the Responses API MCP path, OpenAI documents that approvals are requested by default before sharing data with a connector or remote MCP server, while the application can manage approval responses. The application owner must still design a comprehensible approval experience and retain appropriate evidence.

Decision rule: reject consequential actions if the approver cannot understand what will be sent or changed. A generic “continue” interaction is inadequate evidence for a financial, employment, security, privacy, government or similarly consequential decision.
Check logs end to end. Identify records from the client or application, OpenAI surface, MCP server and source provider. Record which identity, tool, time, parameters, approval outcome and source object each layer captures. Avoid logging full prompts, credentials or complete returned documents merely to make an audit trail more detailed.

Trade-off: insufficient logging prevents investigation, while indiscriminate logging creates another store of sensitive data. Retain identifiers and decision evidence where possible; include content only when justified by a defined investigation or compliance need.
Exercise revocation and rollback. Disable the app, unpublish or withdraw the custom app, remove the Codex configuration, revoke provider credentials, disable the API tool and confirm that subsequent access fails as intended. Identify cached data, logs or server-side records that are not removed by revoking access.

Decision rule: do not launch without an owner who can perform rollback within the organisation’s required response window. Revocation must be tested at the provider as well as the OpenAI-facing configuration because the two controls are not interchangeable.
Review provider terms. Record the applicable app, MCP server and source-provider terms and privacy statements, including the entity operating the remote server. Workspace approval does not replace third-party diligence. Review the app provider’s current terms and privacy policy before sharing data.

Decision rule: defer if the procurement, privacy or security owner cannot identify the receiving entities, permitted purposes, subcontracting position or deletion route required by organisational policy. Do not put secrets or untrusted data into prompts while trying to discover those answers.
Separate training, retention, residency and third-party handling. Capture each statement independently. OpenAI documents that API inputs and outputs are not used to train models by default unless a customer opts in; that statement does not mean zero retention. OpenAI’s API data guidance describes default abuse-monitoring retention of up to 30 days and says Zero Data Retention (ZDR) and Modified Abuse Monitoring require prior approval and have feature or endpoint qualifications. The remote MCP provider’s own data-retention and data-use policies still apply regardless of OpenAI API controls.

Decision rule: never approve on the shorthand “our data is not trained on”. Obtain current, applicable evidence for retention, residency and every third party in the proposed data path.
Assign support ownership. Name owners for user access, provider authorisation, workspace publication, local configuration, remote-server operation, API billing, incident response and user support. Record which party handles a source-permission defect, failed approval, unavailable tool and suspected data disclosure.

Decision rule: reject an integration that depends on “the platform team” or “the vendor” without a named internal owner and an agreed escalation route.
Check live service status at the decision and launch gates. Consult the OpenAI status page and the source provider’s authorised operational channel. The OpenAI status page was fully operational when opened on 2 October 2026, but it reports aggregate conditions and warns that individual availability can vary by tier, model and feature. That observation is not an uptime conclusion or a promise for rollout day.

Decision rule: postpone a go-live when a relevant active incident prevents meaningful validation. A healthy aggregate status page does not prove that a tenant-specific feature is enabled.

Acceptance criteria for a bounded rollout

The intended users can access the selected surface in the exact live tenant, role, region and interface.
The authoritative identity is documented, and two differently permissioned test identities preserve the provider’s source boundary.
Every exposed tool and provider scope has a stated purpose; unused or unjustified access has been removed.
A read-only pilot exposes no executable write operation. A later write phase requires a separate approval.
Users can identify the destination, data and effect before approving consequential sharing or action.
Audit evidence identifies the actor, tool, time, approval and affected object without unnecessarily duplicating sensitive content.
Provider terms, privacy statements, retention and residency statements have been reviewed by the responsible functions.
Revocation has been demonstrated at the OpenAI surface, provider and remote server or application layer where applicable.
An internal support owner and incident escalation path are published to pilot users.
The current contract, separate billing arrangements, feature rollout and live service status have been checked.

Passing these criteria means only that the bounded use case has sufficient evidence to proceed under its recorded restrictions. It does not approve new sources, broader user groups, write access or reuse of the same server in another surface.

Five worked procurement decisions

Decision A: an approved conversational app

Need: individual staff members want to search and summarise material from an already approved provider while remaining in a ChatGPT conversation. The provider offers an existing ChatGPT app, users lawfully authorise their own accounts and no custom operation is required.

Selected surface: the existing ChatGPT app, restricted initially to supported read/search behaviour. It is the smallest surface because the conversation is the intended workplace and an approved integration already exists.

Rejected alternatives: Company Knowledge is rejected because the requirement is a user-authorised interaction with one app rather than managed organisation-wide knowledge answering. A custom remote MCP app would add server vetting and publication without supplying a missing capability. Codex MCP places the tool in a developer host, not the staff conversation. The Responses API would make the organisation build identity, interface, approvals, logging and billing for a workflow already served by the app.

Unresolved evidence: exact tenant availability; provider scopes; applicable app terms; memory and context behaviour for the intended workspace; log visibility; and the revocation procedure. Availability must be verified for the app, plan, region, role, model and interface.

Approval owner: the workspace owner approves enablement, while the source owner confirms permitted use and the privacy or security reviewer accepts the data path. Each user remains responsible for provider authorisation within policy.

Stop condition: stop if the app requests unjustified source access, cannot preserve provider permissions, lacks an acceptable revocation route or requires write authority for the read-only use case.

Decision B: managed Company Knowledge lookup

Need: members of an eligible managed workspace need organisation-specific answers from supported sources, with links allowing users to inspect the underlying material. Existing source permissions must remain authoritative.

Selected surface: Company Knowledge. OpenAI’s documentation, opened on 2 October 2026, describes availability for Business, Enterprise and Education when the plugin, a supported source and necessary app or administrator authorisation are available. This selection does not imply that every repository or every provider account is connected.

Rejected alternatives: a single conversational app is too narrow where the approved requirement is managed knowledge answering across supported sources. Custom MCP is rejected because no missing bespoke tool has been identified. Codex MCP is inappropriate for general workspace members. The Responses API is unnecessary because the organisation is not building a separate customer or employee application.

Unresolved evidence: support for each proposed source in the live tenant; administrator enablement; individual provider connection requirements; citation behaviour; source-permission preservation; and handling of documents that move or lose permission after retrieval.

Approval owner: the workspace administrator owns enablement; each source owner approves inclusion; identity administrators validate user lifecycle controls; privacy and security owners review the aggregate data path.

Stop condition: stop if stakeholders describe the surface as a universal company index, cannot identify the authoritative source identity, or cannot verify cited answers against accessible source links. Human review remains mandatory before using retrieved information for employment, finance, security, government or other consequential decisions.

Decision C: a vetted remote workspace tool

Need: managed-workspace users need a remote internal tool in ChatGPT that is not available through an approved existing app. The first release fetches limited operational records and performs no modification.

Selected surface: a custom remote MCP app in ChatGPT developer mode, privately tested and published only after administrator vetting. OpenAI’s Help Centre describes full MCP, including modify and write actions, as a beta capability for Business, Enterprise and Education, with workspace publication and additional role-based access control and action controls documented for Enterprise and Education. The team must verify the live tenant rather than turn that description into a universal entitlement claim.

Rejected alternatives: an existing app is rejected because it lacks the required internal tool. Company Knowledge is rejected because the requirement is a precise operational fetch, not source-linked knowledge answering. Codex MCP is rejected because the users are not working in a repository or developer client. The Responses API is rejected because the desired user experience is the managed ChatGPT workspace and the organisation does not need to own a separate application.

Unresolved evidence: tenant eligibility; remote-server identity and authentication; exact tools exposed at publication; provider and server retention; log availability; private-network reachability; prompt-injection controls for retrieved content; and whether publication changes preserve the reviewed tool snapshot.

Approval owner: the custom-app administrator owns publication; the remote-service owner owns operation and credentials; the source owner approves data access; security and privacy reviewers approve the read-only boundary.

Stop condition: stop if untrusted source content can direct broader access, the remote server exposes write tools during the read-only phase, material server changes can bypass renewed review, or no owner can immediately unpublish and revoke credentials. Trust in the server developer does not make source content trustworthy.

Decision D: a repository-local developer tool

Need: developers need a tool that operates in a trusted local project and is useful from Codex desktop, the CLI or the IDE extension. It need not be published to general ChatGPT workspace users.

Selected surface: Codex MCP, using a local STDIO process when the tool should remain on the same host, or a reviewed streamable HTTP server when a remote operating boundary is intentional. OpenAI documents shared same-host MCP configuration across Codex desktop, CLI and IDE, together with project scope, tool allow/deny lists and approval controls.

Rejected alternatives: an existing ChatGPT app and Company Knowledge do not supply repository-local execution. A custom ChatGPT MCP app would require a remote workspace publication path and would not turn a local process into a web app. The Responses API adds an application and API operating burden when the user is the developer in the local project.

Unresolved evidence: project trust; executable provenance; local credential storage; allowed and denied tools; default and per-tool approval settings; effects on files outside the repository; remote-server terms if HTTP is selected; and support responsibility across Codex clients.

Approval owner: the engineering tool owner approves the configuration; the repository owner accepts file and command boundaries; security reviews executable and credential risks; each developer follows the approved project configuration.

Stop condition: stop if the server requires broad filesystem or credential access, if denied tools remain callable, if a repository can silently replace trusted configuration, or if the team assumes the local configuration is automatically a workspace-published ChatGPT app. Any operation affecting production, security controls, money or employment requires explicit human review outside the developer tool.

Decision E: an application-owned customer workflow

Need: customers use the organisation’s own application. The organisation must own customer identity, eligibility, interface, approval wording, audit records, orchestration, support and commercial controls while invoking an approved remote MCP server.

Selected surface: an application-owned Responses API MCP integration. This is the smallest appropriate route only because the application itself is the required user location and the organisation accepts responsibility for the full control loop.

Rejected alternatives: a ChatGPT app would place the workflow in ChatGPT and use its account context rather than the company’s customer experience. Company Knowledge is for eligible managed-workspace knowledge use, not a customer product. A custom ChatGPT MCP app remains a workspace-published ChatGPT surface. Codex MCP targets developer hosts and projects.

Unresolved evidence: API organisation membership and billing; customer-to-provider identity mapping; allowed tools; approval wording; application and remote-server logs; OpenAI and third-party retention; residency; ZDR eligibility if required; failure behaviour; revocation; and support obligations. ZDR, where approved and applicable, does not determine the remote MCP server’s handling.

Approval owner: the product owner accepts customer experience; the API organisation owner controls access and billing; the application security owner approves identity and tool boundaries; privacy and legal reviewers assess the data path and terms; the remote-service owner accepts operational support.

Stop condition: stop if the application cannot show a meaningful approval before consequential data sharing or action, cannot attribute a call to the correct customer, cannot disable the tool independently, or cannot reconcile its records with the remote server. Human review is compulsory for security, privacy, payments, credit, employment, healthcare, government services and other consequential outcomes.

Decision record to retain

Use the following as an example template, adapting it to the organisation’s control framework. Blank or “unknown” entries are unresolved evidence, not implicit approval.

Field	Required record
Decision identifier and date	Unique reference, author and review date
Bounded use case	User, source, operation and operating location
Selected surface	Exact app, Company Knowledge, custom ChatGPT MCP, Codex MCP or Responses API MCP route
Alternatives rejected	Specific reason each larger or misplaced surface was not chosen
Authoritative identity	User, workspace, local host or application identity and source mapping
Entitlement evidence	Tenant, role, region, interface, rollout and dated documentation check
Tools and scopes	Allow-list, denied operations, provider scopes and read/write classification
Approval design	Who approves, what they see and what happens after denial
Data path	Systems receiving prompts, parameters, source data, outputs and logs
Terms and controls	Provider terms, retention, residency, training statement and applicable API controls
Operational owners	Named owners for support, credentials, publication, billing and incidents
Rollback	Disablement, revocation, deletion request and user-notification procedures
Acceptance evidence	References to approved records without embedded secrets
Unresolved evidence	Open questions, owner and deadline
Decision	Approve, approve with restrictions, defer or reject
Expiry and re-review	Trigger date plus changes requiring immediate reassessment

Responsibility handoff

“Accountable” means the final internal decision owner; “responsible” means the person performing the work; “consulted” supplies required review; and “informed” receives the outcome. One person may hold several roles in a small organisation, but the responsibilities must remain explicit.

Activity	Accountable	Responsible	Consulted	Informed
Approve the bounded use case	Business or product owner	Pilot lead	Source owner, security, privacy	Support and users
Verify entitlement	Workspace or API organisation owner	Administrator	Procurement	Pilot lead
Approve source access	Source owner	Identity administrator	Privacy and security	Workspace or application owner
Vet MCP tools or app scopes	Security owner	Technical owner	Source and privacy owners	Support
Design approval interactions	Product or workspace owner	Application or app owner	Security, privacy, affected business owner	Users
Review terms and data statements	Procurement or legal owner	Procurement lead	Privacy, security, source owner	Decision owner
Operate logs and incidents	Service owner	Operations or support team	Security and provider contacts	Decision owner and affected users
Execute rollback	Service owner	Administrator or application operator	Source owner, security, support	Users and procurement

Escalation, rejection and rollback

Escalate first to the named service owner when a user cannot access the feature or a tool fails. Escalate to the source and identity owners when results suggest an incorrect permission boundary. Escalate immediately to security and privacy incident processes for suspected disclosure, prompt injection, credential misuse or unauthorised action. Billing and membership disputes go to the workspace or API organisation owner and procurement. A service incident should also be checked against current OpenAI status information, without assuming an aggregate status explains a tenant-specific failure.

Pause rather than improvise when the issue concerns money, employment, government services, privacy rights, security decisions or another consequential outcome. Preserve minimum necessary evidence, revoke active authority where appropriate and require qualified human review before resuming.

Reject if the intended user, source and operation cannot be stated precisely.
Reject if entitlement is inferred from a different OpenAI product or another user’s access.
Reject if the authoritative source identity or permission owner is unknown.
Reject read-only status when any write tool remains executable.
Reject consequential actions without intelligible, attributable approval.
Reject if provider terms, retention or residency evidence required by policy is unavailable.
Reject if remote-server ownership, support or credential rotation is unassigned.
Rollback after unexpected privilege expansion, unexplained source access, unauthorised writes, material unreviewed tool changes or loss of audit evidence.
On rollback, disable publication or tool configuration, revoke provider credentials, rotate exposed secrets, stop scheduled calls, preserve necessary incident evidence and notify affected owners.
Confirm what data remains in OpenAI, application, provider and remote-server logs; do not claim that disconnecting an app deletes all prior records.
Reopen only through a new decision record that identifies the cause, corrective evidence and renewed approvals.

Dated procurement note

Checked 2 October 2026: do not reproduce a remembered price or use a ChatGPT subscription as a proxy for API cost. OpenAI’s Business overview says ChatGPT Business is separate from the API platform, API usage is billed separately and a Business workspace requires at least two seats. OpenAI’s Enterprise guidance likewise distinguishes ChatGPT workspace membership from API Platform organisation membership.

Before purchase or launch, verify the current account contract, minimum and assigned seat requirements, separate API organisation access and billing, usage limits, regional terms, feature rollout, workspace settings and current service status. Ask the account owner to confirm the exact tenant rather than relying on a public plan description. Recheck third-party app or MCP provider charges and terms separately. A contract may govern the account differently from a general help page, and neither proves that a beta or staged feature is enabled for the intended users.

Conclusion: choose the smallest controlled surface

Use an existing ChatGPT app for an approved conversational integration; Company Knowledge for managed, permission-respecting organisational lookup; a custom ChatGPT MCP app for a vetted remote workspace tool unavailable through supplied apps; Codex MCP for trusted repository-local developer work; and the Responses API for a product whose organisation will own identity, approvals, logging, orchestration, support and billing. If a smaller surface meets the authorised read use case, reject the larger one. If no surface provides sufficient entitlement, permission, data-boundary and rollback evidence, do not integrate.

Glossary

App: An integration that brings supported external search, content or actions into ChatGPT. Availability and capability depend on the particular app and account context; authorising it does not create new source permissions.
Company Knowledge: A managed ChatGPT knowledge-answering surface for eligible Business, Enterprise and Education workspaces using supported, authorised sources. It respects existing source permissions and is not a universal company index.
MCP: Model Context Protocol, a protocol through which a host can discover and invoke tools supplied by a server. The term alone does not specify where the server runs, who authorises it or whether its tools can write.
Remote server: A service reached over a network rather than started as a local process. Its operator, authentication, terms, retention, residency and support obligations must be reviewed separately.
STDIO: Standard Input/Output, a local transport in which a host communicates with a process through its input and output streams. Codex supports local STDIO MCP servers, but that configuration does not publish an app to ChatGPT.
Approval: An attributable decision permitting a specific data transfer or action after the approver can understand its destination and effect. Approval reduces uncontrolled execution but does not remove prompt-injection, error or harmful-write risk.
Entitlement: Whether a particular account, plan, workspace, role, region, rollout, model and interface exposes a capability. Membership in one OpenAI surface does not prove entitlement in another.
API organisation: The administrative and billing context for API Platform access. It is separate from ChatGPT workspace membership and requires its own access and commercial controls.
ZDR: Zero Data Retention, an API data-control arrangement requiring prior approval and subject to feature or endpoint qualifications. It does not determine how a third-party MCP server stores or processes data.
Least privilege: Granting only the identities, provider scopes, tools, objects and operations needed for the approved task. A confirmation step does not make excessive underlying authority least-privileged.

Access 40,000+ AI Prompts for ChatGPT, Claude & Codex — Free!

Subscribe to get instant access to our complete Notion Prompt Library — the largest curated collection of prompts for ChatGPT, Claude, OpenAI Codex, and other leading AI models. Optimized for real-world workflows across coding, research, content creation, and business.

Access Free Prompt Library

Useful Links

Markos Symeonides

25 Codex Prompts for Open-Source Package Maintainers: From Issue Intake to a Safe, Evidence-Backed Release

Posted in AI News

Reading Time: 74 minutes

Use 25 Codex prompts from issue intake through compatibility checks, tests, review and evidence-backed release, with repository permissions and human maintainer approval.

Before You Trust Codex Code Review: A Reproducible PR Benchmark for Rule Signal, Reviewer Time, and False-Positive Noise

Posted in ChatGPT Prompts

Reading Time: 74 minutes

Design—not results—of a reproducible Codex pull-request review benchmark: pinned cases, rule conditions, human adjudication, reviewer time and false-positive definitions.

25 ChatGPT Prompts for Public Consultation Response Analysis: De-identification, Theme Coding, Evidence Ledgers, and Human Sign-off

Reading Time: 68 minutes

A 25-prompt public-consultation analysis masterclass for authorised, de-identified responses, thematic coding, evidence ledgers, dissent, uncertainty and human sign-off.

How to Build a Read-Only Codex Repository Atlas: Turn an Unfamiliar Codebase into a Reviewable Onboarding Map

Posted in AI News

Reading Time: 72 minutes

Map an unfamiliar repository with Codex under read-only boundaries: record entry points, dependencies and uncertainty, then verify every finding before a human-approved change.

Which OpenAI Integration Surface Fits Your Team? A 2026 Buyer’s Guide to ChatGPT Apps, Company Knowledge, Codex MCP, and the Responses API

Evidence checkpoints

The decision in one page

Four distinctions that stop category errors

Capability: what the surface can do

Entitlement: whether this account and context expose it

Deployment: where the tool actually runs

Commercial membership: which product relationship pays for and admits the user

Keep the four commercial and operating domains separate

Name the five surfaces precisely

1. Existing ChatGPT app

2. Company Knowledge

3. Custom remote MCP app in ChatGPT

4. Codex MCP

5. Application-owned Responses API MCP integration

The four-question decision sequence

Question 1: Where does the work occur?

Question 2: Whose permissions govern?

Question 3: Is read/search enough, or is consequential action required?

Question 4: Who owns controls after launch?

Three compact worked examples

Sales knowledge lookup

Repository-local developer utility

Customer-facing workflow

Facts to verify in the live tenant

Record a provisional lane, not a purchase recommendation

Existing ChatGPT apps and Company Knowledge: use the supplied lane before building one

Separate availability, workspace permission and source authorisation

Apply a context and data-handling test before routine use

Company Knowledge is source-respecting answering, not universal indexing

Custom remote MCP apps in ChatGPT developer mode: a managed publication lane

Treat vet, test and publish as distinct governance decisions

Respect the remote-server and private-network boundary

Design minimum-data tools before debating write access

Read-first is a rollout policy; write authority is another gate

Codex MCP: developer-hosted tools with local and project controls

Choose STDIO or streamable HTTP by operating boundary

Use allow lists, deny lists and approvals as separate controls

Comparison: three user-facing and developer-hosted lanes

Worked rejection analysis: one internal engineering tool

When the Responses API is the right lane

Apply the operating-ownership test before discussing implementation

Design the approval sequence as an application feature

Default approval requests and application-managed controls solve different problems

Map the data boundary layer by layer

Interpret non-training, retention and ZDR narrowly

Gate the design against indirect prompt injection

Reject excessive data requests before they reach approval

Preserve audit evidence without turning logs into a second data leak

Anti-pattern one: buying ChatGPT Business for API capacity

Anti-pattern two: choosing custom MCP because API ZDR may be available

A worked surface-selection decision

Release checklist for an application-owned lane

Run the pilot, preserve the evidence and record the decision

Set the pilot boundary before anyone connects a source

A documented-review protocol, not a benchmark

Acceptance criteria for a bounded rollout

Five worked procurement decisions

Decision A: an approved conversational app

Decision B: managed Company Knowledge lookup

Decision C: a vetted remote workspace tool

Decision D: a repository-local developer tool

Decision E: an application-owned customer workflow

Decision record to retain

Responsibility handoff

Escalation, rejection and rollback

Dated procurement note

Conclusion: choose the smallest controlled surface

Glossary

Access 40,000+ AI Prompts for ChatGPT, Claude & Codex — Free!

Useful Links

Get Free Access to 40,000+ AI Prompts for ChatGPT, Claude & Codex

More on this