Zenity Labs' AgentForger disclosure showed a crafted ChatGPT link could create and deploy an autonomous Workspace Agent on a victim's behalf, inheriting enterprise connectors the employee had already authorised. OpenAI fixed it in four days and there is no evidence of exploitation. The structural gap it exposed — no widely deployed primitive for credentials delegated to a process rather than a person — remains open across every agent platform.
Start with the part that should lower your blood pressure rather than raise it. Zenity Labs reported this vulnerability to OpenAI through Bugcrowd on 4 June 2026. It was triaged and accepted on 5 June and fixed on 8 June — four days from report to patch. Zenity confirmed no evidence of exploitation in the wild prior to the fix. Public disclosure followed in late July, which is the normal order of operations. If you use ChatGPT Workspace Agents, this is not something you need to act on today.
Which is exactly why the patch is the least interesting fact about it. What Zenity found is a vulnerability class new enough that it does not yet have a settled name — the researchers call it cross-site agent forgery — and underneath the specific bug sits a structural problem that no patch addresses, because it is not a bug. It is how agent platforms are built.
OpenAI's Workspace Agents can connect to Outlook, Gmail, Slack, Google Drive, SharePoint and Teams, take actions across those services, and run on a schedule rather than only when a human is present. That last property is what turns an assistant into an autonomous actor, and it is what makes this interesting.
Zenity found that the official agent build process could be hijacked from within an initialisation URL. A crafted ChatGPT link, delivered by ordinary phishing, could create, authorise and deploy an agent on the victim's behalf. The prerequisites were minimal: the target had to be logged into ChatGPT, have Workspace Agents access, and have at least one authorised enterprise connector. No credential theft, no session hijacking, no malware.
The result was an agent the victim did not knowingly create, running in their organisation, acting with their access. Zenity's write-up describes it as an autonomous insider, which is the right frame — not a stolen session that ends when the tab closes, but a persistent process that continues working after the initial interaction is over. Reporting on the disclosure has described the forged agent polling for instructions on a recurring schedule; the specific interval varies between accounts, so treat the mechanism as the durable fact and the timing as a detail.
The mechanism is unusually clean, and it is the teachable part. Two URL parameters did the work.
That second line is the entire bug. Content arriving from an untrusted source — a URL parameter, which is to say a string a stranger can set — was interpreted as an instruction to be carried out rather than as data to be shown to the user for confirmation.
If that sounds familiar, it should. It is the same category error that produced SQL injection, where user input was concatenated into a query and executed as code. It is the same category error behind cross-site scripting, where user content was rendered as markup and executed as script. It is the same category error behind prompt injection generally. Every computing era discovers a new place to confuse data with instructions, and every era is surprised by it.
The lineage to CSRF is the tightest, and worth drawing out because it shows what has changed. Classic cross-site request forgery tricks a logged-in browser into performing one action — transfer the money, change the email address. The damage is bounded by that single request. Cross-site agent forgery tricks a logged-in session into creating a persistent autonomous actor, which then keeps acting. The blast radius is not one request; it is however long the agent runs before someone notices it exists.
The generalisation worth keeping: in classic web security, the unit of compromise was a request or a session. On agent platforms, the unit of compromise is a process with a schedule. Detection and revocation tooling built for the first assumption does not naturally cover the second.
Here is the half that generalises past OpenAI, and the reason this disclosure is worth reading long after the patch shipped.
The forged agent inherited the connectors the employee had already authorised. Email, calendar, cloud storage, Slack, Teams, SharePoint. There was no new consent screen. No fresh OAuth grant. No moment where the user was shown a list of permissions and asked whether this new thing should have them. According to Zenity and subsequent reporting, an agent created this way could exfiltrate data, harvest credentials and MFA tokens, impersonate the employee in their own communication channels, and persist past the initial phishing interaction.
That is not an oversight in OpenAI's design so much as an inherited assumption from the model everyone is building on. OAuth was designed to answer a specific question: does this human consent to this application accessing this resource on their behalf? The grant is scoped to an application and a user. It assumes the human who approved the connector is, more or less, the human using it.
Agent platforms break that assumption structurally. The thing using the credential is not the person who approved it. It is a process the person spawned — or, in this case, a process someone else spawned in their name. And the industry has no widely deployed primitive for expressing 'this credential is delegated to a process, not a person, with these limits, for this long, revocable independently of the human's own access.'
Pieces of the answer exist. OAuth token exchange and RFC 8693 provide machinery for delegation. Workload identity systems like SPIFFE were built for exactly the problem of authenticating non-human actors. Scoped, short-lived, per-process credentials are well-understood in infrastructure security. What does not exist is any of this being the default in the consumer-and-enterprise SaaS connector ecosystem that agent platforms actually plug into. The connectors are OAuth apps, and OAuth apps do not distinguish between a human clicking a button and an agent running on a timer.
OpenAI's fix closed the specific path — the parameters can no longer be used to instantiate an agent without user confirmation. That is the correct fix, it landed fast, and OpenAI's four-day turnaround is genuinely good by the standards of the industry. It is also narrow by necessity: it addresses how an unauthorised agent got created, not what an agent inherits once it exists.
The honest statement of the residual risk is that any path to creating an agent in a user's context — whether a future vulnerability, a compromised session, a malicious internal actor, or a user who simply gets socially engineered into building the agent themselves — produces something with the same inherited access. The forgery was the interesting attack because it needed only a click. It is not the only route to the same endpoint.
For organisations deploying agents, that suggests a small number of unglamorous questions worth asking before the next rollout:
None of those are exotic. All of them are answerable today with existing tooling, and most organisations rolling out agents have not answered them, because the rollout was framed as a productivity decision rather than an identity one.
It is worth ending on the thing that went right. A security research firm found a serious flaw, reported it through a coordinated channel, the vendor accepted it within a day and shipped in four, and disclosure came after the fix with no evidence of exploitation. That is the process working. The reason to keep reading about it is not that anyone was harmed — nobody was — but that the flaw was a clean demonstration of a gap that is still open everywhere else.
No. Zenity Labs reported AgentForger to OpenAI on 4 June 2026, OpenAI accepted it on 5 June and shipped a fix on 8 June — four days. Zenity confirmed no evidence of exploitation in the wild before the patch. Public disclosure came in late July, after the fix was already deployed. The reason the story still matters is the underlying permission model, not the specific flaw.
DrafterDaily covers AI and enterprise security with the technical detail intact — what actually happened, what it generalises to, and what is still unfixed.
More technology analysisCVE-2026-0768 is an unauthenticated root RCE in Langflow. It was disclosed in January, the fix has shipped through seven releases, and attackers are hitting it in September — because low-code AI middleware became critical infrastructure without acquiring a patch owner.
Opposition to data centres is not a referendum on AI. It is a cost-allocation dispute — and PJM's capacity auction is the mechanism that turned an abstract argument into a number on 67 million households' bills.
OpenAI's first published benchmarks for its custom inference chip are real, from a public benchmark, and normalised on nameplate TDP rather than measured power. OpenAI disclosed that itself, in a sentence nobody is quoting.