ChatGPT Workspace Agents Security: Workspace Agents for Enterprise and Business, Shared Connections and Custom MCP Controls
ChatGPT workspace agents are shared, scheduled and triggerable from Slack or an API, and they act through whichever connection the builder chose. OpenAI ships real controls for this. They stop at the edge of what OpenAI can see, and the custom MCP tools your agents call into your own systems sit on the other side of that edge.
Direct answer
ChatGPT workspace agents are reasonably well governed for OpenAI managed apps: admins control who can build and publish, write actions default to requiring approval, and the Compliance Platform exports immutable logs. The gaps are shared connections that let anyone using an agent act as its builder, connector constraints that do not filter returned data, and custom MCP calls into your own systems, which need per call policy enforced on your side.
Try it live
Watch AgentShield block an attack in real time.
Pick a scenario and drive the inspection lane yourself. No signup needed.
Run a request
Runs the live engine on your text. Nothing is stored, no account needed.
Inspection lane
INSPECTINGPolicy trace
High-risk action held for approval
Audit trail
- § · → → →
The risk
A revenue operations lead builds a workspace agent that reads new leads, updates the CRM through a custom MCP server and posts a summary in a Slack channel every morning. To make it work in Slack, every connection has to be shared, so the agent runs as one account for everyone who mentions it. Six weeks later a contractor in that channel asks it to export the full pipeline, and the agent does exactly that, with the builder credentials, and nothing in the path asked whether it should.
How AgentShield handles it
Keep OpenAI in charge of what it governs well: workspace roles, app availability, write approvals on managed connectors and the compliance log export. Put AgentShield in front of the custom MCP servers your workspace agents call, so every tool call into your CRM, billing, ticketing or internal APIs is checked against a policy you own, scoped to the agent and the invoking user, held for approval when it is high impact, inspected for injected instructions in what comes back, and recorded with the verdict.
The controls
The controls that secure what a shared ChatGPT workspace agent may do through your custom MCP tools.
What ChatGPT workspace agents can do in your systems, and why that is a security question
Workspace agents are shared agents that live inside a ChatGPT Business, Enterprise, Edu or Teachers workspace, and they are built to act, not just answer. OpenAI released them in research preview on April 22, 2026. They are powered by Codex, they run in the cloud, and one agent can be used by a whole team in ChatGPT, deployed into a Slack channel, put on a schedule, or started by an API call from another system. OpenAI positions them as the team successor to custom GPTs, and they are one of the two destinations OpenAI names for customers of Agent Builder, which shuts down on November 30, 2026 (our OpenAI Agent Builder shutdown page covers that migration).
That set of surfaces is what makes them a security question. A custom GPT waited for a person to type. A workspace agent can wake up at 9 AM on Monday, read a shared drive, call a custom MCP server that writes to your CRM, and post the result where forty people can see it, with nobody at the keyboard. OpenAI's own help center describes the reach plainly: you can "connect it to apps and tools, share it with teammates or your workspace, use it in Slack, run it on a schedule, or trigger it through an API."
Each surface changes two things at once: whose credentials the agent uses and who is allowed to start it. The table is the fastest way to see where the exposure sits.
| Surface | Who can start a run | Whose credentials it acts with | What to watch |
|---|---|---|---|
| ChatGPT, interactive | Anyone the agent is shared with | The end user connection where the app supports it | Lowest risk. The person running it is usually the person whose data it touches |
| Slack channel | Anyone in the channel who mentions the agent | Shared or agent owned connections only. OpenAI says Slack cannot pause a run to authenticate each person | Everyone in the channel inherits the builder's reach |
| Schedule | Nobody. It runs on its own | The configured connections | No human watching when write actions come up |
| API trigger | Any system holding a Workspace Agent access token | The configured connections | The API returns 202 Accepted with no run ID, so the caller never sees what happened |
| Custom MCP server | Whatever started the run | The token your MCP server was set up with | OpenAI sees the call. It does not know your business rules for it |
The API row deserves a second look. OpenAI's documentation is explicit that "the API queues the agent run and returns 202 Accepted with no response body. It does not return a run ID, and the agent's response cannot currently be retrieved through the API." If you wire a workspace agent into a procurement or support workflow through that trigger, the calling system has no receipt. Your evidence of what the agent did has to come from somewhere else, and that is a design decision to make before launch, not after an incident.
The shared connection problem: whose credentials does a workspace agent use?
Every app connection on a workspace agent is either an end user account or an agent owned account, and that single setting decides who the agent acts as. With an end user account, each person running the agent authenticates with their own login, so the agent can only reach what that person already can. With an agent owned account, the agent uses one shared connection for everyone, which is convenient and is also required for Slack.
OpenAI is direct about the risk. On publishing with personal connections, its help center warns: "Anyone who can use the agent may be able to access data or perform actions through those connections as the creator." On Slack: "Other people may be able to trigger actions through that connection when they use the agent in Slack." And its recommendation for agent owned connections is to use a service account and limit access "to only what the agent needs."
That advice is right, and it is also where most rollouts drift. A service account scoped to "what the agent needs" on day one tends to grow. Someone adds a second workflow, the account gets write access to one more object, and the agent now carries a credential broader than any single person who invokes it. Identity for agents is its own discipline for this reason, and our AI agent identity page covers why an agent should never simply borrow a human's access.
The attack that made this concrete was AgentForger. Zenity Labs showed in 2026 that a crafted link could make ChatGPT's agent builder create an attacker controlled workspace agent using the victim's own connectors, and in its words "a single link could hijack OpenAI's ChatGPT Agent Builder to stand up an attacker-controlled AI agent with a real employee's access and its approvals." OpenAI fixed it on June 8, 2026, before the public write-up on July 24. The fix closed that path. The lesson stands: in this product, whoever gets an agent built also gets the reach of its connections. (Zenity is also a vendor in this space, and we compare it honestly on our Zenity alternatives page.)
| Configuration | What can go wrong | Control that actually helps |
|---|---|---|
| Agent owned connection on a personal account | Every user of the agent acts as that person, including in Slack | Move to a dedicated service account with the narrowest scope the source system allows |
| RBAC lets a group publish agents with personal connections | Creators share their own mailbox or drive reach with the whole audience | Restrict that permission to a small builder role and review published agents monthly |
| Agent deployed to a busy or cross company Slack channel | Contractors or guests in the channel can trigger actions | Deploy only to employee only channels and set the agent to mention only replies |
| Custom MCP server with one broad API token | Any run can call any tool the server exposes, with any arguments | Per tool, per argument policy enforced in front of the MCP server |
What OpenAI's built-in workspace agent controls cover, and what they do not
OpenAI ships more governance for workspace agents than most agent platforms do, and a security team should use all of it before buying anything. The controls below come from OpenAI's help center and its Workspace agents security overview, current as of April 29, 2026. The right hand column is the honest limit of each one.
| OpenAI control | What it does | Where it stops |
|---|---|---|
| Workspace RBAC | Controls who can use, build, publish, publish with shared connections, and deploy to Slack | Decides who builds agents, not what a given run is allowed to do |
| Admin app and action availability | Per app, allow all actions, read only, or a custom set, and decide how new actions are handled | Workspace wide. It cannot tell a harmless update from a harmful one on the same action |
| Write action approvals | Write actions default to Always ask during a run | Builders can set some actions to Never ask, and a scheduled run has nobody watching in real time |
| Connector Action Constraints | Builder defined rules that limit parameters, such as only emailing one domain | OpenAI: "They do not filter or restrict the data a connector returns in response" |
| Compliance Logs Platform and Compliance API | Immutable JSONL logs of runs, connector calls, triggers and memory, plus full agent configuration and traces | After the fact. Roughly 10 minute windows, p99 under 30 minutes from event to log |
| Spend controls | Workspace limits and role level credit pools | OpenAI says agent specific budget caps or alerts "are not currently exposed as a distinct product surface" |
Two of those limits matter more than the rest. The first is the Connector Action Constraints sentence. A constraint governs what the agent asks a connector to do, and OpenAI's own example is that a rule blocking a search for the word "confidential" would not stop an otherwise permitted action from returning an email that contains it. Returned content is also where indirect prompt injection arrives: an instruction hidden in an email, a shared doc or a ticket that the agent reads mid run. Nothing in the constraint layer inspects it. Our prompt injection protection exists for exactly that path.
The second is timing. The compliance logs are good evidence, immutable and exportable to your SIEM, but they describe what happened ten to thirty minutes ago. For an agent that can post, send or update records on a schedule, logging tells you what to clean up. It does not prevent the action. That split between after the fact evidence and in path enforcement is the same one we see on every platform we cover, and it is why the audit trail and the policy decision need to live in the same place.
For managed connectors such as Gmail, Google Drive, SharePoint and Slack, OpenAI's controls are what you have, because traffic to those apps runs inside OpenAI's platform. For the custom MCP servers your builders add, the call leaves OpenAI and lands on infrastructure you run, and that is where you can enforce your own rules on every request.
A rollout checklist for ChatGPT workspace agents in a US enterprise
Workspace agents are off by default for ChatGPT Enterprise workspaces, so there is a clean moment to set things up before the first agent ships. This is the order we would do it in.
- Map roles before you enable anything. Separate who can use agents, who can build them, who can publish to the directory, and who can publish with shared connections. The last permission should be a short list.
- Set app actions to read only by default. Turn on write actions per app only when a named workflow needs them, and choose admin review for actions added later.
- Require service accounts for every agent owned connection. No personal mailbox or drive behind a shared agent, and each service account scoped to one workflow.
- Keep write approvals on Always ask for anything that sends, deletes, posts or pays. Treat any Never ask setting on a write action as a change that needs security sign off.
- Limit Slack deployment to employee only channels, with mention only replies, and remember that everyone in that channel runs the agent as its connection.
- Put custom MCP servers behind a policy gateway. Per tool and per argument rules, approval for high impact calls, and inspection of tool results before the agent sees them. Our MCP gateway page explains the pattern.
- Stream the Compliance Logs Platform into your SIEM from day one, and alert on connector failures and new published agents, not just volume.
- Store API trigger tokens in a secrets manager and give every triggering system its own token, since the trigger itself returns no run ID you can reconcile later.
- Review published agents on a schedule. Version history lets you see what changed. "Can chat" access also lets a user view an agent's instructions and tools, so do not put secrets in instructions.
If your team is migrating flows off Agent Builder at the same time, treat each rebuilt flow as a new agent and run it through this list. A flow that relied on an approval node in Agent Builder does not carry that approval over on its own, so rebuild it explicitly in the new agent and test it before the old flow stops. The same thinking applies to human approval gates for AI agents on any platform.
Where AgentShield fits with ChatGPT workspace agents, and where it does not
AgentShield sits in front of the custom MCP servers and internal APIs your workspace agents call, and it does not sit between ChatGPT and OpenAI managed connectors. That boundary is the whole answer, so here it is by need.
| Your need | Use OpenAI's built-in control | What AgentShield adds |
|---|---|---|
| Decide who can build and publish agents | Yes, workspace RBAC | Nothing. Buy nothing for this |
| Agents that only read Drive or SharePoint and summarize | Yes, read only app actions and source permissions | Nothing. Buy nothing for this |
| Approve Gmail sends or Slack posts | Yes, write approvals and Connector Action Constraints | Nothing on that path, it runs inside OpenAI |
| Control what a custom MCP tool may change in your CRM, billing or ticketing system | Partly. OpenAI sees the call but not your business rules | Per tool and per argument policy, scoped to the agent and the invoking user, enforced before the call reaches your system |
| Stop injected instructions in data your MCP tools return | No. Constraints do not filter returned data | Inspection of tool results for injection and sensitive data before the agent reads them |
| Human approval on a scheduled or API triggered run | Always ask exists, but nobody may be watching | Out of band approval with the full call and arguments, and a default deny if nobody answers |
| Evidence at the moment of decision | Compliance logs, 10 to 30 minutes later | An immutable record of each call, the policy verdict and the approver, exportable to the same SIEM |
Three of those seven rows say buy nothing, and we mean it. If your workspace agents only read and summarize, OpenAI's controls are enough and a gateway would add latency for no benefit. The case for AgentShield starts when a builder adds a custom MCP server that can write to a system of record, because from that point the most consequential actions your agents take happen on infrastructure OpenAI does not govern. The same argument holds for agents built on the OpenAI Agents SDK, where you own the tool layer outright.
Setup is a change to where the custom MCP connection points. You register the MCP server behind AgentShield, write policy per tool (for example, allow CRM reads for any user, allow updates only on records owned by the invoking user, hold any bulk export for approval), and the workspace agent keeps working as before. The tool permissions feature is where those rules live.
FAQ
Common questions about chatgpt workspace agents security.
Are ChatGPT workspace agents secure?
They are well governed for OpenAI managed apps: workspace RBAC, read and write action controls, write approvals that default to Always ask, and immutable compliance logs. The real risks are shared connections that let every user act as the builder, especially in Slack, returned data that constraints do not filter, and custom MCP tools that write to your own systems without your business rules applied.
What are ChatGPT workspace agents?
They are shared, Codex powered agents in ChatGPT Business, Enterprise, Edu and Teachers workspaces, released in research preview on April 22, 2026. A team builds an agent once, connects apps, files, skills and custom MCP servers, and then uses it in ChatGPT, deploys it to Slack, runs it on a schedule, or triggers it from another system through an API.
Who can build workspace agents in ChatGPT Enterprise?
Workspace agents are off by default for ChatGPT Enterprise workspaces. Admins enable them and then use role based access controls to decide who can use agents, build them, publish them to the workspace directory, publish them with shared connections, and deploy them to Slack. The publish with shared connections permission is the one to keep to a short list.
Do ChatGPT workspace agents ask for approval before write actions?
By default, yes. Write actions for apps and connectors are set to Always ask during a run. Depending on the app, builders can change specific actions to Never ask or a custom setting. On a scheduled run or an API triggered run nobody may be watching, so high impact actions need an approval that reaches a named person and denies by default.
How much do ChatGPT workspace agents cost?
OpenAI bills workspace agents in credits that are consumed when they run. Usage rises with the number of users, how often the agent runs, file and context size, tool and MCP calls, schedules and busy Slack channels. Admins can set workspace limits and role level credit pools, but OpenAI says agent specific budget caps or alerts are not currently a distinct product surface.
Can ChatGPT workspace agents run in Slack?
Yes. You add the ChatGPT Agents app to a Slack channel and connect the agent to it. Every app connection must then use shared authentication, because Slack cannot pause a run to sign in each person. That means anyone in the channel can trigger actions as the connection owner, so deploy only to employee only channels.
Are ChatGPT workspace agent actions logged for compliance?
Yes, for eligible Enterprise and Edu customers. The Compliance Logs Platform exports immutable JSONL files covering agent lifecycle, runs, connector calls, OAuth resolution, triggers, skills and memory events, in roughly 10 minute windows with p99 under 30 minutes. The Compliance API also exposes every agent configuration, change audit logs and run traces.
Does AgentShield work with ChatGPT workspace agents?
Yes, on the custom MCP path. You register the MCP servers your workspace agents call behind AgentShield, which checks each tool call against your policy, holds high impact calls for approval, inspects returned data for injected instructions and records every verdict. It does not sit on OpenAI managed connectors such as Gmail or Slack, where OpenAI's own controls apply.
More use cases