Zenity Labs disclosed AgentForger this week, a vulnerability in OpenAI's ChatGPT Workspace Agents that let a single phishing link create, authorise, publish, schedule, and execute an autonomous AI agent inside a victim's organisation. The agent inherited the employee's identity, reused their pre-authorised connectors (Outlook, Gmail, Slack, Teams, Drive, SharePoint), disabled its own approval gates, and polled the attacker's inbox for new instructions every five minutes. OpenAI patched it in four days. No evidence it was exploited in the wild.
The fix was fast. The class of vulnerability is not going away.
How AgentForger actually worked
ChatGPT's Workspace Agents Builder lives at chatgpt.com/agents/studio/new and accepts two URL parameters: template_name and initial_assistant_prompt. Under normal use, building an agent is interactive. You pick a template, write instructions, review connector permissions, set approval gates, test in Preview Mode, and publish. Multiple points where a human is supposed to be in control.
Zenity found that initial_assistant_prompt wasn't just placed into the prompt field. It was auto-submitted and executed. An attacker could embed a full instruction set in the URL, and the Builder would carry it out the moment the page loaded in the victim's authenticated session. No further clicks needed after the initial one.
The payload in Zenity's proof of concept told the Builder to connect all previously authorised connectors, set every permission to "Never ask", create schedules offset by five minutes so the agent runs twelve times an hour, check Outlook for emails from the attacker with "TASK" in the subject, execute whatever the email says using connected apps, and email results back. Then it told the Builder to make the agent live.
One click. The victim sees a ChatGPT page load. In the background, a fully operational agent is now running under their name with their access, taking orders from someone else.
What the forged agent could do
Part 2 of Zenity's write-up demonstrates the blast radius. Once the agent was live, the attacker sent TASK emails and got results back. The demonstrated capabilities:
The agent mapped the organisation by pulling data from Outlook, Slack, Teams, Drive, SharePoint, and Calendar. It returned people, roles, Slack channel IDs, active projects, recurring meetings, and workstreams. That's the kind of internal context an attacker normally builds over weeks of lateral movement, returned from a single emailed assignment.
It found an M&A term sheet, a board presentation flagging missed revenue targets and planned layoffs, and a company-wide employee export with compensation data. It searched Slack for messages containing "pass:" and found a database username and password pair, emailed in plain text to the attacker.
It sent Teams messages from the victim's account asking colleagues to confirm an SSO rollout on an attacker-controlled login page. It prepared a $242,500 wire transfer approval request. It created calendar invites with attacker-controlled attendees. All of it looked like normal internal activity from a trusted employee.
Why this is a new class of problem
The instinct is to file this under "CSRF, patched, move on." I think that undersells it.
Traditional CSRF makes the victim's browser perform one unintended action. AgentForger made the unintended action be the creation of an entire autonomous system. The agent had tools, approvals, instructions, a schedule, and access to already-authorised connectors. It persisted without the victim needing to click again or keep a tab open. Michael Bargury, Zenity's CTO, put it well: "This isn't a forged request, it's a forged insider."
The root cause was two things combining. First, the Builder treated a URL parameter as executable input without confirmation, which is a classic CSRF-adjacent mistake. Second, the same natural-language prompt that created the agent could also disable the security controls meant to govern it. The mechanism intended to require human approval for sensitive actions could itself be turned off by the instructions being executed. Zenity calls this the "lethal trifecta": untrusted input, access to private data, and an exfiltration path, all handed to a build tool that constructs an agent with the guardrails already off.
That second piece is the structural one. Every agent platform that lets natural-language instructions modify security-relevant configuration has this shape of vulnerability latent in it. The specific URL parameter is gone, but the design pattern (agents that can configure their own permissions through the same interface that configures their behaviour) is everywhere.
What security tooling can't see yet
I wrote about the Hugging Face incident last week, where the problem was that guardrails helped the attacker and blocked the defender. AgentForger is a different failure mode but the same gap: existing security tools are built to watch users and endpoints. An AI agent is neither. It operates under a real user's identity, through legitimate platform APIs, on a schedule, and every action it takes looks like normal authenticated work.
Your SIEM sees an Outlook send event from a known employee. Your DLP sees a Drive access from a known session. The agent is invisible because it isn't a new principal in any system your security stack models. It's a ghost wearing a badge it was handed at creation.
The Gartner prediction that over 40% of agentic AI projects will be cancelled by 2027 cites governance and operational discipline as the causes. AgentForger is a concrete example of what ungoverned agent creation looks like when someone hostile finds the seam. The platform assumed the user intentionally created, approved, scheduled, and launched the agent. That assumption is the vulnerability, and it's an assumption every agent platform currently makes.
What to actually do about it
OpenAI's fix was to remove the initial_assistant_prompt parameter from the URL. That stops this specific attack. It does not stop the class.
If your org uses ChatGPT Workspace Agents (or any agent platform with connector access and scheduling), the questions worth asking this week: Can you inventory every agent running under employee identities? Can you see what connectors each one has and what approval settings are configured? Do you have alerting on agent creation events, not just agent actions? Is there anything in your stack that distinguishes "employee did a thing" from "agent running under employee's name did a thing"?
For most teams the answer to all four is no, and that's the real finding here. The vulnerability is patched. The visibility gap is not.
FAQ
What is AgentForger and how was it discovered?
AgentForger is a vulnerability in OpenAI's ChatGPT Workspace Agents disclosed by Zenity Labs in July 2026. It allowed a single phishing link to create an autonomous AI agent inside a victim's organisation without further user interaction. The agent inherited the victim's identity and pre-authorised app connectors. Zenity reported it to OpenAI via Bugcrowd on June 4, 2026, and OpenAI fixed it by June 8 by removing the affected URL parameter.
Has AgentForger been exploited in the wild?
No. OpenAI patched the vulnerability within four days of disclosure, and Zenity states there is no evidence of exploitation in the wild. The disclosure was published in late July 2026 after the fix was confirmed.
How is AgentForger different from a normal phishing attack?
Traditional phishing tricks a user into performing one action, like entering credentials. AgentForger's single click created a persistent autonomous system that continued operating indefinitely without further victim interaction. The forged agent ran on a five-minute schedule, took new instructions via email, and could perform reconnaissance, data theft, credential harvesting, and internal phishing across all connected enterprise apps.
Which organisations were affected by AgentForger?
Any organisation using ChatGPT Workspace Agents where employees had previously authorised at least one connector (Outlook, Gmail, Slack, Teams, Google Drive, or SharePoint) was potentially vulnerable before the June 8 patch. The attack required the victim to be logged into ChatGPT and to click a malicious link.
What should security teams do in response?
Audit your agent inventory: identify every Workspace Agent running under employee identities, check connector permissions and approval settings, and establish alerting on agent creation events. The specific vulnerability is patched, but the broader gap (security tools that cannot distinguish agent actions from user actions) remains unaddressed on most enterprise stacks.
Top comments (0)