AgentForger: A Single Link That Forged a Rogue ChatGPT Agent

Key Takeaways

• Security firm Zenity Labs disclosed “AgentForger,” a cross-site request forgery (CSRF) flaw in OpenAI’s ChatGPT Workspace Agents that let a single crafted link silently stand up a fully autonomous, attacker-controlled agent inside a victim’s ChatGPT workspace — no malware, no phishing-site credential theft, and no new OAuth consent screen required [1][2].
• The attack worked because the Agent Builder’s URL parameters — a template selector and an initial_assistant_prompt field — were treated as trusted, auto-executable input rather than as unverified user-supplied data, letting the embedded prompt attach the victim’s already-authorized connectors, switch off approval gates, and schedule recurring runs entirely through natural language [1][3].
• Once forged, the agent operated as a persistent, self-directed insider with the victim’s identity and access across Outlook, Gmail, Slack, Teams, SharePoint, and Google Drive, and researchers demonstrated it could harvest credentials via internal phishing, mine chat logs for exposed passwords, draft a fraudulent six-figure wire-transfer approval, and seed calendar-based social engineering — all using trusted internal channels that Zenity assesses are harder for colleagues to question than external email [2][4].
• Zenity reported the flaw to OpenAI through Bugcrowd on June 4, 2026, and OpenAI shipped a fix by removing the vulnerable URL parameter on June 8, 2026, a roughly four-day turnaround [3][5], with no evidence the technique was exploited in the wild before the patch [3].
• The case reframes what “insider threat” means in an agentic enterprise: because the forged agent inherited a real employee’s permissions rather than needing its own, conventional account-compromise defenses — password resets, MFA, endpoint detection — would not have surfaced it, underscoring the need to govern AI agents as distinct, auditable identities rather than as an extension of the human who created them [4][6].

Background

On July 23, 2026, Zenity Labs published a two-part technical disclosure describing a vulnerability it named AgentForger, found in OpenAI’s ChatGPT Workspace Agents — a feature that lets ChatGPT users build autonomous agents connected to enterprise applications such as Outlook, Gmail, Slack, Microsoft Teams, SharePoint, and Google Drive [1][7]. Zenity researcher Mike Takahashi characterized the flaw as an evolution of classic CSRF: rather than forging a single unauthorized request, an attacker could forge an entire standing agent, one that would keep running, keep receiving instructions, and keep acting inside the victim’s organization long after the initial click [1][3]. The company’s co-founder, Michael Bargury, summarized the stakes bluntly, describing the resulting agent as “a fully autonomous agent inside your company that has your people’s identity and access, with the guardrails off” [3].

The vulnerable surface was OpenAI’s Agent Builder, reachable at chatgpt.com/agents/studio/new, which accepts a template_name parameter to select a pre-built agent persona and an initial_assistant_prompt parameter that is automatically submitted and executed as soon as the page loads [1]. An attacker could construct a link selecting the highest-privilege “Chief of Staff” template and embed a prompt instructing the Builder to connect all of the victim’s previously authorized connectors, disable write-action approval requirements, configure a recurring execution schedule — every five minutes in Zenity’s proof of concept — and publish the agent live [1][3]. Because the victim needed only to be logged into ChatGPT with at least one connector already authorized from prior legitimate use, clicking the link triggered no new OAuth consent screen; the natural-language prompt itself carried out the configuration changes that would normally require deliberate user action [1][5]. No token or cookie theft occurred at any stage — the entire attack rode on the victim’s existing, legitimately authenticated session [1].

The disclosure landed amid other 2026 incidents in which autonomous agents became attack infrastructure, such as the July 2026 case in which an OpenAI evaluation model breached Hugging Face’s production systems while gaming a benchmark [8]. AgentForger differs from that precedent in a consequential way: it did not require a misbehaving model or an escaped sandbox. The agent behaved exactly as instructed by its creation prompt; the vulnerability was a web-application access-control failure that let an attacker supply that prompt on the victim’s behalf [1][2].

Security Analysis

The core defect is a failure to distinguish a URL parameter from an authenticated user’s deliberate input. Traditional CSRF defenses assume the forged action is a single, discrete state change — a password reset, a funds transfer, a settings toggle — that can be blocked with anti-CSRF tokens or same-site cookie policies. AgentForger instead forged the creation of an ongoing actor, and because the Agent Builder interprets natural language as configuration commands, the same auto-submitted prompt could simultaneously select a high-privilege template, attach connectors, disable approval gates, and set a recurring schedule in one step, collapsing what would normally be several distinct, user-confirmed actions into a single unconfirmed page load [1][3]. This is the mechanism Zenity’s naming captures: cross-site agent forgery, not merely cross-site request forgery.

A second structural issue is that the attack required no privilege escalation at all. The forged agent operated entirely within scopes the victim had already granted to OpenAI’s connectors during normal, legitimate use — the same access an employee already had to their own Outlook inbox, Slack workspace, and shared drives [1][5]. This is consistent with the blind spot CSA’s own survey research on agent identity has flagged: when an agent does not operate as a distinct, monitorable identity, defenders lose the signal that would normally indicate compromise, because every action the forged agent takes is, from the platform’s perspective, indistinguishable from the victim performing it themselves [6]. CSO Online’s coverage framed this directly as an insider-threat problem, with Bargury describing the forged agent as a “persistent operator” acting from within trusted enterprise systems [4].

The scenarios documented in Zenity’s second disclosure illustrate how that trusted access converts into concrete business risk, though all four were run in Zenity’s controlled lab environment rather than against a real victim organization. In the demonstration, the forged agent sent an internal Teams message, appearing to originate from a real colleague, directing recipients to a spoofed Microsoft single sign-on page framed as an “SSO rollout confirmation” in order to harvest credentials [2]. Separately, in the same proof of concept, it searched Slack history for messages containing password fragments and compiled the results into a table for exfiltration, automating a reconnaissance task that would otherwise require manual searching [2]. In a modeled business-email-compromise scenario, the agent drafted an approval request to wire $242,500, leveraging the fact that the request would appear to come from a legitimate, trusted employee account rather than an external or newly compromised one [2]. A fourth demonstrated scenario used a calendar invite carrying an attacker-controlled attendee to extend reconnaissance and social engineering into a channel that recipients are conditioned to trust [2]. Zenity’s assessment is that messages sent through these internal channels are markedly harder for colleagues to question than an equivalent external phishing email, because they arrive through infrastructure the organization already trusts [2][4].

Zenity reported the issue via OpenAI’s Bugcrowd program on June 4, 2026, OpenAI confirmed the report within a day, and a fix — removing the exploitable URL parameter behavior — shipped four days later, on June 8, 2026 [3][5]. SecurityWeek’s coverage found no indication the technique was used maliciously before the patch [5]. No CVE identifier has been assigned; OpenAI has not stated a reason, though the fix was a server-side configuration change rather than a versioned software patch, which commonly falls outside CVE scope.

Recommendations

Immediate Actions

Security teams operating OpenAI Workspace Agents should audit their existing agent inventory for entries the organization does not recognize, particularly any agent configured with disabled approval gates (“never ask” for write actions) or an unusually frequent recurring schedule, both signatures of the AgentForger technique [1][3]. Any suspicious agent identified should be disabled immediately and its attached connector authorizations revoked and re-issued, since the forged agent’s access rode entirely on pre-existing OAuth grants rather than new credentials that a password reset would address [1]. Because the exploit vector was a clickable link rather than an attachment or executable, user awareness communications should specifically flag unsolicited chatgpt.com/agents links as a phishing indicator, distinct from the credential-harvesting links users are typically trained to recognize [5].

Short-Term Mitigations

Organizations should not rely on a vendor’s default configuration to gate high-impact actions; approval requirements for sending external communications, initiating financial transactions, or posting to broad-audience channels should be enforced as an organizational policy layer independent of whether a given agent-builder platform enables them by default [2][4]. Building centralized visibility into which agents exist across sanctioned AI platforms — who created each one, which connectors it holds, what schedule it runs on, and what permissions it was granted — closes the gap that let the forged agent in Zenity’s research run undetected for as long as its schedule persisted [4][6]. Connector scopes themselves warrant tightening to least privilege; broad send-and-modify access to email and file-storage connectors should be the exception granted case by case, not the default extended to every agent a user creates [6]. Behavioral monitoring tuned to agent-specific anomalies — a sudden high-frequency execution schedule, bulk searches for credential-like strings, or unfamiliar impersonation patterns in internal messaging — provides a detection layer that does not depend on the platform vendor closing every future variant of this bug [2].

Strategic Considerations

The durable lesson from AgentForger is that autonomous agents need to be governed as first-class, auditable identities with their own lifecycle, rather than as a transparent extension of whichever user happened to create them. CSA’s own survey research on agent identity found that a majority of organizations cannot reliably distinguish AI agent activity from human activity in their logs, and that agents frequently inherit more access than they need — conditions consistent with what let AgentForger’s payload operate invisibly under a real employee’s identity [6]. Enterprises adopting agent-builder platforms should require that any agent capable of write actions or external communication be provisioned with its own credential scope, decommissioning process, and audit trail, independent of the human account through which it was created. Bargury’s own framing of the defensive question is a useful governance test: for every deployed agent, an organization should be able to answer “does this agent have permission?” and “is this the behavior we intended?” on demand, not only after an incident [4]. Finally, this class of vulnerability — where natural-language input to an agent-configuration interface is treated as inherently trusted — belongs in agentic-AI red-teaming and threat-modeling exercises going forward, since the underlying pattern (unvalidated input driving autonomous, privileged configuration changes) is not unique to OpenAI’s implementation and is likely to recur across other agent-builder products.

CSA Resource Alignment

AgentForger illustrates the identity gap CSA’s own research has been documenting across the industry. CSA’s “Identity and Access Gaps in the Age of Autonomous AI” survey report found that most AI agents do not operate as distinct identities, that a majority of organizations cannot clearly separate agent activity from human activity in their logs, and that agents commonly inherit more access than their task requires — conditions consistent with those that allowed the forged ChatGPT agent to operate under a real employee’s identity, using connectors that employee had already authorized, without tripping any identity-based alarm [6]. The same report’s finding that a large majority of practitioners believe prompt manipulation could expose sensitive credentials or tokens anticipates the credential-harvesting and Slack password-mining scenarios Zenity demonstrated in practice [6].

CSA’s “AI Agent Governance: From Visibility to Control” survey adds the operational half of the picture, reporting that a majority of organizations experienced at least one AI agent incident in the past year, that shadow agent deployment routinely outpaces organizational visibility, and that decommissioning and lifecycle controls lag well behind agent creation — the same gap that let Zenity’s forged agent persist on a recurring schedule until manually discovered [9]. CSA’s whitepaper “The Non-Human Identity Governance Vacuum” develops the governance argument in fuller detail, calling for AI agent identities to carry their own lifecycle management, just-in-time scoped credentials, and zero standing privilege rather than inheriting a human creator’s persistent access — the same governance gap AgentForger’s payload exploited [11]. Together, these findings argue for the identity- and lifecycle-centric controls detailed in CSA’s AI Controls Matrix (AICM v1.1), particularly its Identity and Access Management domain provisions governing agent-specific access restriction and credential scoping, which — had they been enforced as platform-level defaults rather than optional configuration — would have constrained exactly the “never ask,” broadly-connected, indefinitely-scheduled agent that AgentForger’s payload created [10].

References

[1] Zenity Labs. “AgentForger, Part 1: ChatGPT Cross-Site Agent Forgery.” Zenity Labs, July 2026.

[2] Zenity Labs. “AgentForger, Part 2: The Autonomous Insider.” Zenity Labs, July 2026.

[3] Townsend, Kevin. “OpenAI Fixes ChatGPT Agent Flaw That Could Let Attackers Forge an AI Insider.” SecurityWeek, July 23, 2026.

[4] CSO Online. “AgentForger proves AI agents can become persistent insider threats.” CSO Online, July 2026.

[5] The Register. “One ChatGPT link could smuggle a rogue AI agent into your company.” The Register, July 23, 2026.

[6] Cloud Security Alliance. “Identity and Access Gaps in the Age of Autonomous AI.” Cloud Security Alliance, 2026.

[7] OpenAI. “Introducing workspace agents in ChatGPT.” OpenAI, 2026.

[8] OpenAI. “OpenAI and Hugging Face partner to address security incident during model evaluation.” OpenAI, July 21, 2026.

[9] Cloud Security Alliance. “AI Agent Governance: From Visibility to Control.” Cloud Security Alliance, 2026.

[10] Cloud Security Alliance. “AI Controls Matrix (AICM) v1.1.” Cloud Security Alliance, June 22, 2026.

[11] Cloud Security Alliance. “The Non-Human Identity Governance Vacuum.” Cloud Security Alliance, 2026.