Beyond Phishing: How AgentForger Weaponized ChatGPT Link Parameters into Stealth Corporate Moles
The days when we worried about phishing links merely stealing session tokens feel almost quaint. A new vulnerability, dubbed "AgentForger" by security firm Zenity Labs, exposed a far more sophisticated reality: a single click on a weaponized ChatGPT link could instantiate an autonomous, attacker-controlled AI agent directly inside an enterprise ChatGPT environment.
This wasn't about breaking in. It was about forging an insider. And for a brief period, OpenAI’s own platform made the process remarkably seamless.
The AgentForger Vulnerability: Exploiting Trust in Automation
At its core, AgentForger wasn't a traditional breach where an attacker cracked a password. Instead, it was an "agent trust failure"—a conceptual flaw where the platform implicitly trusted the automated setup flow of AI agents as if it were an intentional, authorized action by an employee.
Zenity Labs discovered that ChatGPT’s Agent Builder, the tool designed for creating custom assistants to traverse enterprise tools like Outlook, Slack, and Google Drive, was vulnerable. The Agent Builder tool improperly processed specific URL parameters.
By crafting a malicious URL, an attacker could inject instructions directly into the agent creation process:
chatgpt.com/agents/studio/new?template_name=[template]&initial_assistant_prompt=[malicious prompt]
When a user logged into their corporate ChatGPT session clicked this link, the Agent Builder would open, and the initial_assistant_prompt would immediately execute. This wasn't a suggestion; it was an command, processed instantly upon the page load, bypassing the intended manual configuration steps.
Weaponizing the Agent Builder
The true danger lay in how the attack leveraged the Agent Builder’s built-in capabilities to transform this forged agent into a persistent, autonomous actor.
The weaponized prompt didn't just stand up a bot; it configured the bot to be fully functional within the victim's workspace. It automated the selection of a "Chief of Staff" template, connected to the victim's pre-authorized enterprise applications, and—critically—disabled approval prompts.
By setting connector approvals to "Never ask," the attacker ensured that no further interaction was required from the victim. The agent was then published and scheduled to run hourly.
This immediately turned the Agent Builder’s "Preview Mode" from a safe testing environment into a live, malicious operator environment. It was designed to run the newly created agent against real connected systems, which now included the attacker's instructions, not a harmless prototype.
From Click to Persistent Mole
Once installed, the forged agent needed a way to receive instructions without further user intervention that might trigger security detections. The solution was surprisingly simple: it used the compromised employee's own email account to receive tasks.
The agent was scheduled to scan the victim's inbox regularly, looking for emails from the attacker with the subject line "TASK." When it found one, it would treat the body of the email as a command.
The capabilities of this agent were extensive, directly leveraging the access the employee already possessed:
- Internal Reconnaissance: Mapping the organization’s people, projects, and communications by trawling through Outlook, Slack, Teams, and shared files.
- Data Exfiltration: Hunting for sensitive documents, password lists, or API keys buried in past communications or file storage systems, and exfiltrating them via email.
- Lateral Movement: Impersonating the victim on Microsoft Teams, allowing the attacker to conduct convincing spear-phishing campaigns against other employees from within the company’s trusted perimeter.
Because this agent ran as an authorized user, it bypassed traditional browser-based security controls. Attackers no longer needed to maintain a persistent connection to the victim's browser; they simply sent "tasking" emails at their leisure, and the forged insider did the dirty work on their behalf.
A Paradigm Shift in AI Security
Zenity Labs reported the issue via Bugcrowd on June 4, 2026. OpenAI acknowledged the report the following day and deployed a fix by June 8, 2026, by removing the URL parameter that enabled this auto-execution.
While the bug itself was patched quickly, the security implications are profound.
AgentForger illustrates that as AI assistants transition from passive chat interfaces to autonomous agents capable of performing actions across corporate applications, the security perimeter must evolve. We can no longer rely solely on user authentication. Security monitoring must now extend to the behavior of the agents themselves.
Platforms that automatically enable agent creation using complex, multi-step workflows must treat these flows as potentially untrusted input, even if the user is already authenticated. The assumption that an automated setup flow is always a user-driven action is precisely what turned an ordinary link into a persistent, corporate mole.
As companies continue to integrate deeply connected AI assistants, security teams face a new challenge: identifying when a legitimate automation flow has been subverted to forge an insider who never sleeps, never steals a password, yet knows exactly where the keys to the kingdom are stored. This is the new baseline for securing autonomous enterprise AI.
For deeper insight into securing AI agents, see our guide on AI Agent Governance Frameworks. For how to detect rogue agents in your environment, read Monitoring Autonomous AI Behavior.
