A Single Link Could Turn ChatGPT's Agent Builder Against Its Own User

A URL Parameter Became an Agent-Creation Command

Researchers at Zenity Labs disclosed a cross-site request forgery flaw in OpenAI's ChatGPT Agent Builder, codenamed AgentForger, that let a crafted link build and activate an autonomous agent inside a victim's account with no further action required. The tool accepted an initial_assistant_prompt value directly through the URL. A logged-in user who clicked a link shaped like chatgpt.com/agents/studio/new with an embedded prompt would have that prompt automatically submitted and executed, creating an attacker-defined agent already wired to whatever connectors the account had approved: Outlook, Gmail, Teams, or Slack among them, with approval prompts disabled by default. OpenAI patched the issue on June 8, 2026, and separately announced it will deprecate Agent Builder entirely by November 30, 2026, directing users to the Agents SDK instead.

Authorization, Not Code, Is the New Surface

For two decades, web risk models were built around code: a vulnerable plugin, an unpatched dependency, a misconfigured server. AgentForger sits somewhere else — a request-forgery flaw in the layer that decides which automated entity gets to act on an organization's behalf, and with what permissions inherited by default. That layer barely existed as a named attack surface before products let agents hold their own credentials and take actions unsupervised. WebPulse's own scoring engine already tracks a related AI-Readiness dimension across the frameworks it detects, precisely because agent-facing capability and agent-facing risk are emerging on the same timeline, not one after the other. This is a single disclosed case, not evidence of a broader pattern yet, but it previews a category of exposure that framework- and plugin-level scanning was never built to catch.

Existing Scoring Systems Don't See This Yet

Executives evaluating exposure typically lean on CVE counts, the CISA Known Exploited Vulnerabilities catalog, and EPSS exploitation-probability scores. As of this week, the KEV catalog holds 1,653 entries and 100 CVEs sit above the 0.5 EPSS threshold. AgentForger carries no CVE identifier at all — it is a logic flaw in a SaaS product's request handling, not a code vulnerability entered into a public registry, and it would not appear in any dashboard built around CVE or plugin-risk counts. That gap is the point: the instruments organizations already trust for exposure reporting were built to catalog known code flaws, not authorization logic inside the agent products now being connected to email, chat, and file systems.

What Budget-Signers Should Take From This

The takeaway is not that agent tooling is unsafe by default, and it is not a reason to pause deployment. It is that governance questions — who can create an agent, what connectors and permissions it inherits automatically, and how quickly a grant can be revoked — now belong on the same review cycle as identity and access management, not left to whichever team first switched the feature on. Teams already running agent-builder products, from OpenAI's or any vendor's, gain little from waiting for a CVE to appear before asking how agent creation is authorized, logged, and reversible. A short checklist covering those three questions costs little to run and closes a gap most organizations have not yet audited.