One click. That’s all it took to turn ChatGPT’s Agent Builder into a mechanism for planting an autonomous, always-on insider inside an enterprise — with the victim’s credentials, their connectors, and every approval prompt silently switched off. The vulnerability, dubbed AgentForger by Zenity Labs and patched by OpenAI on June 8, 2026, isn’t just another CSRF bug. It’s a preview of what phishing looks like when the payload is no longer malware, but a coworker the attacker forged out of thin air.
How a URL Parameter Became a Rogue Employee
According to Zenity Labs’ two-part disclosure, ChatGPT’s Agent Builder accepted an initialization state through URL parameters, including template_name and initial_assistant_prompt. AI Red Team Researcher Mike Takahashi found that when the Builder page loads, initial_assistant_prompt isn’t merely populated into the prompt box — it’s automatically submitted and executed. In other words, an attacker crafting a link like chatgpt[.]com/agents/studio/new?template_name=[...]&initial_assistant_prompt=[malicious prompt] could deliver an instruction that ChatGPT executes on behalf of any logged-in victim who clicks it.
This matters because the trust boundary has shifted. Traditional CSRF hijacks a single action — a fund transfer, a password reset. AgentForger hijacks an entire agent-creation workflow, meaning one click provisions a persistent operator, not a one-shot request. If you’re a security engineer used to auditing form submissions, you now need to audit prompt submissions that spawn autonomous processes with scheduling and connector permissions attached.
The editorial take: URL-driven state hydration was already sketchy in the web app era. In the agent era, it’s arson.
Why “Never Ask” Is the Real Vulnerability
The forged prompt Zenity documented instructed Agent Builder to attach every already-authorized connector — Outlook, Gmail, Google Calendar, Google Drive, Slack, Teams — and set each one to “Never ask.” It then made the agent live, scheduled it to run every hour, and invoked Preview Mode to trigger immediate execution against the victim’s real accounts. Preview, Zenity notes, “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.”
The practical consequence: consent UX designed to protect users became the very knob the attacker turned off. If you’re building any AI agent product, approval toggles must be gated by out-of-band confirmation — because a prompt that can create an agent can also configure the agent’s guardrails to zero. Imagine a marketing analyst at a mid-sized SaaS company clicking what looks like a shared ChatGPT template link during a Slack thread; an hour later, an agent is quietly reading their inbox, exfiltrating attachments from Drive, and scanning Slack DMs for passwords — no popups, no confirmations, no anomalous login.
Prediction: within twelve months, “approval-tampering” will be a named category in agent security frameworks, right next to prompt injection and tool misuse.
The Persistence Problem No EDR Will Catch
Once published and scheduled, the rogue agent doesn’t need the Builder tab to stay open. It doesn’t need the victim to click again. Takahashi describes it plainly: “Each TASK email becomes a new assignment for the agent. The agent is not waiting for another click. It is waiting for instructions.” The attacker’s C2 channel is literally the victim’s inbox — filtered on a subject line starting with “TASK” — and results are exfiltrated as outbound email to the attacker’s address.
For defenders, this is nightmarish. There’s no binary on disk, no unusual process tree, no suspicious network beacon from an endpoint. The activity originates from OpenAI’s infrastructure using legitimate OAuth-scoped connectors. EDR won’t see it. DLP might catch outbound content if you’re lucky. Your SIEM will show a valid ChatGPT agent doing what agents do. If you operate in a regulated vertical — say healthcare or pharma where PHI can leak through a single Drive query — this attack pattern effectively bypasses the endpoint-centric assumptions baked into most compliance frameworks.
The forged agent can also weaponize the victim’s own Teams presence, sending phishing links to colleagues that lead to fake Microsoft login pages — a lateral-movement primitive that skips every reputation filter because the sender is genuinely trusted.
Expect the first public breach attributed to a forged workspace agent within the year, and expect the disclosure to read “the activity used legitimate SaaS connectors and was not detected by traditional endpoint tooling.”
The Broader Pattern of Agent Infrastructure Abuse
AgentForger arrives roughly a month after Zenity’s earlier research showing how threat actors are actively exploiting critical LiteLLM vulnerabilities (CVE-2024-6587, CVE-2026-40217, CVE-2026-35029) and exposed Ollama endpoints to hijack AI infrastructure for offensive operations. Zenity’s framing is sharp: “Self-hosted model servers and agent frameworks keep getting deployed while being misconfigured and unauthenticated, on predictable ports, willing to serve any client.”
Agent platforms — whether SaaS like Agent Builder or self-hosted like LiteLLM and Ollama — extend implicit trust to whoever holds a URL or an unauthenticated port. That’s a database-era security model applied to systems that can act, decide, and persist. Before shipping an agent workflow that could be turned against you, AI agents vs traditional automation is worth reading. OpenAI is also deprecating Agent Builder effective November 30, 2026, urging users to switch to the Agents SDK — which shifts the surface, but not the underlying trust problem.
The prediction is uncomfortable: as more vendors race to ship visual agent builders, we’ll see AgentForger-class bugs in at least three more major platforms before the end of 2026.
FAQ
Q: What is the AgentForger vulnerability?
A: AgentForger is a cross-site request forgery flaw in OpenAI’s ChatGPT Agent Builder disclosed by Zenity Labs. It allowed a single phishing link containing an initial_assistant_prompt URL parameter to auto-execute in a victim’s authenticated session, creating a persistent, scheduled AI agent with all connectors set to “Never ask.” OpenAI patched it on June 8, 2026.
Q: Who was at risk from AgentForger? A: Per Zenity’s report, exploitation required a victim who was logged into ChatGPT, had access to Workspace Agents, and had at least one authorized connector such as Outlook, Gmail, Google Calendar, Google Drive, Slack, or Teams. Any organization with widespread ChatGPT enterprise adoption and connector integrations fit the profile.
Q: How is this different from a normal phishing attack? A: Traditional phishing steals credentials or drops malware on an endpoint. AgentForger installs an autonomous agent that runs on OpenAI’s infrastructure using legitimate OAuth-scoped connectors, receives new instructions via email subject lines beginning with “TASK,” and cannot be detected by endpoint security tools. The victim never has to click a second link.
Key Takeaways
- Audit any product you ship that hydrates state or executes actions from URL parameters — the pattern that enabled AgentForger is common and rarely reviewed as a prompt-injection surface.
- Treat agent approval settings (“Never ask,” auto-schedule, connector attachment) as privileged operations that require out-of-band confirmation, not in-flow prompts.
- Update your incident response playbooks to include enumerating active agents, scheduled tasks, and connector approvals inside SaaS AI platforms — endpoint telemetry will not catch a forged agent.
- Assume that any drag-and-drop agent builder shipping in the next 12 months will have an AgentForger-class flaw until proven otherwise; require vendor attestation on CSRF and URL-parameter execution before adoption.
- If you rely on OpenAI Agent Builder, plan the migration to Agents SDK now — the November 30, 2026 deprecation date is a forcing function, not a suggestion.