ChatGPT AgentForger: How One Link Created A Rogue AI Agent

July 25, 2026

Researchers say a crafted ChatGPT link could silently create a persistent Workspace Agent with access to existing connectors. Here is what was fixed, what remains unclear, and what users should check.

Yes—according to Zenity Labs, one crafted ChatGPT link could make the Workspace Agent builder create, authorize, schedule, and run a rogue AI agent inside a logged-in employee's account. The attack required specific preconditions, and OpenAI fixed the flaw in June. No exploitation in the wild has been reported. The lasting lesson is that agent creation, connector access, approvals, and schedules are separate security boundaries.

Updated July 25, 2026: This article reflects Zenity Labs' technical disclosure, OpenAI's current Workspace Agents documentation, and independent security coverage. The vulnerable behavior is reported as fixed.

Who This Article Is For

This article is for:

The incident is especially important for organizations that connect ChatGPT agents to Outlook, Gmail, Slack, Google Drive, SharePoint, Teams, calendars, or custom tools.

It is also easy to misunderstand. AgentForger was not a story about an AI model spontaneously deciding to become malicious. It was a reported cross-site request forgery-style product flaw in an agent-building workflow. An attacker still needed a victim to click a crafted link while logged in, with Workspace Agents access and at least one previously authorized connector.

What Is Confirmed

Zenity Demonstrated A Crafted-Link Attack

Zenity Labs' Part 1 disclosure says the ChatGPT Workspace Agent builder accepted two URL parameters: one selected a template, while another supplied an initial builder prompt.

The critical behavior, according to the researchers, was that the initial prompt was not merely displayed for review. It was automatically submitted and executed after the logged-in user opened the link.

Zenity's proof of concept instructed the builder to:

  1. create an agent from an existing template
  2. attach connectors the user had already authorized
  3. change supported write approvals from Always ask to Never ask
  4. add multiple schedules so the agent would run every five minutes
  5. watch an inbox for messages from an attacker-controlled address
  6. treat messages beginning with TASK as new commands
  7. send results back to the attacker

That sequence matters more than any one prompt. The link was allegedly able to initiate a chain of authenticated, state-changing actions inside the victim's existing ChatGPT session.

The Attack Needed Several Preconditions

The headline-friendly version is "one link created a rogue agent." The complete version has four important conditions:

Required condition Why it mattered
The victim clicked the crafted link This initiated the builder flow
The victim was logged in to ChatGPT The builder operated in an authenticated session
The account had Workspace Agents access The vulnerable builder had to be available
At least one connector was already authorized The proof of concept reused existing access without a new OAuth prompt

This was not a universal one-click takeover of every ChatGPT account. A consumer account without Workspace Agents or connected enterprise apps did not have the demonstrated attack path.

The preconditions do not make the flaw trivial. They explain why authorization already granted for a legitimate workflow can become dangerous when a different component is allowed to assemble and activate a new agent without an unmistakable confirmation step.

The Agent Could Persist Through Schedules

Zenity Labs' Part 2 disclosure describes the scheduled task as the persistence mechanism.

After the original click, the proof-of-concept agent allegedly continued checking the mailbox for new commands. The attacker no longer needed the victim to click another link or keep the builder tab open.

Zenity demonstrated the agent searching connected email, chat, file, and calendar services; building an organization map; locating sensitive documents and credentials; and sending internal phishing messages through the victim's trusted identity. These were controlled research demonstrations, not evidence that real customers were compromised.

OpenAI's Current Documentation Confirms The Underlying Capabilities

OpenAI's current Workspace Agents documentation says eligible Business and Enterprise users can build reusable agents, connect apps and tools, run agents on schedules, trigger them through an API, and share them with a team or workspace.

The same documentation says:

Those current controls do not prove every detail in Zenity's historical proof of concept. They do confirm why an unintended agent with connectors, reduced approvals, and a schedule would have meaningful authority.

OpenAI Fixed The Reported Flaw

Zenity says it reported AgentForger through OpenAI's Bugcrowd program on June 4, 2026. According to its timeline, Bugcrowd triaged the report and OpenAI accepted it on June 5, then OpenAI fixed the issue on June 8.

SecurityWeek's independent coverage also reports that OpenAI fixed the flaw within days. CSO Online and TechRadar added current attention to the disclosure.

No cited source reports observed exploitation in the wild.

What Is Still Unclear

OpenAI Has Not Published A Dedicated Public Advisory

OpenAI's help documentation describes how Workspace Agents currently work, but OpenAI has not published a dedicated incident or security-advisory page that independently explains the entire AgentForger attack chain.

The exact technical mechanics, affected implementation window, and proof-of-concept results therefore remain attributed to Zenity Labs and the outlets that reviewed its disclosure.

That is not the same as saying the research is false. Zenity provides a detailed timeline, screenshots, video demonstrations, preconditions, and a specific root-cause theory. The uncertainty is about how much of that account has been independently confirmed in first-party technical detail.

The Exact Affected Population Is Not Public

The public sources do not provide:

Workspace Agents were not enabled for every ChatGPT user. That narrows the exposed population, but the available material does not quantify it.

Current Confirmation Prompts Are Not Fully Documented As A Patch Boundary

OpenAI's current instructions describe reviewing a draft plan, choosing tools, refining the agent, previewing it, and selecting Create. They also document default write approvals and connector constraints.

The public help page does not say, "This exact step was added to fix AgentForger," nor does it publish a security test that a URL can no longer automatically submit builder instructions. Zenity reports that the vulnerable parameter behavior was fixed. A public regression test or advisory would make the repaired boundary easier for customers to verify.

No Exploitation Report Does Not Prove No Attempt Occurred

No source reviewed for this article reports exploitation in the wild. That is the responsible statement.

It would be inaccurate to turn it into a stronger claim that no one ever tried the technique or that no affected organization experienced suspicious behavior. Absence of a public exploitation report is not evidence of universal non-exploitation.

How AgentForger Crossed Five Authority Boundaries

AgentForger is useful as a durable security lesson because it crossed five boundaries that organizations often review separately.

Boundary Intended decision Reported failure mode
Creation Did the user intend to build an agent? A crafted URL supplied and auto-submitted builder instructions
Connection Which apps may the agent use? Previously authorized connectors were reused
Approval Which actions require a human check? The builder prompt changed supported actions to Never ask
Persistence When may the agent run? Multiple schedules created a recurring command loop
Visibility Can an admin find and stop it? The resulting activity could resemble work performed by a legitimate user-created agent

Call this the Create, Connect, Approve, Schedule, Audit test.

An organization should be able to answer five questions for every agent:

  1. Create: Who intentionally created this agent, and what proof records that intent?
  2. Connect: Which data sources and actions can it reach?
  3. Approve: Which reads, writes, sends, edits, or deletes require human confirmation?
  4. Schedule: What can wake it up without a person present?
  5. Audit: Where can an administrator see its instructions, owner, changes, runs, and outbound actions?

A secure answer at only one layer is not enough. Strong login security does not help if an authenticated workflow accepts an unintended state-changing command. A safe default approval does not help if the same automated builder can change the approval. A narrow prompt does not help if a schedule creates a persistent command channel.

This is a different boundary from the OpenAI and Hugging Face sandbox incident. A sandbox tries to contain code or tools during execution. AgentForger concerned who was allowed to create an agent, what authority it inherited, and how it could continue running inside a trusted application environment.

What ChatGPT Workspace Administrators Should Check

1. Inventory Every Workspace Agent

Do not limit the review to popular or officially shared agents. Include:

For each one, record the owner, creation date, last update, instructions, connected apps, approval policy, schedules, sharing scope, and recent activity.

An agent without a clear owner or business purpose should not retain broad access merely because it is currently inactive.

2. Review Existing Connectors Separately From Agents

Deleting or disabling one agent may not revoke the user's underlying app authorization.

Review the account-level connection to Gmail, Outlook, Google Drive, SharePoint, Slack, Teams, calendars, and custom MCPs. Remove unused connections and narrow the surviving ones.

This distinction also appears in ordinary AI project workflows: removing one project reference does not necessarily revoke a connected app's broader access.

3. Restore Human Approval For High-Impact Actions

OpenAI documents Always ask as the default for write actions. Preserve or restore that checkpoint for actions that:

Use Never ask only when the exact action, destination, data scope, and failure impact are understood.

4. Add Connector Action Constraints

OpenAI's current documentation says Connector Action Constraints can restrict how supported actions are used. Examples include limiting email recipients to one domain or allowing an agent to read only a specific document.

Constraints should encode a narrow business purpose. "Can use email" is broad. "Can send a weekly report only to an internal reporting address" is meaningfully narrower.

OpenAI cautions that constraints govern what the agent can ask a connector to do; they do not necessarily filter all data returned through an otherwise permitted action. Treat action constraints as one layer, not a complete data-loss-prevention system.

5. Review Schedules And Trigger Sources

List every recurring schedule, API trigger, Slack channel, inbox rule, webhook, and other source that can start an agent without a person actively watching.

Look for:

The core persistence lesson is simple: a safe-looking agent definition can become a background operator when a schedule and an untrusted command source are combined.

6. Treat Builder Links As Security-Sensitive

Employees should not treat every chatgpt.com link as harmless merely because the domain is familiar.

Before using a link that opens an agent builder:

Phishing can abuse a trusted domain or authenticated workflow. The logo in the address bar is not proof that the requested action is intended.

7. Monitor The Agent, Not Only The Human Account

Traditional account alerts focus on logins, devices, impossible travel, and password changes. A malicious agent operating under a legitimate user's existing session may not look like a new account takeover.

Monitor for:

The OWASP AI Agent Security Cheat Sheet recommends least privilege, human approval for high-impact actions, validation of tool inputs and outputs, audit logging, and treating external content as untrusted.

What This Incident Does Not Prove

AgentForger does not prove that:

It also does not prove that a conventional chat product is automatically safe. Chat services still process active prompts, may use providers, and can have separate risks involving accounts, uploads, search, voice, billing, logs, and security controls.

Where OpenVeil Fits—And Where It Does Not

OpenVeil is a paid, privacy-focused AI chat workspace with browser-local chat history and no server-side chat-history record for private chat sessions. It supports web search, uploads, voice, and image tools where enabled.

For someone who needs useful AI chat but does not need a persistent enterprise agent connected to email, drives, calendars, and collaboration tools, choosing a smaller capability surface can be a reasonable form of data minimization.

That is a product-fit point, not a security guarantee.

OpenVeil does not claim to:

Active OpenVeil requests may still be processed by OpenVeil and necessary AI, search, upload-processing, hosting, routing, security, billing, and infrastructure providers. OpenVeil also maintains the account and billing records required to operate the service.

The defensible comparison is narrower: if the job is private AI chat, OpenVeil provides a hosted chat option with browser-local history without asking users to treat every conversation as a persistent workspace agent with broad enterprise connector authority.

Before choosing any product, use the AI privacy-claim checklist and match the tool's authority to the actual task.

FAQ

What Was AgentForger?

AgentForger was Zenity Labs' name for a reported vulnerability in OpenAI's ChatGPT Workspace Agent builder. A crafted link allegedly supplied and auto-submitted instructions that created and activated an attacker-controlled agent inside a logged-in user's workspace.

Was AgentForger A Prompt-Injection Attack?

Zenity characterized the root issue as cross-site request forgery combined with security-sensitive configuration controlled through natural-language instructions. It was not the ordinary scenario of a deployed agent reading a poisoned webpage and confusing content with instructions.

Did The Attack Work Against Every ChatGPT User?

No. The demonstrated chain required a user who was logged in, had Workspace Agents access, clicked the crafted link, and had at least one previously authorized connector.

Could The Rogue Agent Read Email And Files?

In Zenity's controlled demonstration, the agent used previously authorized connectors to search email, chats, drives, and collaboration services. Real access would depend on the victim's existing connectors and permissions.

Could Multi-Factor Authentication Stop It?

Multi-factor authentication remains important for preventing unauthorized logins. The reported attack operated inside an already authenticated session after the victim clicked a crafted link, so MFA alone would not address the demonstrated builder behavior.

Has AgentForger Been Fixed?

Zenity says OpenAI fixed the flaw on June 8, 2026, four days after disclosure. Current coverage reports it as patched. OpenAI has not published a dedicated public advisory describing the complete fix.

Was AgentForger Exploited In The Wild?

No reviewed source reports exploitation in the wild. That is not proof that no attempt ever occurred; it means there is no public evidence of real-world exploitation in the sources used here.

Should Organizations Disable Every AI Agent?

Not necessarily. Organizations should match agent authority to business need, inventory agents, minimize connectors, preserve approvals for high-impact actions, constrain destinations, review schedules, and monitor agent activity. Disabling an agent feature can be appropriate when those controls are not ready.

Is OpenVeil Protected From AgentForger?

AgentForger was a reported flaw in OpenAI's Workspace Agent builder, not OpenVeil. OpenVeil's relevant distinction is its focus on privacy-oriented chat with browser-local history. OpenVeil does not claim to be a phishing defense or a general agent-security control.

The Bottom Line

AgentForger was reportedly patched before its public disclosure, and no exploitation in the wild has been reported. Its lasting value is the authority map it exposes.

An AI agent is not only a model and a prompt. It is also:

Review those boundaries together. A trusted session, familiar domain, and legitimate connector do not prove that the agent being created is one the user intended.

If your actual need is private AI chat rather than persistent cross-app automation, explore OpenVeil and review the OpenVeil privacy policy before choosing a plan.

When privacy, account control, uploads, and search matter, OpenVeil gives you a private AI workspace designed for that job.