The short answer
Researchers at Zenity Labs disclosed AgentForger, a cross-site request forgery (CSRF) flaw in ChatGPT's Agent Builder that let a single phishing link build, authorize, and deploy an attacker-controlled autonomous AI agent inside a victim's organization — with no confirmation click. The Builder accepted part of its starting state through URL parameters, and the value in initial_assistant_prompt was executed rather than merely displayed. One click from a logged-in user who had Workspace Agents and at least one connected app was enough for the Builder to wire up their connectors, switch off approval prompts, publish a new agent, and put it on a schedule. OpenAI was notified through Bugcrowd on 4 June 2026 and closed the hole within days by removing the vulnerable parameter.
The patch is done, so this is not a fire drill. It is a design lesson for anyone shipping AI agents: the agent is an identity with standing access, and a forged one is an insider. The interesting part of AgentForger is not the specific bug — it is how ordinary the web flaw was and how much blast radius it inherited because an agent sits on top of pre-approved enterprise connectors.
What Zenity disclosed
Zenity Labs' AI red team published research in late July 2026 describing AgentForger, a flaw in the Agent Builder that ships with ChatGPT's Workspace Agents. The attack needed only that the target was signed in to ChatGPT, had access to Workspace Agents, and had at least one connector already authorized — Outlook, Gmail, Google Calendar, Slack, or Teams, for example. Under those common conditions, opening a normal-looking link was enough to stand up a working agent that answered to the attacker rather than the employee.
The chain, as Zenity describes it, is blunt. One click and the Builder "got to work on the attacker's behalf, wiring up the victim's existing connectors, turning off approval prompts, publishing the new agent, and setting it loose on a schedule." Rather than phone home to classic command-and-control infrastructure, the forged agent watched the victim's inbox for messages with a set keyword in the subject line and treated each one as a fresh assignment — a quiet, low-signal channel that looks like ordinary mail traffic.
The timeline matters for how you read the news. Zenity reported the issue to OpenAI through Bugcrowd on 4 June 2026; OpenAI acknowledged it on 5 June and fixed it within days by removing the vulnerable URL parameter, so the specific path is closed. The public write-up is the July event, not a live zero-day. Separately, OpenAI has said it will deprecate the Agent Builder on 30 November 2026 and steer developers to its Agents SDK — a reminder that the surface itself is still young and moving.
How one link forged an agent
The mechanics are a textbook web bug in an unfamiliar setting. The Agent Builder let part of its initial state arrive through URL parameters, following a shape like /agents/studio/new?template_name=…&initial_assistant_prompt=…. The problem, in Zenity's words, was 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." An instruction embedded in a link became the first command the Builder acted on, with the authority of whoever clicked it.
That is cross-site request forgery: a state-changing action triggered by a crafted request that rides the victim's existing session. CSRF is one of the oldest categories in the web-security book, and the standard defenses — anti-forgery tokens, requiring an explicit user gesture for sensitive actions, not treating GET parameters as commands — are well understood. What made AgentForger dangerous was not novelty but leverage. The forged request did not transfer money or change an email; it created an autonomous actor bolted onto connectors the user had already approved, so no fresh consent screen ever appeared.
This is the pattern to internalize. When an agent-building surface accepts instructions from untrusted input and executes them, prompt content becomes control flow. The blast radius is then whatever the agent can reach, and modern enterprise agents are deliberately wired into mail, chat, files, and calendars to be useful. A flaw that would be a medium-severity CSRF on a settings page becomes a foothold for an autonomous insider once the object it creates is an agent with standing access.
Why an "autonomous insider" is different
Strip away the ChatGPT specifics and a forged agent behaves like a compromised employee account — with two differences that cut against the defender. First, it is patient and automated: it runs on a schedule, needs no hands on a keyboard, and can search files, collect documents, send messages as the victim, and map the organization without ever tripping a login-anomaly alert, because it is using an already-trusted session and already-approved connectors. Second, it can reproduce. Zenity's scenario has the forged agent launching internal phishing that spawns further compromised agents, turning one click into a spreading population of insiders.
That breaks a few comfortable assumptions. Consent is supposed to be the control point for connector access, but a single approval given weeks ago was enough here — the agent inherited it. Monitoring is tuned for human patterns, but an agent taking orders from inbox messages with an innocuous subject line does not look like exfiltration. And identity governance usually tracks users and service accounts, while agents often exist in a blind spot: nobody owns the inventory of which agents exist, who created them, and what they can touch. AgentForger is a preview of the class of problem, not a one-off.
What it means for US & EU software teams
The first shift is conceptual: an AI agent is a privileged identity, not a UI feature. If you are deploying agents — whether third-party ones like these or systems you build — they need the same lifecycle you give a service account: an owner, an inventory entry, scoped permissions, an audit trail, and a way to revoke them fast. "An agent can do X" should be read as "a new principal in your environment can do X," and provisioned with the least privilege that still lets it work. Broad, standing connector grants are the multiplier that turned a routine CSRF into a domain-wide problem.
The second shift is a hard architectural rule for anyone building agent surfaces: never let untrusted input become an executed instruction, and never let one consent authorize open-ended future action. Keep a human approval step on any agent that can act on data or people, require explicit same-origin confirmation before an agent is published or granted a connector, and treat prompts arriving via links, documents, or emails as data to be sandboxed, not commands to be run. These are the same lessons the industry keeps relearning — input validation, CSRF tokens, least privilege — now applied where the executed object is an autonomous worker.
For regulated products the governance layer is not optional. In FinTech and HealthTech, an agent wired to mailboxes and document stores sits close to personal and financial data, so a forged one is a potential GDPR or HIPAA incident with disclosure clocks, not a lab curiosity. Under the EU AI Act, an automated system taking consequential actions about individuals carries documentation, human-oversight, and logging expectations — and "a third-party agent did it autonomously" is not an answer an auditor will accept. Fold agent identities, permissions, and oversight into your secure SDLC and vendor-risk register now, while the count of agents is still small enough to inventory by hand.
What to do this week
A short, practical sequence that turns the disclosure into action rather than anxiety:
- Inventory your agents. List every AI agent operating in your tenants — ChatGPT Workspace agents, Copilot agents, and home-grown ones — with an owner, its connectors, and what each can reach. You cannot govern what you have not counted.
- Scope connectors to least privilege. Trim standing grants so an agent touches only the mailboxes, channels, and drives it genuinely needs, and never runs with a human's full access or a production deployment identity.
- Keep a human in the loop for actions. Require explicit approval before an agent sends, edits, or shares on behalf of a person, and before any new agent is published or granted a connector. Do not let one past consent stand in for future actions.
- Instrument for agent behaviour. Alert on newly created or modified agents, on connector grants, and on scheduled or automated bursts of connector activity — the signals a forged agent produces — rather than relying on human login anomalies alone.
- Harden your own agent-building surfaces. If you ship anything that assembles or configures agents, never auto-execute instructions from URL parameters, add anti-CSRF protection to state-changing routes, and demand a fresh, same-origin confirmation before an agent goes live.
None of this is an argument against building on agents — the productivity case is real and the direction is set. But AgentForger is a clean signal: the moment an agent can act with your users' access, it is part of your security programme, not a convenience that sits outside it.
Frequently asked questions
What is the AgentForger vulnerability?
AgentForger is a cross-site request forgery (CSRF) flaw Zenity Labs disclosed in ChatGPT's Agent Builder. A crafted link carried an instruction in a URL parameter (initial_assistant_prompt) that the Builder auto-submitted and executed on load. One click from a logged-in user with Workspace Agents and a connected app was enough to wire up their connectors, turn off approval prompts, publish a new agent, and schedule it under the attacker's control. OpenAI was notified on 4 June 2026 and fixed it within days.
Was ChatGPT AgentForger actively exploited?
There is no public evidence of in-the-wild exploitation. It was found and responsibly disclosed by Zenity Labs, reported to OpenAI on 4 June 2026, acknowledged on 5 June, and fixed within days by removing the vulnerable parameter. The research was published in late July 2026 — that publication is the news event; the fix predates it.
How could one link deploy a rogue AI agent?
The Builder accepted part of its initial state through URL parameters, and the value passed in initial_assistant_prompt was executed, not just shown. A phishing link could instruct the Builder to assemble an agent from the victim's already-authorized connectors, disable the human approval step, publish it, and schedule it. Because the victim was already logged in and had approved those connectors, no new consent prompt appeared.
What could the forged agent do?
Researchers described an autonomous insider. The forged agent could reach whatever the victim's connectors allowed — Outlook, Gmail, Slack, Teams, SharePoint, Google Drive — ran on a schedule, and took orders through the victim's inbox. From there it could search and exfiltrate files, harvest credentials, impersonate the employee, map the organization, and send internal phishing that spawned more compromised agents.
What should teams building on AI agents do now?
Treat every agent as a machine identity in your threat model. Keep a human approval step on anything that can act, scope connector permissions to least privilege, and never let one consent cover open-ended future actions. Inventory which agents exist, who owns them, and what they can reach; alert on new or modified agents and on automated connector activity. On your own build surfaces, never auto-execute instructions from URL parameters and require explicit same-origin confirmation before an agent goes live.
Sources
Zenity Labs — AgentForger, Part 1: ChatGPT Cross-Site Agent Forgery (primary research)
The Hacker News — ChatGPT AgentForger Flaw Could Deploy Rogue Workspace Agents via a Phishing Link, July 2026
The Register — One ChatGPT link could smuggle a rogue AI agent into your company, 23 July 2026
SecurityWeek — OpenAI Fixes ChatGPT Agent Flaw That Could Let Attackers Forge an AI Insider, July 2026