OpenAI's Workspace Agents can connect to Outlook, Gmail, Slack, Google Drive, SharePoint, and Teams, execute actions across those services, and run on a schedule. They’re built through a conversational agent builder that lets users describe an agent in natural language, configure tools, preview its behavior, and publish it.

During our research, we discovered that this workflow could be driven entirely by an attacker-controlled URL.

We call it AgentForger: a Cross-Site Request Forgery (CSRF) that doesn't forge a single request; it forges an entire autonomous agent, attacker-controlled and living inside your organization's trust boundary.

Under normal use, creating a Workspace Agent is an interactive process. A user typically:

That flow is supposed to include several moments where the user is in control: choosing the template, providing the instructions, approving connected tools, reviewing approval settings, and deciding whether the agent should go live.

The issue we found is that this interactive flow can be preloaded, started, and driven from the URL itself. Completely without user interaction, except for the victim clicking the link.

The Builder is accessible at:

During testing, we found that the Builder accepts initialization state through URL parameters. Two were particularly relevant:

The template_name parameter selects a starter agent template. For example, template_name=chief-of-staff opens the Builder with the “Chief of Staff” template preselected. Templates are prebuilt starting points for common agent workflows, giving the Builder an initial structure, default behavior, and suggested tools.

The more important parameter is initial_assistant_prompt. This parameter provides the instructions to the Builder. We found that when the page loads, the value of initial_assistant_prompt is not merely placed into the prompt box. It is automatically submitted and executed.

That means an instruction embedded inside a URL can become the first command the Builder acts on.

Because the prompt can be inserted directly into the link, the attacker does not need to send a raw request or interact with the victim’s browser directly. They can send a normal-looking phishing link containing attacker-controlled instructions:

When a logged-in victim clicks the link, ChatGPT opens the Builder in the victim’s authenticated session and automatically submits the prompt embedded in the URL. This turns a regular chatgpt.com link into a way to drive the Builder without further user interaction.

The attack requires a victim who is logged into ChatGPT, has access to Workspace Agents, and has at least one authorized connector. By “authorized connector,” we mean an integration the victim had already connected to ChatGPT during normal prior use, such as Outlook, Gmail, Slack, Google Drive, SharePoint, or Teams. Because that connection already exists, the attack does not need to trigger a new OAuth consent screen.

Once the user clicks the malicious link, the agent creation flow begins. Below, we describe what happens after the click. It requires no further user interaction. Let’s dive in.

The prompt below is embedded in the initial_assistant_prompt URL parameter. Once the victim clicks the link, Workspace Agent builder automatically submits this prompt and begins carrying it out.

This prompt is intentionally direct. The goal is to test whether attacker-controlled URL content can drive the Builder through the full agent creation flow without additional user interaction.

The Builder treats the prompt as a to-do list and works through it autonomously. In our PoC, it:

Preview Mode is meant to allow users to test an agent before publishing it. In this flow, however, Preview is not just a visual preview or dry run. It executes the newly created agent against the victim’s connected accounts using the approval settings that have just been configured.

Because the prompt has already switched Outlook approvals to “Never ask,” the Preview run executes without showing an approval prompt.

We now have a working agentic insider inside the org’s trust boundary. Next, we need a way to dispatch assignments to it. This is where scheduled tasks come in handy.

Workspace Agents can be scheduled to run automatically. The scheduler lets a user configure an agent to execute on a recurring cadence, such as hourly or daily, without manually opening ChatGPT each time.

In normal use, this is useful automation: an agent can check for updates, summarize information, or perform a recurring workflow on the user’s behalf. In this attack, the same scheduler becomes the persistence mechanism.

The scheduled run is what turns the attack from a one-time execution into something closer to command-and-control. Once the agent is published, the attacker does not need the victim to click another link, keep the Builder tab open, or visit ChatGPT again. The agent can continue waking up on its schedule, checking the user’s email inbox for attacker-controlled instructions (all the attacker needs to do is send an email), carrying out new instructions with the victim’s connected services, and sending results back out.

In other words, the forged agent becomes a persistent operator. The original click installs it; the schedule keeps it alive; and the connected apps give it a source of commands, access to sensitive actions and data, as well as a path to return results.

That is where Part 2 begins. With the operator live, we use the same command channel to task the forged agent like an attacker would: recon the organization, find sensitive data, harvest credentials, impersonate the victim, deliver internal phishing, and stage business email compromise.

The exploit relies on two behaviors that combine into a complete attack chain.

The Builder treats the initial_assistant_prompt query parameter as executable input rather than user-supplied content requiring confirmation.

An attacker-controlled URL therefore initiates state-changing operations inside the victim’s authenticated session without explicit user intent.

Traditional CSRF attacks cause a victim’s browser to issue unintended authenticated requests. AgentForger applies the same principle to AI systems: an attacker-controlled URL initiates authenticated, state-changing operations within the victim’s session. Rather than forging one request, it forges the creation and deployment of an autonomous agent.

The Builder allows the same prompt to modify security-relevant configuration, including approval policies and execution schedules.

The mechanism intended to require human approval for sensitive actions can itself be disabled by the instructions being executed.

Together they tick every box of the lethal trifecta: untrusted input (the URL), access to private data (the connectors), and a way to exfiltrate (send mail). Most exploits have to bypass guardrails to get there; this one is handed a build tool and told to construct an agent with the guardrails already off.

AgentForger turns the Workplace Agents builder into the target.

In a traditional CSRF, the attacker tries to make the victim’s browser perform one unintended action. Here, the unintended action is the creation of a new autonomous system: an agent with tools, approvals, instructions, a schedule, and access to already-authorized connectors.

This post focused on the vulnerability: how one phishing link could drive the Builder from initialization to execution.

That is the core of AgentForger: it does not forge a single request; it forges an entire autonomous agent, attacker-controlled and operating inside the organization’s trust boundary.

In Part 2, we follow the forged agent after it goes live and show the full blast radius. Including reconing the org, sensitive data harvesting, user impersonation. The full blown impact of having an authorized persona acting maliciously inside your org.

Stay tuned.

We reported this to OpenAI through their Bugcrowd vulnerability disclosure program. OpenAI resolved the vulnerability within 4 days of disclosure.

The full timeline:

Our thanks to the OpenAI security team for the fast turnaround.