AgentForger Let One ChatGPT Link Build a Persistent Workspace Insider
A vulnerability in OpenAI’s ChatGPT Workspace Agents builder allowed a crafted ChatGPT link to create and deploy an attacker-directed agent in a victim’s authenticated workspace, according to research published by Zenity Labs on July 23. The proof of concept did more than trigger a single unwanted action: it attached previously authorized connectors, changed approval settings, published the agent, and scheduled recurring runs that could continue after the victim closed the page.
Zenity calls the issue AgentForger and describes it as cross-site agent forgery, an agentic extension of cross-site request forgery. The company reported the flaw through OpenAI’s Bugcrowd program on June 4. Its disclosure timeline says OpenAI accepted the report on June 5 and fixed the issue on June 8 by removing the URL behavior that enabled the chain. The public research does not assign a CVE, identify an affected product version, or present evidence of exploitation outside the researchers’ demonstration.
The prerequisites materially constrain the result. The victim had to be logged in, belong to a workspace with Workspace Agents enabled, have permission to create agents, and have at least one connector already authorized. Organization-level policy still bounded which apps and actions were available. Within those boundaries, however, one click could convert the victim’s existing authority into a new autonomous identity without another deliberate approval from the user.
Executable builder state arrived through the URL
Zenity traced the initial weakness to two parameters accepted by the Workspace Agents builder: one selected a starter template, while initial_assistant_prompt supplied instructions. The dangerous behavior was not merely that attacker text appeared in the builder. When the page loaded, ChatGPT automatically submitted the prompt and began acting on it inside the victim’s authenticated session.
The researchers’ prompt instructed the builder to create an agent, attach all previously connected services, set available connector actions to “Never ask,” publish the result, create staggered schedules, and run it in Preview Mode. Zenity says Preview was an execution path rather than a dry-run display, so the newly configured agent immediately operated against connected accounts after approval prompts had been disabled.
This chain separates AgentForger from ordinary prompt injection. The untrusted instruction entered through a first-party URL and targeted the system that defines an agent’s tools, permissions, schedule, and lifecycle. The builder was therefore both an interpreter and a security control plane. Allowing the same natural-language command to create the principal and weaken its approval policy collapsed setup, authorization, and execution into one operation.
Existing OAuth grants supplied the blast radius
The attack did not need to steal a password, session cookie, or fresh OAuth token. It reused connectors the employee had legitimately authorized for normal work, including services such as Outlook, Gmail, Slack, Teams, Google Drive, and SharePoint. Because consent already existed, the proof of concept did not encounter a new provider authorization screen.
That distinction is important for incident response. Traditional identity monitoring may see actions performed by the correct user through an approved SaaS application. The malicious object is the newly created agent and its policy, not necessarily the underlying token. Connector authorization answers whether ChatGPT may reach a service; it does not establish that the user intended this particular agent, instruction set, schedule, or action.
The result resembles the confused-deputy pattern behind the recent Azure DevOps MCP prompt-injection flaw, but AgentForger moved the trust failure earlier in the lifecycle. Instead of poisoning content consumed by an established review agent, the crafted content caused the platform to manufacture the agent that would later consume commands.
Email became a durable command channel
Zenity’s demonstration configured multiple hourly schedules offset by five minutes. On each run, the forged agent checked the victim’s mailbox for messages from an attacker-controlled address with a designated subject prefix, executed the message through connected apps, and emailed results back. The original phishing link installed the operator; ordinary email delivered subsequent tasks.
In the lab, the researchers used that loop to map people and projects across mail, chat, calendars, and file stores; search Drive, SharePoint, Outlook, and Slack for sensitive material; impersonate the victim in internal messages; and prepare phishing and business-email-compromise lures. These are proof-of-concept impacts reported by Zenity, not claims of a real customer intrusion. They nevertheless demonstrate why cross-connector aggregation matters: an agent can correlate context across services and act through the employee’s trusted identity rather than exfiltrating one data source at a time.
The scheduled mailbox loop also illustrates a general persistence primitive. Defenders often focus on malicious system prompts or poisoned memory, as in the MemGhost calendar-memory research. A published agent adds another durable layer: saved instructions, connector grants, approval policy, and schedules can survive the event that created them and accept future attacker input through otherwise legitimate business systems.
Defensive engineering guidance
- Require explicit confirmation for URL-supplied builder state. Query parameters and imported templates should populate inert fields, never auto-submit instructions or initiate authenticated state changes.
- Separate agent creation from security-policy changes. Natural-language setup should not silently lower approval requirements, attach every connector, publish an agent, and schedule execution in one flow. Each trust expansion needs a distinct, comprehensible confirmation.
- Make Preview genuinely non-production. A preview should use synthetic data or read-only test identities. If it can invoke live connectors, it requires the same approvals, audit events, and policy enforcement as a published run.
- Inventory agents as identities. Record creator, creation channel, instructions, connectors, approval modes, schedules, last editor, and run history. Alert when a new agent immediately attaches several data sources or disables action approvals.
- Constrain connectors centrally. Limit high-impact write and delete operations by workspace policy, not only per-agent prompts. Reused OAuth consent should not imply blanket approval for every future agent.
- Detect scheduled command loops. Look for agents repeatedly polling one sender or subject pattern, sending results externally, or combining broad searches with outbound messages. Correlate agent runs with mailbox, chat, file, and identity telemetry.
- Give users a visible kill switch. Workspace administrators need a fast way to enumerate, suspend, and delete agents and schedules, revoke their connector access, and preserve configuration and run logs for investigation.
- Treat first-party links as potentially state-changing. Secure email gateways and user training should not automatically trust a link because its hostname is the approved AI service. Builders and automation consoles deserve the same CSRF assumptions as financial and administrative applications.
AgentForger’s central lesson is that agent lifecycle controls are part of the authorization boundary. The platform correctly recognized the employee and reused connectors the employee had previously approved, yet the user did not intentionally create the resulting operator. For autonomous systems, identity assurance must cover not only who is signed in, but who supplied the instructions, who approved the agent’s authority, and whether publication and persistence reflect a fresh human decision.
Sources: