SoftTech AI Registry
OpenAI · ChatGPT Workspace Agents

App and MCP server actions

ChatGPT Workspace Agents using configured apps / MCP server integrations as tools: retrieving and searching information in connected external systems and, where the integration supports it and the configured policy permits it, performing actions that change state in those systems. OpenAI's current documentation treats "app" and "MCP server" as the same connected integration. Effective access is layered: an agent instruction alone grants nothing, and a request must pass workspace/Workspace-Agents access, plugin and app availability, a configured connection, the connection's authenticated identity, the connected service's own scopes, Action control (which actions are permitted) and App permissions (when human confirmation is required). This record covers that tool-action surface only; scheduled runs and API-triggered runs are separate initiation mechanisms and are excluded. OpenAI applies no preview, beta or general-availability label to this surface in the accessible primary material, and none is inferred here.

Recorded characteristics

Function
OpenAI documents that a plugin can include MCP servers / apps that connect ChatGPT to other tools, and states explicitly that "in this guide, app and MCP server refer to the same connected integration and are interchangeable terms", using "MCP server" in prose while preserving "app" in UI labels such as Workspace apps and App permissions. Plugins in ChatGPT and Codex "can include MCP server connections that search, retrieve, sync, or act on external systems". When ChatGPT uses an MCP server included with a plugin, OpenAI documents that "it sends a request to the connected service and returns data or action results allowed by the authenticated user's permissions in that service". Layered mechanism as documented. OpenAI publishes an explicit capability chain in which a plugin "can span these control layers": Availability (whether the plugin bundle is available to the user, managed in workspace settings); Included skills (which reusable instructions the installed plugin contributes); MCP server access (whether users can use an MCP server's capabilities, managed in Workspace apps and Permissions & roles); Actions and permissions (which actions users can run and when ChatGPT asks before using its tools, managed through the connection's Action control and App permissions); Service authorization (which external data and actions the authenticated identity can access, managed in the connected service and its identity provider); and Runtime permissions (what an agent can do after it receives data or a tool, managed by the runtime, sandbox and approval controls for the active surface). OpenAI's roles documentation states the same principle for the workspace as a whole: "a request must pass every boundary that applies to it", and "workspace access can make a plugin available, but the connected service still decides which data the signed-in account can read". Making an integration available is documented as not equivalent to granting it. OpenAI warns that "making an MCP server or plugin available in ChatGPT doesn't grant access to files, records, or actions in the connected service", and, in the ChatGPT Work cloud security documentation, that "making a plugin available doesn't automatically enable the underlying app, authorize an account, or approve every action the integration can perform". For plugin imports, OpenAI states that "importing a plugin does not grant app access or connect members' accounts" and that "existing app permissions, action controls, and service access still apply". Conditions for a task to act. OpenAI documents that a task using a connected app, directly or through a plugin, "can proceed only when": the workspace enables the app and any plugin that requires it; the person has the necessary workspace or role access; the connection uses an authorized individual, shared, or agent-owned account; and the connected account, approved scopes, and available app action settings permit the requested information or operation. Workspace Agents context. OpenAI's Workspace Agents API documentation establishes that workspace agents are published within a ChatGPT workspace, that "before a user can create a Workspace Agent access token, a workspace admin must enable Workspace agents", and that a published agent has a stable public API trigger identifier. Workspace Agents run as ChatGPT Work cloud tasks on OpenAI-managed infrastructure rather than on the user's device, and OpenAI states that Work Cloud "introduces hosted task execution and optional tools that can access connected systems or take authorized actions". Boundary. This record covers the app / MCP server tool-action surface. It is not a general record of everything a workspace agent can do, it does not cover individual apps' feature sets, and it does not cover the initiation mechanisms (scheduled runs, API-triggered runs) that are recorded as separate candidate capabilities.
Data access
Retrieval. OpenAI documents that connected MCP servers / apps can "search, retrieve, sync, or act on external systems", and that when ChatGPT uses one it "sends a request to the connected service and returns data or action results allowed by the authenticated user's permissions in that service". Two handling modes are documented: non-synced, where ChatGPT "processes data from Chat and deep research transiently and doesn't index it", and synced, where ChatGPT "indexes selected connected content in advance", with the plugin page showing whether a connection supports sync. Access boundary. Effective reach is the intersection of the documented layers — workspace and role access, plugin availability, MCP server access, the configured connection, the authenticated identity, the connected service's scopes, and the connection's Action control. OpenAI states that access should be kept "within the scopes and permissions granted by each connected service and authenticated user", and that when a request reaches a connected service, "that service's scopes, retention, data residency, and other policies also apply". Retention of retrieved content. OpenAI documents that "content retrieved from a connected app isn't automatically saved as a Library file", and that if the content is later saved to a conversation, project, Library, or synced index, "that copy follows the rules for its saved location". Source-system records continue to follow the source system's own policies. Separate capabilities. OpenAI states that "the cloud browser, web search, connected apps, and code or shell networking are separate capabilities" and that "restricting one doesn't automatically disable the others" — connected-app access is therefore not inferable from, and does not imply, browsing or network access. Not established from accessible sources: the per-app inventory of readable objects, and whether Workspace Agents can attach arbitrary customer-deployed MCP servers beyond the admin-gated workspace plugin and app catalogue.
Actions
Can take actions
External actions
Yes
Human confirmation
Conditional
Permission basis
Mixed
Administrative control
Workspace Agents gating. OpenAI's Workspace Agents API documentation states that "before a user can create a Workspace Agent access token, a workspace admin must enable Workspace agents and turn on Allow users to create personal access tokens in Admin > Permissions & roles", establishing that Workspace Agents is an admin-enabled workspace feature and that access-token creation is separately gated. Workspace roles and RBAC. OpenAI documents built-in roles — Owner (workspace-wide settings), Admin (supported operations and groups), Member (no administrative rights) and Analytics Viewer (workspace analytics) — alongside seats that determine which product surfaces a member can access, and custom roles that "define which supported features a member can use" without replacing seat or plan eligibility, granting permissions in a connected system, or changing local runtime requirements. Only workspace owners can configure RBAC and create custom roles; custom roles are assigned through groups (manually managed or SCIM-synced) or directly where supported, and a member can hold more than one. For eligible permissions, "Default inherits the workspace setting, On grants access, and Off explicitly denies access", and "an explicit Off in any applicable role blocks access even when another role grants it". Plugin and app availability. Workspace plugin controls determine which roles can use or install a plugin on supported web and desktop surfaces. Admins manage MCP server capabilities from Workspace apps and Permissions & roles, where they can "enable MCP server connections and assign access by workspace role", configure Action control, set App permissions, and keep access within the scopes granted by each connected service and authenticated user. Plugin management adds an Installation policy of Available or Installed per eligible role, with the documented caveats that required apps must also be enabled, members must have access to the connected service, and importing a plugin does not grant app access or connect members' accounts. Review tooling. Eligible Enterprise owners and admins can export a CSV of public plugins available to the workspace (`public-plugins-security-review.csv`) covering plugin, MCP server and skill metadata, from a public-catalog snapshot that can be up to 48 hours old, excluding workspace-created plugins and unavailable in FedRAMP workspaces. Rollout guidance. OpenAI frames the layers as "a two-step rollout: first make the right plugins available, then configure the capabilities and permissions each workflow needs", advises recording per connected service "the business owner, permitted data, approved read or write actions, authentication method, and a support or removal contact", and advises starting with read actions. Not established from accessible sources: Business versus Enterprise differences in Workspace Agents administration, and the specific role permission names governing agent building and publishing.
Default state
Conditional
Availability
OpenAI documents Workspace Agents as current, active functionality: the Workspace Agents API documentation set covers provisioning Workspace Agent access tokens and triggering published workspace agents, a workspace admin must enable Workspace agents before tokens can be created, and the ChatGPT Work cloud security documentation describes hosted task execution with tools that "can access connected systems or take authorized actions". OpenAI's plugin controls documentation is likewise current and describes apps/MCP servers, Action control and App permissions as live workspace controls. OpenAI applies no preview, beta or general-availability label to the app / MCP server action surface in the accessible primary material reviewed, and no lifecycle label is inferred here. One narrow beta marker does appear in an adjacent area: the API trigger endpoint is called with an `OpenAI-Beta: workspace_agent_runs=v1` header and returns a "trigger run identifier returned by a beta trigger request" — that marker applies to the excluded API-trigger mechanism, not to app and MCP server actions. Historical rollout chronology is not established. The Registry could not retrieve OpenAI's Workspace Agents Help Center article (see limitations), and no accessible OpenAI primary source reviewed states an introduction date, plan-by-plan rollout sequence, or launch default. `first_observed_date` is therefore left unset rather than inferred.
Licensing
OpenAI documents these controls in the context of ChatGPT Business, Enterprise and Edu workspaces: the cloud security page states that "for Business, Enterprise, and Edu workspaces, existing protections include encryption in transit and at rest", and that OpenAI applies "no model training on information accessed through these connections for Business, Enterprise, and Edu customers". Seat types are documented as plan-dependent, with "ChatGPT and Codex seats" named as examples, and OpenAI states that "capabilities and controls depend on the workspace plan, rollout, configuration, and connected integration" and that "available controls can differ by plan, workspace configuration, and rollout". The public plugin security-review CSV export is documented as available to eligible ChatGPT Enterprise workspace owners and admins and unavailable in FedRAMP workspaces. Not established from accessible sources: which plans include Workspace Agents, any per-seat or usage-based pricing for agent runs or app actions, and any Business/Enterprise differences in the approval or Action control options offered.
External model or provider
Not established
Limitations and uncertainty
Evidence-access limitation. OpenAI's principal Workspace Agents Help Center article (help.openai.com/en/articles/20001143, "ChatGPT Workspace Agents for Enterprise and Business") cannot be retrieved by the Registry's research or monitoring infrastructure: it returns HTTP 403 to plain fetch, to browser-header fetch, and to a headless browser, as does the wider help.openai.com and openai.com estate. That page is independently understood to carry relevant material, but nothing from it is stored here as Registry evidence, and no monitor is pointed at it, because Registry evidence must be reproducible from sources the Registry can actually retrieve. Every stored claim on this record comes from OpenAI primary documentation the Registry fetched directly (learn.chatgpt.com and developers.openai.com). No third-party source was used to fill the gap. Several fields below are consequently narrower than OpenAI's own documentation is likely to be. Unresolved — historical rollout chronology. No accessible OpenAI primary source establishes when Workspace Agents was introduced, its plan-by-plan rollout order, or its launch default state. No introduction date is recorded. Unresolved — Workspace-Agent-specific identity semantics. Accessible documentation establishes the three connection identity categories (individual/personal, shared, agent-owned) and their permission consequences at the ChatGPT Work / connected-app level. It does not establish the Workspace-Agent-specific configuration surface for choosing between them, which identity a given agent uses by default, or whether every user who can invoke a published agent thereby exercises that agent's shared or agent-owned connection. No such inference is recorded. Unresolved — per-app action inventory. Accessible documentation establishes only the generic boundary that connected integrations can search, retrieve, sync or act on external systems. It names no specific write action for any specific app. No per-app action list is recorded, and no Gmail, Drive, Slack, Calendar or comparable mutation is claimed. Unresolved — approval defaults. Accessible documentation states that App permissions options "can include Always ask, Any changes, Important actions, and Never ask" and that they vary "depending on the app and workspace". It does not state a default approval mode for Workspace Agents, for any individual app, or at workspace creation. No default approval mode is recorded. Unresolved — parameter and action-input constraints. No accessible OpenAI source reviewed uses "Connector Action Constraints" or documents a mechanism that narrows an action's inputs or parameters (for example restricting recipients, domains or documents). What accessible documentation does establish is Action control's approved custom action set, which selects which actions are permitted rather than constraining an allowed action's parameters. No parameter-constraint mechanism, and no domain, recipient or document example, is recorded. Unresolved — newly added actions. OpenAI states that Action control covers "how the workspace handles newly added actions" but the accessible documentation does not enumerate the available handling options. Only the existence of the setting is recorded. Unresolved — Slack deployment identity. OpenAI publishes a ChatGPT Agents app in Slack article, but it sits on the inaccessible Help Center. Slack deployment is outside this record's boundary and no Slack-specific identity or channel behaviour is recorded. Unresolved — per-action audit and approval logging. OpenAI documents workspace analytics, Codex analytics, an Analytics API and a Compliance API, and states plainly that analytics surfaces are "interactive reporting surfaces, not raw audit logs". No accessible source establishes that individual app actions, individual write approvals, or individual approval decisions by a workspace agent are recorded as auditable events. No audit-log claim is made. Unresolved — custom MCP server scope for agents. OpenAI documents custom and imported plugins and locally configured MCP servers as separate admin-gated paths, but accessible documentation does not establish which of these a workspace agent may attach, nor that every MCP server supports write actions. Unresolved — high-risk action blocking. OpenAI states that "ChatGPT can still block some high-risk actions" even where policy allows an unprompted write, but does not define the category. Recorded as stated, not characterised.

Evidence