SURIQ
The dangerous part of AgentForger was not a memory-corruption bug or a stolen token. It was that OpenAI's ChatGPT Agent Builder read a value out of a web address and ran it as a command. Zenity Labs showed that one crafted link, opened by a logged-in employee, could stand up an autonomous AI agent inside that company's workspace, wire it to every app the employee had already connected, switch off the approval prompts that would normally slow it down, and set it to check an attacker's mailbox every five minutes. OpenAI closed the specific hole in four days. The shape of the failure is what should hold your attention, because it will show up again on the next agent platform.
How one link forged an insider
The proof of concept, published by Zenity Labs and reported by The Hacker News, targeted the Agent Builder in ChatGPT's studio. The Builder took its starting state from parameters in the web address itself: one named a starter template, another carried the opening instruction for the agent. Zenity found that the instruction parameter was not just dropped into the prompt box for a human to review. On page load it was submitted and executed. That makes it a cross-site request forgery: a link the attacker controls drives state-changing actions inside a session the victim, not the attacker, is signed in to.
The instruction the researchers planted told the Builder to assemble a chief-of-staff agent, attach every connector the victim had already authorized (Gmail, Outlook, Slack, Teams, SharePoint, and Google Drive), set each one to Never ask so no approval prompt would ever fire, publish the agent, and stack a set of schedules offset in five-minute steps so that an action ran every five minutes around the clock. Preview Mode ran it on the spot. From then on the agent polled the attacker's inbox for orders and could read stored documents, pull credentials out of chat history, and message the victim's colleagues while wearing the victim's identity.
- 1Victim clicks a crafted ChatGPT Agent Builder link
- 2Builder auto-runs the prompt carried in the URL
- 3Agent attaches every pre-authorized connector, approvals set to Never askDetection point
- 4Agent published and scheduled to run every 5 minutesDetection point
- 5Agent reads attacker inbox, exfiltrates files and credentialsDetection point
Why you never saw a consent screen
A normal phishing-to-OAuth attack has one thing working against it: the consent screen. When a rogue app asks to read your mail, Google or Microsoft shows a dialog, and a careful user can stop right there. AgentForger never reached that dialog, and that is the detail worth sitting with. The connectors were already authorized. The most dangerous step, handing a brand-new agent live access to your mail and files, produced no fresh prompt, because you had granted that access at some earlier, unrelated moment. Pre-authorization is the amplifier here. It turns a single click into full data access with nothing in between for a human to veto.
An agent builder is a provisioning API
Strip away the OpenAI specifics and this is a pattern we keep writing about. A security-sensitive setting, the agent's approval policy, was changeable by the same plain-language instruction that created the agent. We saw the same confused-deputy shape when a Google chatbot edit permission turned out to grant code execution, and when a public GitHub issue talked an AI agent into leaking a private repo. The takeaway from six AI browsers leaking a developer's SSH keys holds here too: one vendor patch does not close the category. Any agent builder that accepts its starting state through a URL inherits this exact risk, and the durable fix is structural. State-changing agent operations need anti-forgery tokens, and a control like disabling approvals should never be something the agent's own prompt can flip.
What to watch when agents can be provisioned this fast
OpenAI patched the URL vector, so there is nothing to install. The action that outlasts this one bug is treating agent creation as a monitored, privileged event across whatever agent platforms your organization runs, the same way you already watch for new inbox rules and freshly consented OAuth apps. Three signatures from this attack are worth an alert:
- An agent published that no one on your team owns or remembers creating.
- A connector flipped to a no-approval state, the
Never asksetting, which is a privilege change and not a convenience toggle. - A cluster of schedules offset by minutes, plus any agent run that reads a mailbox outside your organization, the tell that an agent is taking orders from someone else.
In ChatGPT's Enterprise and Business tiers those events surface through the workspace admin logs and, on the data side, through the Microsoft 365 and Google Workspace audit trails behind each connector. This is a cross-app problem, which is what makes it hard to see: the agent is born in one console and reaches into mail and storage in another, so detection has to correlate across those surfaces rather than watch any single app. A managed detection and response service exists to catch exactly that kind of pattern, mapping the activity to MITRE ATT&CK and putting it in front of an analyst instead of leaving it in a log nobody reads. AgentForger is patched. The provisioning surface it exposed is not going away.