Content Summary
| Item | Detail |
|---|---|
| What happened | A flaw in ChatGPT Workspace Agents let a single crafted link secretly build, approve, and launch an AI agent under a victim's identity |
| Who found it | Mike Takahashi and the research team at Zenity Labs |
| Reported | June 4, 2026, through OpenAI's Bugcrowd program |
| Triaged and accepted | June 5, 2026, within a day of the report |
| Fixed | June 8, 2026, four days after disclosure |
| Known exploitation | No evidence found of use against real victims before the fix |
| Framework mapping | OWASP Top 10 for LLM Applications, prompt injection and excessive agency categories |
| Who should read this | CISOs, AppSec teams, and anyone running enterprise ChatGPT integrations |
Picture an ordinary Tuesday. An employee is going through their inbox, half paying attention, and clicks a link that looks exactly like every other ChatGPT link they have opened a hundred times before. Nothing pops up. No warning, no approval box, no second thought needed.
And yet in the background, something just moved into their company. Not a file. Not a script. A living AI agent, wearing that employee's identity, holding their permissions, and taking orders from a total stranger.
That is the short version of what security researchers at Zenity Labs found inside OpenAI's ChatGPT Workspace Agents feature, and they gave it a name that sticks in your head: AgentForger.
What Exactly is the AgentForger Vulnerability
Most people have heard of phishing links that steal a password or trick someone into wiring money. AgentForger did something stranger. It used a phishing link to build an entire AI worker inside the victim's company, one that could read email, dig through Slack and Teams, pull files from SharePoint and Google Drive, and send messages that looked like they came from a trusted coworker.
Researchers describe it as a new twist on an old idea. For years, security teams have defended against Cross Site Request Forgery, where a hidden link tricks a browser into firing off one unwanted action while a user is logged in somewhere. AgentForger pushed that concept much further.
Instead of one unwanted click resulting in one unwanted action, the hidden link resulted in the creation of an entire autonomous system, complete with its own instructions, its own schedule, and access to every app the victim had already connected.
The Trusted Workflow AgentForger Hijacked
To understand why this worked, it helps to know how ChatGPT Workspace Agents are supposed to be built. Under normal, intended use, a person sits down and walks through a guided setup inside the Agent Builder canvas.
- Open the Agent Builder canvas
- Write the prompt and system instructions for the agent
- Attach connectors such as Outlook, Gmail, Slack, Teams, SharePoint, or Google Drive through OAuth
- Choose approval settings for write actions, normally set to always ask first
- Set up a schedule or trigger for when the agent should run
- Test everything before trusting it
- Publish the agent so it goes live
Every one of those steps assumes a human is sitting there making deliberate choices. The moment that assumption breaks, the whole safety model breaks with it.
The Technical Root Cause Behind Cross Site Agent Forgery
Zenity's researchers found the problem sitting inside the Agent Builder's own web address. Two parameters buried in the URL, one naming which agent template to load and another called initial_assistant_prompt, were never meant to be trusted blindly.
Yet when the page loaded, whatever value sat in initial_assistant_prompt was not just quietly typed into a text box waiting for a person to press send. It was submitted and carried out automatically, the instant the page rendered.
That single design gap meant anyone could hand craft a link, wrap it in a convincing subject line, and send it out as bait. Once a logged in victim clicked it, the Builder treated the embedded instructions as if the employee themselves had typed them.
Security researchers often talk about a pattern called the lethal trifecta when something like this goes wrong. Three ingredients have to line up at once.
First, untrusted input, in this case the poisoned URL parameters.
Second, access to private data, which the agent inherited automatically through connectors the victim had already approved earlier.
Third, an unmonitored way to send information back out, which here meant ordinary outgoing email and chat messages nobody was watching closely. AgentForger lined up all three.
Chief of Staff agent template and connected workspace tools(Image source: labs.zenity.io)From Phishing Link to a Silent Company Insider
The path from a single click to a working spy agent unfolded in clear stages.
Weaponizing the link. The attacker packed natural language commands into the URL, disguised behind an ordinary looking ChatGPT address, and delivered it through a believable phishing message.
Silent build. Once the logged in victim clicked, the Builder read those embedded instructions and quietly compiled a new agent, automatically pulling in whichever enterprise connectors the employee had active, no fresh consent screen required since those permissions already existed.
Turning off the guardrails. The embedded instructions flipped the approval setting from always ask to never ask, so the agent could take sensitive actions without stopping to check with anyone.
Setting up remote control. The attacker scheduled the agent to check for new messages every five minutes, watching for anything sent from the attacker's own address with a subject line that started with the word TASK. Whatever showed up next became the agent's new marching orders.
What the Forged Agent Actually Did Once It Was Alive
This is where the story stops being theoretical. Zenity's team tested exactly what an attacker could push through the compromised agent once it was live and quietly running.
They opened by mapping the whole organization, asking the agent to identify people, roles, active projects, and internal conversations across every connected app. Within one automated task, they had a clean org chart most attackers would normally spend weeks building by hand.
From there, the agent went looking for sensitive material sitting in Drive, SharePoint, and email, and it found things like merger paperwork, board presentations flagging financial trouble, and full employee records containing pay details. Because the agent could reason across mail, files, and chat as one connected memory rather than separate silos, it stitched scattered clues into a complete picture far faster than any manual search would.
It also went hunting for passwords and access tokens sitting inside old Slack messages, handing the attacker a direct pivot point into other systems. And because the agent operated under the real employee's identity, it could send internal messages nobody would think twice about, including a fake single sign on prompt sent through Teams and a staged approval request for a large wire transfer, the kind of message that slips past people precisely because it looks like it came from someone they already trust.
-(1)_compressed-20260727072955.webp)
Cross Site Agent Forgery Compared to Older Attack Types
| Feature | Traditional CSRF | Server Side Request Forgery | Cross Site Agent Forgery |
|---|---|---|---|
| Main target | One state changing web request | Internal servers or metadata endpoints | The entire AI agent build and run cycle |
| What triggers it | Browser sends cookies automatically | A server fetches an attacker chosen URL | A URL parameter auto executes as an agent prompt |
| How it bypasses trust | Rides an active login session | Exploits internal network trust | Inherits already authorized enterprise connectors |
| Does it stick around | No, it fires once | Depends on the payload | Yes, it runs on a recurring schedule |
| How far it reaches | One isolated action | Whatever the internal network exposes | Full enterprise data plus an ongoing remote control channel |
Where This Sits in the OWASP Top 10 for LLM Applications
Security teams tracking AI risk often lean on the OWASP Top 10 for LLM Applications to talk about these issues in a shared language. AgentForger touches several categories at once. The untrusted URL parameter feeding straight into the agent's instructions is a textbook case of prompt injection.
The way the agent's approval settings could be silently overridden and then act without any human checking in lines up with what OWASP calls excessive agency. And the quiet handoff of enterprise data through outgoing email touches on improper handling of sensitive output.
Spotting This Kind of Attack Before It Spreads
Security teams do not need to wait for the next AgentForger style bug to start watching for the warning signs. A few detection habits go a long way.
Watch for a sudden burst of new agent creation events, especially ones tied back to an external referrer link rather than someone manually opening the Builder. Keep an eye on configuration change logs for approval settings flipping from always ask to never ask, since that single toggle is the moment a helpful assistant turns into something running unsupervised.
Flag any scheduled task with an unusually short repeat interval, particularly anything close to that five minute mark. And watch outbound email and chat traffic for patterns that look automated rather than human, especially messages carrying a consistent subject prefix like TASK.
Teams that already run detailed web application security testing against injection style flaws will recognize a lot of this logic. The attack surface has simply moved from a login form to an AI agent builder.
How OpenAI Closed the Door
OpenAI moved fast once Zenity's findings came in through Bugcrowd on June 4, 2026. The report was triaged and accepted within a single day, and by June 8, 2026, OpenAI had shipped a fix that stripped out the auto submitting behavior tied to those URL parameters entirely. No evidence surfaced that anyone had exploited the flaw against a real organization before that patch went out.
Still, a patch on one platform does not make the underlying problem disappear. Any organization plugging AI agents into email, chat, and file storage should be thinking in terms of defense in depth rather than trusting a single vendor fix.
- Never let a web based AI builder auto execute instructions carried inside a URL without a human confirming them first
- Require step up authentication before anyone, including an AI agent, can change permission or approval settings on something with enterprise access
- Apply least privilege scopes to every connector an agent touches, rather than handing over broad standing access
- Monitor and filter outgoing communication generated by AI agents the same way a security team would watch traffic leaving any other automated system
Companies building out this kind of layered protection often turn to teams already running AI powered cybersecurity solutions, since the controls that stop this class of attack look a lot like the behavioral monitoring already used to catch account takeovers elsewhere.
Frequently Asked Questions
What is the AgentForger vulnerability in ChatGPT?
It is a flaw in ChatGPT Workspace Agents that let a single crafted link silently build, approve, and run an autonomous AI agent under a victim's own identity, without any confirmation from the victim.
How does Cross Site Agent Forgery differ from traditional CSRF?
Traditional CSRF tricks a browser into firing one unwanted request. Cross Site Agent Forgery goes further and tricks the victim's account into creating an entire ongoing autonomous system that keeps running long after the original click.
Did AgentForger bypass OAuth consent screens?
It did not break OAuth itself. It relied on connectors the victim had already authorized earlier, so no new consent screen ever appeared during the attack.
How can security teams detect malicious AI agent activity?
Watch for unusual spikes in agent creation, approval settings changing from always ask to never ask, unusually short recurring schedules, and outbound messages following an automated looking pattern.
How did OpenAI patch the AgentForger vulnerability?
OpenAI removed the auto submitting behavior tied to the vulnerable URL parameters in the Agent Builder, closing the gap that let instructions execute without a person reviewing them first.
Reference Sources
All facts in this article were verified against the following live sources before publication.
