All posts
Unproven Execution

AgentForger: One URL Provisions a ChatGPT Insider

A crafted chatgpt.com URL silently provisioned a Workspace Agent bound to a victim's already-authorized Gmail, Slack, and Drive connectors

Securityv0 Intelligence Team OWASP: ASI05 sv0 finding: unproven_execution
chatgpt openai workspace-agents unproven-execution csrf oauth-connectors

The Incident

On 2026-07-23, Zenity Labs disclosed AgentForger, a cross-site request forgery affecting OpenAI’s ChatGPT Workspace Agent Builder. A single URL of the form chatgpt.com/agents/studio/new?template_name=<t>&initial_assistant_prompt=<attacker-prompt>, clicked by a logged-in user with Workspace Agents access, caused the Builder to auto-submit the attacker’s prompt and provision a fully-configured autonomous agent — with tools, schedule, and instructions — with no visual confirmation and no OAuth dialog. The forged agent inherited the user’s already-authorized connector grants across Gmail, Outlook, Google Drive, SharePoint, Slack, and Teams. Zenity’s proof-of-concept polled attacker email every five minutes for TASK:-prefixed commands, giving the operator persistent C2 through the user’s own account long after the phishing tab was closed.

Zenity researcher Mike Takahashi reported the flaw via OpenAI’s Bugcrowd program on 2026-06-04. OpenAI acknowledged it the next day and shipped a fix on 2026-06-08 by removing the initial_assistant_prompt parameter. No CVE has been publicly assigned. Zenity’s disclosure describes a proof-of-concept; no named victim organization was reported.

MITRE ATT&CK coverage: T1204.001 (User Execution: Malicious Link), T1550 (Use Alternate Authentication Material — inherited connector OAuth grants), T1078.004 (Valid Accounts: Cloud Accounts), T1102 (Web Service — email-based C2 with the TASK: protocol).

The Authority Path That Failed

Two identities carried authority in this attack, and both were exercised beyond what a single click could have authorized. The first was the victim’s authenticated ChatGPT browser session. That session held broad authority — create Workspace Agents, attach any of the account’s authorized connectors as tools, configure schedules, run agents autonomously against enterprise SaaS. The scope it exercised on a phishing click was the silent provisioning of a persistent agent that the user never saw and never approved. The trust anchor that failed first was OpenAI’s treatment of the initial_assistant_prompt URL parameter as executable input auto-submitted in the user’s session, rather than as user-suggested content that required an explicit “Create this agent” confirmation gesture.

The second identity is the forged agent itself — a fresh non-human identity that inherited the account’s connector OAuth grants and continued operating after the phishing tab was closed. The account-level OAuth consents the user granted months earlier to connect Gmail, Slack, or Drive were never grants to any future agent the user’s session might provision, but the platform bound them that way by default. The fix OpenAI shipped closes this specific CSRF; the authority-inheritance pattern — connector grants being account-wide authority that any agent-provisioning path inherits — remains the class.

SecurityV0 Perspective

This fits unproven_execution. A framework instantiated an agent with code-adjacent tools attached — send-mail, read-mail, calendar-create, drive-read, Slack-post — that no operator explicitly authorized for that specific agent. The connector OAuth grants existed at the account level from prior use, but their binding to this new agent, on this schedule, executing these instructions, was never a human decision. Same shape as the Langflow CSV Agent + Python REPL pattern: a framework attached execution capability to an agent that no operator explicitly asked for.

What To Do

  • Inventory every Workspace Agent your organization can observe. For each agent, record its instructions, schedule, bound connectors, and provisioning timestamp. Flag any agent your policy has not explicitly approved, and escalate visibility gaps to the platform owner.
  • Revoke stale connector OAuth grants. Every account-level connector grant is an implicit tool bundle for any agent-provisioning path that runs under that identity. Rotate through your authorized ChatGPT users and disconnect Gmail, Outlook, Slack, Teams, Google Drive, and SharePoint connections that are not actively used.
  • Require a per-agent, per-tool consent step in your agent-provisioning path. Treat “user session has authority to create agents” and “an incoming HTTP request creates one” as separate authorizations. Any agent-builder surface should require an explicit user gesture — not a URL parameter — to bind connectors to a new agent.
  • Use available platform and SaaS audit trails to detect unusual agent activity. Alert on new agents created outside business hours, unexpected connector use, and mail or collaboration activity to destinations never previously used by that identity.
  • Rehearse the forensic answer. For every enterprise ChatGPT user, be able to answer within one incident-response hour: which agents exist under this identity, when each was created, what its instructions say, and which mailboxes, channels, and drives it has touched in the last 72 hours.

Sources

All posts