A single phishing link, one click from a logged-in employee, and no confirmation prompts at all — that was enough to stand up a fully authorized, persistent AI agent inside a victim organization's ChatGPT Workspace environment. That's the vulnerability cybersecurity research firm Zenity Labs disclosed under the codename "AgentForger," and it's one of the clearest illustrations yet of why agentic AI platforms need their own security model, not a set of assumptions borrowed from traditional web application security.
Zenity Labs described AgentForger as a "cross-site agent forgery" — a deliberate nod to cross-site request forgery, the classic web attack where a malicious site tricks a logged-in user's browser into performing an unwanted action on a trusted site. AgentForger applies the same underlying logic to a much newer and more consequential target: AI agent creation. Instead of forging a password change or a fund transfer, the forged action was the creation and authorization of an autonomous AI agent with standing access to a victim's connected enterprise applications.
How the AgentForger vulnerability actually worked
The mechanics are worth walking through carefully, because the danger isn't in any single exotic technique — it's in how ordinary each step looks in isolation. A victim needed to already be logged into ChatGPT and to have at least one connector pre-authorized — something as common as a connected email account, a calendar, or a cloud storage integration, the kind of setup plenty of ChatGPT Workspace users have in place for everyday productivity. When that victim clicked a malicious link, ChatGPT's agent-creation feature, "Builder," would autonomously construct a new agent behind the scenes. No dialog asking the user to confirm they wanted a new agent. No review step showing what permissions it would carry.
The forged agent didn't need to request access to anything, because it inherited it automatically. Builder attached all of the victim's previously connected integrations to the new agent directly — meaning the rogue agent instantly had the same reach into email, calendar, cloud storage, and collaboration tools that the legitimate user had already granted to their own ChatGPT account over time. And in the same silent motion, the exploit flipped a critical safety control: write-action approvals, which should have been set to "Always ask" before any sensitive or irreversible action, were switched to "Never ask." That single setting is the core safeguard designed to stop an agent from silently sending emails, moving files, or modifying calendar entries without a human in the loop. AgentForger disabled it as part of the same click that created the agent in the first place.
Why zero confirmation prompts is the part that matters most
It's tempting to read AgentForger as "just" a permissions bug, but the zero-confirmation detail is what turns it from a nuisance into a genuine incident-response scenario. Every legitimate safeguard ChatGPT Workspace Agents ship with — the "Always ask" default, the visible step of building and naming a new agent, the expectation that a user consciously chooses to authorize an integration — assumes a human is in the loop somewhere in the process. AgentForger removed the human from every single one of those checkpoints simultaneously. The victim didn't approve a new agent. They didn't approve giving it access to their connectors. They didn't approve disabling the write-action confirmation gate. All of that happened as a side effect of a single click on a link that, to the victim, may have looked like nothing more than a normal web page.
Once established, the forged agent could operate with real reach into the organization: exfiltrating sensitive data from connected email and cloud storage, harvesting credentials and multi-factor authentication tokens as they passed through connected services, impersonating the employee in communications sent through their own authorized accounts, and continuing to operate quietly long after the initial phishing click was a distant memory to the victim. No malware, no separate exploit chain, no traditional endpoint compromise. The entire attack lived inside a legitimate product's legitimate agent-creation workflow, using legitimate, previously-granted permissions — which is exactly why it's a hard case for conventional endpoint and network security tooling to catch. There's no malicious binary to flag. There's an AI agent doing AI-agent things, just doing them for someone other than the person who's supposed to control them.
The fix, the timeline, and the disclosure
OpenAI fixed the underlying issue as of June 8, 2026, following responsible disclosure from Zenity Labs — meaning the researchers reported the flaw privately and gave OpenAI time to patch it before any public details went out, the standard and appropriate process for handling a vulnerability like this. Public reporting followed roughly six weeks later, around July 23-24, 2026, with coverage from The Hacker News, SecurityWeek, The Register, and other security-focused outlets bringing the technical details to a wider audience.
That gap between "fixed" and "publicly known" is normal and, frankly, healthy — it's how responsible disclosure is supposed to work, giving the vendor room to patch before attackers have a public writeup to work from. But it also means organizations running ChatGPT Workspace Agents were exposed to this class of attack for some period before the fix landed, and it's a live question worth asking your own security team: were we running the vulnerable configuration during that window, and do we have logs that would tell us either way?
AgentForger as a preview of agentic AI's real attack surface
The reason AgentForger deserves attention well beyond OpenAI's user base is that it's not really a story about one bug in one feature. It's a case study in what happens when you combine two things that are individually reasonable and, together, create a new and under-appreciated attack surface: pre-authorized connectors that persist across sessions, and agent-builder workflows that can act on a user's behalf without requiring fresh consent for each new agent. That combination — standing access plus low-friction agent creation — is not unique to ChatGPT. It's the same basic architecture underpinning agent-platform categories broadly, including enterprise copilot and agent-builder tools from other major vendors. Any platform that lets a user pre-authorize integrations once and then spin up new automated agents that can inherit that access carries some version of this risk, whether or not that specific product has had its own AgentForger moment yet.
For security teams, that's the real takeaway: this isn't a "patch and move on" vulnerability, it's a signal to re-examine the permission model of every agentic AI platform your organization has deployed, not just the one that happened to make headlines this week.
It also reframes what "least privilege" needs to mean once agents enter the picture. Traditional least-privilege thinking asks what a given human user should be able to access. Agentic platforms introduce a second, harder question: what should an agent created on that user's behalf be allowed to inherit automatically, without a fresh, explicit grant for that specific agent's specific purpose? AgentForger exploited the gap between those two questions — the human's access was appropriately scoped, but the agent-creation workflow treated "the user is logged in" as sufficient justification to hand a brand-new, purpose-unknown agent the same standing reach. Any security team evaluating an agent-builder product should be asking the vendor directly whether agent creation requires per-agent, per-connector consent, or whether it silently inherits from whatever the user has previously authorized.
What security teams should actually do about this
Start by auditing which employees currently have pre-authorized connectors active in ChatGPT Workspace or any comparable agent platform your organization uses. Most security teams have decent visibility into who has logins to core enterprise systems and considerably less visibility into which individual employees have quietly connected email, calendar, or cloud storage integrations inside an AI assistant over the past year. That inventory gap is exactly the blind spot AgentForger exploited, and closing it is a prerequisite for everything else on this list.
Review your agent-builder permission defaults directly rather than assuming the vendor's out-of-the-box configuration is the safest available option. "Always ask" should be treated as a setting that a user's own click, or a phishing link masquerading as one, should never be able to silently downgrade to "Never ask" — and if your platform doesn't give you visibility into when that setting changes for a given user, push your vendor for that logging capability specifically.
Treat agent-creation events as a first-class security signal, not background noise. Every time a new agent is built inside your organization's AI platform — who created it, what connectors it inherited, whether write-action approvals were left at their safe default — is exactly the kind of event that belongs in the same monitoring pipeline as new OAuth grants or new admin account creation. If your SIEM or logging pipeline currently has no visibility into agent-creation activity at all, that's a gap worth closing before your next AI platform expansion, not after an incident forces the issue.
Most importantly, treat any single-click AI-agent-authorization flow with the same institutional wariness your security team already applies to an OAuth consent screen. Years of phishing awareness training have taught employees to pause before granting a third-party app access to their Google or Microsoft account through an OAuth prompt. Agent-creation links deserve the identical instinct and the identical scrutiny, because functionally, that's exactly what they are — a consent flow that grants standing access to enterprise systems, just wrapped in a newer, less familiar interface that hasn't yet built up the same reflexive user suspicion.
The bigger lesson for anyone deploying agentic AI
AgentForger got fixed relatively quickly once Zenity Labs reported it, and that's a genuinely good outcome — responsible disclosure did what it's supposed to do. But the underlying architecture that made it possible in the first place — standing connector access plus low-friction agent creation — isn't unique to one product, and it isn't going away, because it's also exactly what makes agentic AI useful. The convenience of not re-authorizing every integration every time you spin up a new agent is the same convenience that let AgentForger turn one phishing click into a persistent, fully-authorized insider threat with zero malware required.
That tension — convenience versus standing access risk — is the defining security question of the agentic AI era, and it isn't going to resolve itself through vendor patches alone. Organizations deploying any agent-builder platform need to build their own layer of scrutiny around connector inventories, permission defaults, and agent-creation logging, because the next flaw in this category won't announce itself with a catchy codename in advance. It'll look, right up until the incident report, like an ordinary product feature working exactly as designed.