This one is already fixed — read it for the pattern, not an action. Zenity Labs disclosed AgentForger, a flaw in ChatGPT Workspace Agents. OpenAI patched it server-side within four days of the report, there is no CVE, and there is nothing for you to deploy. What is worth your time is the attack it proves is now practical.
Phishing's payoff is changing. For twenty years the goal of a phishing click was to steal a thing — a password, a token, a session — and you raced the victim to reset it. AgentForger shows a different payoff is now practical: capability, not a credential. One tampered link, clicked by one logged-in employee, and a new AI agent spins up inside the company that answers to the attacker, not the employee.
It inherits trust the user already gave. The forged agent picks up every application the employee had already connected to ChatGPT — Outlook, Slack, Teams, Google Drive, SharePoint — so no new consent screen appears. The dangerous authorisation was granted earlier, legitimately, during normal use. The attack just repurposes it.
Then the agent runs the whole chain itself. In the research it mapped the org, found an M&A term sheet and a board deck flagging layoffs, pulled compensation data, dug database passwords out of a Slack channel, sent Teams messages under the victim's name pointing at a fake SSO login page, and staged a $242,500 wire approval — on a five-minute schedule, checking the attacker's inbox for the next task. The victim sees nothing.
The root cause is mundane; the consequence is not. A URL parameter in the agent builder was executed without a confirmation — textbook cross-site request forgery, aimed at an agent builder instead of a bank transfer. Zenity calls it an agent trust failure: the platform assumed that if an agent exists, a human meant to create it. Any enterprise AI platform that lets a user stand up an agent, wire it to real tools and schedule it could reproduce the same class of attack — how many do is an open question this one bug does not answer.
Disposition. Disclosed by Zenity Labs and fixed by OpenAI server-side on 8 June 2026, four days after the 4 June report. No CVE, no customer patch, no exploitation reported in the wild. There is nothing to deploy. This unit exists to explain the attack class, because the class outlives this one bug.
Why now. Zenity Labs published AgentForger on 23 July 2026, and coverage followed the next day. It is a cross-site request forgery, but instead of forging a single request it forges an entire autonomous agent. An attacker sends a link to ChatGPT's agent builder with the instructions embedded in a URL parameter; the builder auto-submitted and executed that parameter without asking the user to confirm. A logged-in employee with Workspace Agents and at least one previously authorised connector only had to click. It matters now not because anyone is exploiting it — it is fixed — but because it is a clear, concrete demonstration that an AI agent can be turned into a persistent, attacker-controlled insider from a single click, building on the same team's 2025 work against other agent platforms.
Also inside: The mechanics are worth understanding because they generalise. The forged agent does not need the victim again after the first click: it writes itself a schedule that fires every five minutes, checks a mailbox for messages from the attacker whose subject starts with a keyword, executes the instruction across the connected apps, and emails the result back. That is command-and-control over a legitimate SaaS channel, running under the victim's identity, invisible to the victim. Zenity's point about aggregation is the sharp one: no single connector is the danger; the danger is that the agent can reason across all of them — mail, chat, storage — as one searchable workspace, the way a capable insider would. It is not running an exploit against each app. It is using them exactly as intended, on behalf of the wrong person.
Then. There is no patch to apply — the action is architectural, and it applies to every agent platform you run, not just ChatGPT. Ask three questions of each one. Who is allowed to create an agent, and can that creation be triggered without an explicit, un-spoofable confirmation? What can an agent reach once created — does it inherit all of a user's connectors by default, or is its access scoped and separately approved? And how would you know an agent was taking orders from the wrong place — do you log agent creation, scheduling, and cross-connector activity the way you log logins? If you cannot answer the third question, an AgentForger-class event in your estate would be invisible, exactly as it was to the victim in the research.
We are filing this as analysis, tier track, not as an action item, because it is fixed and was never exploited in the wild — calling it ACT would be manufacturing urgency the facts do not support. But do not read 'fixed' as 'over'. The specific bug is closed; the class — a user-provisioned agent, wired to real tools, created or configured through an interface that can be driven remotely without genuine consent — is a property of how agentic AI is being shipped across the industry, not a mistake unique to one vendor. Expect more of these. The defensive work is to treat agent creation and agent permissions as security-relevant events today, before the class produces one that is not fixed in four days.
The honest objection is that this is a fixed bug, never exploited, found and named by a vendor that sells the defence — and it is worth answering, not dodging.
Basis. All three are true: OpenAI closed it in four days, no exploitation has surfaced, and Zenity Labs sells agentic-AI security. Those facts should discount the marketing, not the mechanism. The parts that matter do not depend on Zenity's framing and are independently checkable: the agent builder executed a URL parameter without confirmation — textbook CSRF — and a created agent inherited the user's existing connector consent. Both are verifiable design facts, and both are what make the class real. The specific bug is minor; the demonstration of what a forged agent can then do is the point, and it holds whoever ran the demo.
What would lower this. If the inherited-consent and remote-provisioning behaviours turn out to be specific to how ChatGPT was built rather than common across agent platforms, the 'class' shrinks to one vendor's fixed mistake and this piece is over-generalising from a marketing artefact. Independent reproduction on a second platform would settle it either way.
The durable lesson is that agent creation and agent permissions are now security-relevant events, and most organisations do not log them.
Basis. The attack was invisible to the victim precisely because provisioning an agent, granting it connectors, and scheduling it are treated as ordinary product features, not as privileged actions worth monitoring. That is true across the enterprise AI platforms shipping today, not only ChatGPT; Zenity's prior AgentFlayer work showed similar issues against Copilot Studio and Salesforce Einstein. Where those events are unlogged, an AgentForger-class compromise leaves the same near-zero trace it left in the research.
What would lower this. If the major platforms add un-spoofable confirmation on agent creation and default to scoped, separately-approved connector access — and expose agent lifecycle events to the SIEM — the monitoring gap closes and this becomes a solved onboarding problem rather than a standing blind spot.
This is a class, not a one-off, so 'OpenAI fixed it' is the wrong place to stop reading.
Basis. The root cause is structural: agentic platforms deliberately let a user stand up an autonomous agent, connect it to real tools, and schedule it. Any interface that can drive that provisioning remotely without genuine consent reproduces the attack. The specific CSRF is closed; the design pattern that made it possible is spreading, not retreating.
What would lower this. This rests on one vendor's fixed bug plus a research lineage, not on observed in-the-wild abuse of the class. If agent platforms converge on strong provisioning controls before attackers operationalise the technique, the class stays theoretical and this reads as over-warning.
Read this for the shift your instinct already named: the phishing click no longer ends the attack, it starts it. Every stage below is run by the agent itself, on a schedule, under the victim's identity — no further attacker clicks, no malware on an endpoint, no exploit against the connected apps. It is the whole kill chain, orchestrated by something the victim installed by accident.
OpenAI closed the specific bug; these are the controls that break the class, wherever you run agentic AI. Each maps to a stage in the chain above — you do not need all of them, but the first three turn an invisible, persistent compromise into a noisy, contained one.
An agent must never be created or configured from a link, a URL parameter, or a single GET request. Require an interactive, anti-CSRF confirmation — a real 'create this agent, with these tools?' step bound to a server-side token — that a crafted link cannot drive. This is exactly the fix OpenAI shipped; demand it of every agent platform you adopt, and treat 'agents can be provisioned by URL' as a disqualifier.
An agent should not silently inherit the connectors its creator authorised for themselves. Grant tools to the agent explicitly, least-privilege, and force a fresh approval for anything sensitive — mail-send, finance, HR, source control, admin. If a forged agent starts with nothing, the rest of the chain has nothing to stand on.
Creation, permission grants, schedule changes and cross-connector activity should flow to your SIEM the way logins do. Most organisations do not capture these at all, which is why the attack was invisible to the victim. You cannot alert on what you never recorded — start by recording it.
These behaviours also occur in legitimate agents — scheduling, reading across apps and acting on email are the point of them — so no single one is an alarm on its own. The signal is the combination, and above all an agent whose instructions arrive from outside the organisation. A self-scheduling agent that reads broadly across mail, chat and storage and acts on inbound external email is the forged-operator shape; tune on that external-controller tell to keep the false-positive rate survivable.
Sending external email, messaging many internal users, approving a payment or wire, and bulk-exporting data should require human approval when an agent initiates them — and the 'set every connector to never ask' move should simply be unavailable to an agent. This is the control that stops recon from becoming business email compromise.
Keep a named-owner inventory of every agent, review it, and auto-expire the dormant and the unowned. A persistent insider you do not know exists is the whole problem; an agent that quietly dies after a period of inactivity cannot be a durable foothold.
| Source | Admiralty | Used for |
|---|---|---|
| https://labs.zenity.io/p/agentforger-part-1-chatgpt-cross-site-agent-forgery | A2 | PRIMARY: researcher writeup, part 1, read in full. The cross-site-agent-forgery mechanism; the URL parameter auto-executed without confirmation; inherited pre-authorised connectors; the self-scheduling persistence; preconditions; disclosure timeline (reported 4 Jun, fixed 8 Jun 2026); no CVE |
| https://labs.zenity.io/p/agentforger-part-2-the-autonomous-insider | A2 | Researcher writeup, part 2, read in full. The full post-forgery chain — recon (M&A term sheet, board deck, compensation export), passwords found in Slack, Teams/Slack phishing under the victim's name to a fake SSO page, the $242,500 BEC wire lure; the aggregation-across-connectors argument; 'agent trust failure' |
| https://www.securityweek.com/openai-fixes-chatgpt-agent-flaw-that-could-let-at | B2 | Independent corroboration of the flaw, the single-link forging of an enterprise agent, and OpenAI's fix |
| https://www.csoonline.com/article/4200978/agentforger-proves-ai-agents-can-bec | B2 | Independent framing of AI agents as persistent insider threats; the class argument beyond the single vendor |
| https://www.theregister.com/security/2026/07/23/one-chatgpt-link-could-smuggle | B2 | Independent reporting corroborating the one-click smuggling of a rogue agent and the persistence mechanism |