Zenity researchers found that a crafted chatgpt.com link could make the Workspace Agents builder select a template and automatically submit attacker-written instructions inside a logged-in user’s session. Their proof of concept continued through connector setup, approval changes, publishing, scheduling and an immediate preview run.
Zenity reported the issue to OpenAI on June 4 and says it was fixed on June 8. The researchers published their findings on July 23. They did not report exploitation outside their testing.
Two URL parameters drove the builder
Zenity’s technical account identifies two parameters accepted by the Workspace Agents builder:
template_name, which selected a starter templateinitial_assistant_prompt, which supplied instructions to the builder
The second parameter created the security problem. Zenity found that its value was submitted automatically when the page loaded instead of remaining in the prompt box for review. A victim who clicked the link did not need to paste instructions or press a submit button.
The attack had prerequisites. The victim had to be signed in to ChatGPT, have access to Workspace Agents and have at least one connector already authorized. The existing connection meant the proof of concept did not need to open a new OAuth flow.
This was not a claim that any visitor could create an agent in any workspace. The link operated inside the victim’s authenticated session and used capabilities already available to that user.
The proof of concept created a scheduled agent
Zenity’s embedded prompt told the builder to create an agent without follow-up questions, attach existing connectors, change connector approvals, add recurring schedules, publish the agent and run it in Preview Mode.
According to the researchers, the builder completed those steps. Their demonstration used several hourly schedules offset from one another, producing an effective five-minute polling interval. The agent checked the victim’s mailbox for messages from an attacker-controlled address, treated messages with a specified subject prefix as instructions and emailed results back.
Part 2 of Zenity’s report documents what the researchers made that agent do in their test environment. It searched connected email, file and collaboration services, found sensitive material, sent internal phishing messages and prepared fraud lures. Those were controlled proof-of-concept actions, not observed attacks against customers.
That distinction affects how the findings should be reported. The vulnerable creation path is documented, and the follow-on actions demonstrate available capability. The public research does not establish an attacker campaign, victim count or real-world data theft.
Existing connections supplied the access
OpenAI’s Workspace Agents cookbook says agents can use connected apps, run on schedules and be shared with other users.
The example shows builders choosing between end-user and agent-owned connections, then limiting individual connector actions. It also says administrators can enforce connector action limits at the workspace level.
OpenAI tells workspace owners to use role-based controls for agent access, building and publishing. These controls explain why the configuration step in Zenity’s demonstration was consequential: the builder prompt changed how a previously connected service could be used.
These are product controls, not evidence that the reported path remains vulnerable. Zenity says OpenAI fixed the flaw before the research was published.
Review builders, agents and schedules
Organizations using Workspace Agents should inventory who can build and publish agents. Keep those permissions narrower than ordinary agent use, especially where builders can attach agent-owned connections or connectors with write actions.
Review existing agents by owner, sharing state, connected app, authentication type, approval setting and schedule. A recurring agent with write access to email or collaboration tools deserves more attention than a private, read-only agent without a schedule.
Limit each connector to the actions the agent actually needs. A reporting agent that only reads calendars and documents should not receive delete access or broad write permissions.
Include agents when a user changes roles or leaves. Reassess the user’s private agents, published agents, schedules and any shared connection that authenticates with that person’s account. An automation can continue to look routine even when its owner or original purpose has changed.
OpenAI patched the reported path, but administrators still need an inventory of who can create scheduled agents, which connectors those agents use and who is responsible for reviewing them.
Verify the inventory against current workspace roles and connector grants. The review is complete only when every scheduled agent has a current owner, an approved purpose, the minimum required connector actions and a documented decision to keep or disable it.