OpenAI fixed the ChatGPT “AgentForger” flaw four days after Zenity’s June report

A single “ordinary” ChatGPT link could quietly plant a fully autonomous, attacker-controlled AI agent inside a victim company’s ChatGPT workspace, according to Zenity Labs researchers. Their write-up centers on a flaw in OpenAI’s workspace agents feature: one click could let an attacker build, publish, and schedule a malicious agent that operates through whatever apps and actions the organization already allows.

Zenity says it reported the issue to OpenAI through Bugcrowd on June 4. OpenAI acknowledged the report the following day, June 5, and fixed the vulnerability four days later by removing the URL parameter that enabled the attack before it was publicly disclosed. The timeline matters because it shows this was not a vague theoretical risk. The attack depended on concrete workspace conditions and permissions, and Zenity’s proof-of-concept demonstrated a “corporate mole” behavior that goes well beyond initial phishing.

Here is the part that should make any CISO or board member sit up: this technique was not positioned as a password-stealing or browser-session hijacking play. Instead, it effectively tricked ChatGPT’s agent builder into doing the work of an attacker. If the victim belonged to a workspace where agents were enabled and had permission to create them, Zenity says the builder would accept instructions embedded inside a link. After the click, it could wire up the attacker’s agent to the victim’s existing connected services and connectors, turn off approval prompts, publish the agent, and set it loose on a schedule.

The researchers’ description is blunt about impact. If the workspace had already connected services such as Outlook, Teams, Slack, SharePoint, or Google Drive, and the organization’s admins allowed the relevant actions, Zenity says the rogue agent could use those permissions. That changes the risk shape from “stolen credentials” to “misuse of legitimate access.” From there, the agent could rummage through corporate data, send messages as the employee, and continue running after the original phishing email had done its job.

Zenity also says the weak spot was specifically ChatGPT’s agent builder, the feature used to spin up AI assistants that can operate across business systems like email, chat, and calendars. Their claim is that the builder accepted malicious instructions hidden in what looked like a normal ChatGPT link. In other words, the social engineering lure could be ordinary looking, while the payload was the agent setup itself. For security teams, that is a nasty combo: you can recognize phishing attempts, but this kind of attack tries to smuggle the harmful action into a workflow the user might think is benign.

The proof-of-concept scenarios Zenity lays out read like a blueprint for business email compromise, updated for agentic systems. Zenity says it demonstrated the ability to automatically map an organization’s people and projects by trawling Outlook, Slack, Teams, calendars, and file stores. It also describes hunting for passwords and API keys buried in chat messages, and sending convincing phishing messages through the victim’s own Teams account. After deployment, Zenity says the agent would not rely on classic command-and-control infrastructure. Instead, it would monitor the victim’s inbox for attacker emails with “TASK” in the subject line, turning each message into a new assignment such as searching files, collecting sensitive documents, or emailing results back.

This is where second-order implications start to matter for executives, not just security teams. As AI agents move from answering questions to taking actions across corporate systems, the attack surface starts to resemble your workforce: identity, roles, connected apps, approvals, and ongoing workflows. Zenity’s co-founder and CTO, Michael Bargury, told The Register: “This isn’t a forged request, it's a forged insider,” adding that with one click an attacker gets an autonomous agent inside the company with employees’ identity and access and guardrails off. Zenity frames it as “an agent trust failure,” noting that existing security controls were not built to see it. Even if you never run into this exact bug, the underlying failure mode is the one that will keep showing up: trust in automation plus over-permissioned integrations.

There is also a process and regulatory angle worth noting. Zenity reported the issue through Bugcrowd on June 4, OpenAI acknowledged it the next day, and then removed the enabling URL parameter four days later before public disclosure. That kind of rapid remediation is good hygiene, but it also highlights the reality regulators and auditors tend to care about: how quickly systems can be fixed once a credible threat is identified, and how well vendors coordinate disclosure. For companies, the operational takeaway is not just “patch the vendor,” it is “assume an agent can act with your permissions if it can be tricked into being created.”

The strategic stakes for peers are simple: if employees can be socially engineered into granting an attacker a foothold, and if that foothold can translate into an agent that keeps running, then the incident response timeline expands. The attacker does not need to stay on the phone or keep clicking. The agent can persist, poll inboxes for tasks, and execute through connected tools. Zenity’s “AgentForger” may be fixed now, but the broader shift it exposes is not. For decision-makers, the question becomes whether your control environment is ready for insider-like automation risks inside modern AI workspaces.