Approve ChatGPT workspace-agent actions before connecting internal tools

As of July 7, 2026, the practical question around ChatGPT workspace agents is no longer just whether a team can make a repeatable agent. The sharper question is what happens when that agent can reach internal tools, shared app accounts or custom MCP actions.

OpenAI's workspace agents documentation describes agents that can work with apps, custom MCPs, tools, files, skills and schedules. It also says write actions for apps and connectors are set to ask during an agent run by default, and describes connector action constraints for narrowing how supported connector actions may be used. OpenAI's apps in ChatGPT documentation separates permission options such as asking before app use, asking before changes and allowing actions without a prompt.

That is the choice small teams need to make before the pilot feels normal: should this agent only gather and draft, or should it also change records, send messages, post updates or create tickets?

Quick answer: keep the first shared agent read-oriented unless the team can name the job, the source account, the write action, the approval prompt and the action limit. A vague "internal tools" agent is not ready for broad use.

Start with the internal tool job

Do not start with the agent template. Start with the internal tool job.

Write one sentence:

"This agent is allowed to use this tool to do this job."

Good first jobs sound narrow:

• collect status from a project tracker;
• draft a weekly customer-risk note from approved records;
• prepare a meeting brief from a known folder and calendar;
• summarize tickets that match one queue;
• find the current owner of a process.

Riskier first jobs sound open-ended:

• update customer records;
• post to a team channel;
• file tickets automatically;
• send external email;
• change access, plans, billing or account settings.

The difference is not whether the agent is useful. The difference is whether a mistake stays inside a reviewable draft or becomes a system change.

Split read, draft and write actions

Treat every connected tool as three possible permissions, not one.

Read means the agent can fetch or search information. Draft means it can prepare a message, update, ticket, document or checklist without submitting it. Write means it can change something outside the chat.

Those should not have the same approval rule.

For a first pilot, a sensible pattern is:

| Tool behavior | First-pilot default | Why it matters | | --- | --- | --- | | Read a scoped source | Allowed for test users | The agent needs evidence to be useful. | | Draft a response or update | Allowed, with source trail | Drafts save time but remain reviewable. | | Post, send, edit or delete | Ask every time | The action changes the shared system. | | Change permissions or money | Keep out of scope | The blast radius is too high for a first run. |

OpenAI's admin controls documentation points admins toward app availability, permissions and action controls. Use those controls before the agent is shared, not after the first awkward run.

Check the account behind the action

A workspace agent can use different connection patterns depending on the app and channel. That choice matters because the agent may act through the account that is connected to it.

Before the first test, write down:

• whether each app uses the runner's account or an agent-owned account;
• whether a shared or service account is available for team use;
• which folders, projects, channels or records that account can reach;
• whether the same account can send, edit, post or delete;
• who can review logs or run history after the agent acts.

Do not use a personal account as a shared connection unless the team has consciously accepted the risk. A personal connection can make the agent look like a team workflow while still depending on one person's permissions, records and access boundaries.

Test the approval moment, not only the answer

Most pilot tests check whether the agent gives a decent answer. That is not enough when internal tools are involved.

Test the moment right before an action happens:

• Does the agent show what it is about to change?
• Does it identify the target system, record or channel?
• Does the approver understand the source behind the action?
• Can the user edit the draft before approving?
• Does the agent stop when the source is missing or conflicting?

If the approval prompt is vague, the control is weak. A user should not approve "update this" without seeing what "this" is, where it goes and which source supports it.

The approval step should feel boring. It should be clear enough that a busy operator can say yes, edit or stop.

Add constraints before trust expands

Approval prompts are useful, but they are not the whole control. A better first pilot combines approval with narrow action constraints.

For example, a useful constraint might limit an agent to one project board, one customer folder, one internal status document or one permitted recipient domain. That does not make every answer safe. It does reduce the chance that a broad connected app becomes a broad operational tool by accident.

Use constraints for the action, not as a substitute for source review. If an app can search many records, a constraint on sending or editing does not automatically make all returned data appropriate for the agent's answer. The team still needs the earlier office-search checks: source ownership, permission path and a citation trail that a person can inspect.

Keep custom MCP apps on a shorter leash

OpenAI's developer mode and MCP apps documentation says OpenAI-built apps are search-only today, while custom MCP apps are the route for write or modify capabilities. That makes custom apps powerful, but also easier to over-trust.

Before connecting a custom internal app to a shared agent, answer four questions:

• Which objects can it read?
• Which objects can it change?
• Which fields are hidden from the agent?
• Which actions need human approval every time?
• Which action constraints keep the app inside this one workflow?

If the internal system has messy permissions, old records or weak audit logs, do not give the agent broad tool access first. Use a narrower search or fetch pilot, then add write actions only after the answer path is reliable.

For company-knowledge style work, the earlier AI office-search source map is still the right first step. For actions, the extra step is approval design.

Make the first agent boring on purpose

A boring first agent might:

• read a known project board;
• draft a weekly update;
• cite the records it used;
• flag missing information;
• ask before posting anywhere;
• leave a visible run history.

That is less exciting than an agent that "runs operations." It is also much easier to trust.

The goal is not to prove that an agent can touch every internal tool. The goal is to prove that one repeated workflow becomes faster without making the team nervous about silent changes.

If that works, expand one boundary at a time:

• more users;
• one more source;
• one more draft type;
• one low-risk write action with approval;
• a scheduled run after the review process is stable.

Do not expand all five at once.

The approval checklist

Before publishing a workspace agent that can use internal tools, check:

• The agent has one named job.
• Each connected tool has a read, draft or write role.
• Shared or agent-owned accounts are scoped to only what the job needs.
• Connector action constraints narrow supported actions where possible.
• Write actions ask before sending, editing, posting or deleting.
• High-risk actions stay out of scope.
• Test users include one person who should see the source and one who should not.
• The approval prompt shows the target, change and source trail.
• Someone owns the agent after launch.

If those answers are not written down, the agent is not ready for broad use.

Small teams do not need a perfect governance program to test workspace agents. They do need a clear line between "help me prepare the work" and "change the system for me." Keep that line visible until the workflow earns more trust.