Custom per-action approvals missing from Workspace Agents

GPT builders Plugins / Actions builders
, ,
1

Title: Custom per-action approvals missing from Workspace Agents

Hi,

Previously, I could open a Workspace Agent in the builder, go to Tools, select a connected app, and choose Custom in its approval settings. This let me configure individual actions to always require approval or run automatically.

Now, in the same area under Safety constraints → Action safety, I only see:

  • Always ask

  • Allow read tools

  • Allow low-risk tools

  • Allow all tools

The Custom option is missing. Allow all tools is also greyed out with the message “Your workspace admin has disabled this option,” even though I’m the workspace administrator.

My agent uses a custom MCP app with an agent-owned account. I need some write actions to run automatically while others always require approval. Allow read tools asks before every write, and Allow low-risk tools doesn’t let me explicitly choose the approval behavior for each action.

I can see action-management controls for apps already published to the workspace. However, this particular connection provides access to a sensitive internal system, so I cannot publish it for general organization use just to access those controls. It needs to remain restricted to the agent and its authorized users. The app’s Manage page currently shows options such as Refresh tools and Publish to workspace, but I don’t see per-action approval settings there.

The Workspace Agents documentation still mentions Custom approval settings for specific write actions.

Has this setting been removed, moved, or is its absence a bug? What is the supported way to configure per-action approvals for an agent-owned custom MCP connection without publishing the app to the workspace?

2

Hi Philippe,

I checked the current OpenAI documentation, and it still explicitly mentions Custom approval settings for specific write actions under Workspace Agents → Manage write actions. However, it also says availability depends on the app, so it’s not entirely clear whether this is an intentional restriction for custom MCP connections or a UI regression.

One potentially useful distinction: Connector Action Constraints can restrict how tools are used, but they don’t replace per-action approval policies.

OpenAI also documents restricted app access through RBAC for Enterprise/Edu workspaces, which may address the concern about exposing an internal connector to the entire organization. However, I couldn’t confirm that this restores per-action approvals for agent-owned MCP connections.

A couple of things might help narrow this down:

  • Does the Custom option disappear for all connected apps, or only for your agent-owned custom MCP?

  • Are you using a Business or Enterprise workspace?

If Custom is missing across all connections despite being documented, this seems worth raising with OpenAI Support as a possible regression or an undocumented change.

Official references:

Hope this helps narrow it down!

3

Seems to me like it is undocumented change, because we have a Business account, and the “Custom” option disappeared on all apps and all workspace agent.

My workspace agent that had the custom option enabled switched to “Allow Low-risk Tools” option…

4

This change would be a serious regression for anyone using agents against systems where different write operations have very different risk.

In our own agent infrastructure we deliberately separate:

  • what the model wants to do,
  • what the connector/tool technically exposes,
  • and what the current policy actually authorizes.

Those are three different layers.

A useful approval model needs to be action-specific. For example, “create draft” may be allowed automatically, while “send message”, “delete record”, “change permissions”, or “modify production state” should still require an explicit gate.

A workspace-wide choice like “allow low-risk tools” is much coarser. It delegates the risk classification to the platform and removes the operator’s ability to encode domain-specific policy.

For sensitive internal MCP apps this is especially important, because publishing the app to a wider workspace just to regain approval controls is the wrong security tradeoff.

I would strongly prefer the previous per-action control to remain available for private/agent-scoped MCP connections, ideally with an explicit effective-policy view showing:

tool/action → current approval rule → source of that rule (agent / workspace / admin policy).

That would also make regressions like an existing Custom configuration silently becoming “Allow Low-risk Tools” immediately visible instead of changing behavior underneath a previously verified agent.

5

Same read as Daareek: this looks like a regression, and I don’t have a fix for the UI.

Since you own the MCP server, three things you can do on your side:

  1. Don’t rely on annotations for this. The Apps SDK reference says: “These hints only influence how ChatGPT or Codex frames the tool call to the user; servers must still enforce their own authorization logic.” So destructiveHint may get you a prompt, but it is not a guarantee. I could not find how “Allow low-risk tools” maps annotations to ask vs. auto.
  2. Log the initialize request ChatGPT sends and check if it declares capabilities.elicitation. If it does, your server can ask for confirmation itself on the sensitive tools. I have not tested this in ChatGPT, so please treat it as something to check.
  3. The gate that survives UI changes is server-side. The sensitive tool refuses to run until an approval is recorded out of band (Slack, an email link, a queue). This is a design pattern, not an OpenAI feature.

One untested idea: approval looks to be set per connected app, so splitting auto-run writes and gated writes into two MCP apps might get the split back.

If your tools are Python, I maintain agent-airlock, which has a @requires_human_oversight decorator for point 3. It is sync-only, and you bring your own approver transport.