OpenAI Workspace Agents Vulnerability: One ChatGPT Link Could Create a Rogue AI Agent

OpenAI fixed a Workspace Agents vulnerability after researchers found that one ChatGPT link could create an attacker-controlled agent in a victim’s account. The agent could inherit existing app access, disable approval prompts, and seek new instructions every five minutes. The conflict was unusually direct: a feature built to delegate trusted work could be converted into a persistent internal operator.

Zenity Labs named the attack AgentForger and disclosed its research on July 23, 2026. The company reported the flaw to OpenAI on June 4. OpenAI accepted the report the next day and deployed a fix on June 8, according to Zenity’s disclosure timeline.

No evidence currently shows that attackers exploited the flaw in the wild. The demonstrated attack was a proof of concept conducted by security researchers. However, its mechanics challenge a central promise behind enterprise AI agents: users and administrators remain in control of what agents build, access, and approve.

The OpenAI Workspace Agents vulnerability was more than a malicious prompt. It combined an authenticated ChatGPT session, previously authorized connectors, scheduled execution, and attacker-controlled instructions. That combination gave the resulting agent the appearance and permissions of legitimate workplace automation.

This distinction matters for companies adopting agents from OpenAI, Microsoft, Google, Salesforce, and other vendors. Security systems commonly track users, devices, application sessions, and OAuth grants. An agent acting through a valid user and approved connections can fit poorly into those categories.

The immediate bug is closed. The harder problem remains open: how should an organization verify that an autonomous agent represents a user’s actual intent?

How the OpenAI Workspace Agents Vulnerability Worked

AgentForger turned an initialization feature into an unauthorized agent-building process inside an authenticated ChatGPT session.

OpenAI Workspace Agents are designed for repeatable business workflows. A user can describe a task, select connected applications, configure approvals, test the workflow, publish it, and set a schedule. OpenAI’s workspace agent guide describes both human-triggered and schedule-triggered execution.

Under normal conditions, those steps give users several opportunities to review the agent. They can inspect its instructions, control its tools, require approval for sensitive actions, and decide whether to publish it.

Zenity found that the agent builder accepted initialization state through URL parameters. One parameter selected a template. Another, called initial_assistant_prompt, provided instructions to the builder.

The critical behavior involved the second parameter. According to Zenity’s technical analysis, the builder automatically submitted and executed its contents when the page loaded. It did not simply display the text for the user to review.

An attacker could therefore place operational instructions inside an otherwise legitimate chatgpt.com link. When an eligible victim clicked it, ChatGPT opened the builder within that person’s authenticated session. The attacker did not need to imitate the ChatGPT domain or steal the user’s password first.

The demonstrated attack depended on three important conditions. The victim had to be signed into ChatGPT, have access to Workspace Agents, and have at least one previously authorized connector. That connector could link ChatGPT with services such as Outlook, Gmail, Slack, Teams, Google Drive, or SharePoint.

These requirements limit the vulnerable population. A random internet user without Workspace Agents or connected business applications would not provide the same attack path. Inside an enabled enterprise workspace, however, the conditions could be common among active agent users.

Previous authorization made the attack quieter. The forged agent reused connectors the victim had already approved, so it did not need to launch a new OAuth consent flow. OAuth is the standard process through which a user grants one service access to another account.

The proof-of-concept prompt instructed the builder to attach available connectors and change their approval settings. It also told the builder to publish the new agent and create multiple recurring schedules.

Those schedules were offset to produce an effective run every five minutes. Each run checked the victim’s mailbox for messages from the attacker with a specific subject prefix. The agent treated each matching email as a new assignment and returned results by email.

The agent did not need a continuously open browser tab after publication. It could wake according to its schedule, read the next instruction, use connected services, and send back its findings. This design converted a single click into a continuing command channel.

AgentForger resembles cross-site request forgery, or CSRF, an attack that causes an authenticated browser to perform an unintended action. The difference is the object being created. Traditional CSRF often triggers one transaction, while AgentForger created a system able to perform future transactions independently.

Zenity reported that OpenAI resolved the weakness within four days. The rapid fix reduced the direct exposure window following disclosure. It does not establish how long the underlying behavior existed before researchers reported it.

The Five-Minute Command Loop Changed the Stakes

The dangerous result was not the initial browser action, but an autonomous operator that could accept changing orders after the original click.

A conventional phishing link usually aims to steal credentials, deliver malware, or trigger an immediate transaction. Defenders can investigate the page visit, block the destination, reset the account, or remove the malicious program.

AgentForger followed a different pattern. The ChatGPT link initiated an agent-creation workflow on OpenAI’s own domain. The resulting agent then operated through services the victim had already connected.

This moved persistence into a legitimate cloud platform. Persistence is an attacker’s ability to maintain access after the initial compromise. Here, scheduled agent runs supplied that continuity without requiring installed endpoint malware.

Email served as the command-and-control channel. Command and control describes how an attacker sends instructions to compromised infrastructure and receives results. The forged agent watched for designated messages, executed their contents, and replied through an approved mail connector.

The five-minute interval also changed the attacker’s options. The malicious instructions did not need to anticipate every useful target before the link was sent. An attacker could adjust tasks after learning more about the organization.

Zenity’s proof of concept used the agent to map people, roles, projects, meetings, and internal communication channels. The researchers then directed it toward files, messages, credentials, and impersonation scenarios.

In one test, the agent searched connected storage and email for sensitive business material. Zenity says it identified documents including an acquisition term sheet, a board presentation, and employee information. These examples came from the researchers’ controlled environment, not a reported customer breach.

Another test instructed the agent to search Slack messages for password-like content. It organized matching results and returned them to the attacker’s email account, according to Zenity’s impact demonstration.

The researchers also tested internal phishing through Teams and Slack. Because messages originated through the victim’s connected identity, recipients could perceive them as trusted internal communication.

This is where the attack’s potential blast radius extended beyond the first user. A forged agent could use one identity to approach coworkers, search shared repositories, or create convincing requests within familiar workplace channels.

Zenity also demonstrated a business email compromise scenario involving a fraudulent payment request. That test illustrated a possible workflow rather than a completed financial crime. There is no public evidence that AgentForger caused an actual transfer.

The core risk came from aggregation. A human attacker might need separate access to email, storage, calendars, and chat before connecting their contents. A workspace agent is designed to reason across those systems as a combined working context.

That ability is valuable for legitimate tasks. An agent can prepare a project brief from meetings, messages, and documents without forcing a user to search each application manually. The same coordination can accelerate reconnaissance when the agent follows malicious instructions.

OpenAI warns that agents accessing applications can reach sensitive information and perform actions for users. Its agent safety guidance identifies prompt injection as a privacy risk and describes confirmations, monitoring, refusal behavior, and supervised browsing controls.

AgentForger exposed a separate layer of the problem. The malicious input did not merely influence an already running agent through a document or web page. It influenced the system responsible for building and configuring the agent itself.

That distinction increased the stakes for enterprise buyers. The agent builder was supposed to establish purpose, permissions, approvals, and scheduling. In the demonstrated flow, attacker-supplied language shaped all four.

The Central Conflict Is Capability Versus Control

Workspace Agents become more useful as they gain autonomy, but every delegated capability increases the cost of mistaken or forged intent.

OpenAI presents Workspace Agents as reusable systems that can connect with approved tools, act across workplace data, and run on schedules. Those functions distinguish an agent from a conventional chatbot that only answers a user’s current message.

The value proposition depends on reducing repeated human intervention. A user should not need to reconstruct the same workflow each morning. A scheduled agent can gather updates, summarize activity, or prepare routine outputs automatically.

Security controls often restore human intervention at sensitive points. An agent may read data automatically but ask before sending an email, editing a spreadsheet, or adding a calendar event. These checkpoints preserve autonomy for low-risk work while restricting consequential actions.

The OpenAI Workspace Agents vulnerability undermined that separation because the builder accepted natural-language instructions about security-sensitive settings. The same prompt that defined the agent’s task could reportedly change connector approvals to “Never ask.”

That created a circular trust failure. Approval settings were supposed to constrain the agent’s future actions. Yet the agent-building process could modify those settings under instructions supplied by the malicious URL.

The problem is not that natural language is inherently unsafe. Conversational configuration makes agents accessible to employees who cannot write workflow code. It also introduces ambiguity between ordinary task instructions and administrative changes.

Traditional enterprise software often separates content from control. A document cannot usually change an application’s permission policy merely by describing that change. Agent builders intentionally translate descriptions into working configurations, which weakens that old boundary.

OpenAI says enterprise administrators can control who may use, build, and share agents. Its product announcement also describes Compliance API visibility into agent configurations, updates, and runs.

Those controls are relevant, but they answer a different question. Role-based access determines whether a user is allowed to build an agent. AgentForger asked whether a permitted builder action actually reflected that user’s intention.

The victim’s valid identity made the forged agent difficult to classify. Authentication could show that the user was signed in. Connector records could show that the user had previously granted access. Platform logs could show that the agent was created within an authorized workspace.

Each signal could be technically accurate while the overall action remained unauthorized. The missing property was intent integrity: evidence that the person knowingly approved the resulting agent, permissions, and schedule.

This tension applies beyond OpenAI. Microsoft Copilot Studio, Google’s enterprise agent products, Salesforce Agentforce, and other platforms also connect models with business data and actions. Their architectures differ, so AgentForger should not be treated as evidence of the same flaw elsewhere.

They share the broader design challenge. An agent needs an identity, tools, instructions, triggers, and execution rights. Security teams must monitor the combination, not only each component in isolation.

An agent with harmless instructions and broad permissions can become dangerous if its goal changes. An agent with malicious instructions but no tools has limited reach. Risk rises sharply when untrusted input, private data access, and an outbound channel appear together.

The security community sometimes calls this combination the lethal trifecta. AgentForger assembled all three elements through the builder: attacker-controlled input, approved connectors, and email-based exfiltration.

That does not mean enterprises should abandon agent automation. It means agent creation deserves treatment similar to application deployment, service-account provisioning, and scheduled job creation. Each creates a durable actor inside an organization.

For knowledge workers, the lesson is equally concrete. Connecting an assistant to more workplace information improves context and reduces manual searching. It also concentrates access behind the assistant’s identity and configuration.

Teams building AI workflows should separate information gathering from external actions whenever possible. An agent summarizing approved sources presents less risk than one that can also send messages, modify records, and publish files.

A Fast Patch Does Not Close the Governance Gap

OpenAI removed the reported vulnerability, but organizations still need controls for agents that look legitimate while acting against their owners’ interests.

OpenAI’s response was fast by the timeline Zenity published. The issue was reported on June 4, triaged and accepted on June 5, then fixed on June 8. Zenity publicly released its findings more than six weeks later.

That sequence reflects coordinated vulnerability disclosure, in which researchers give a vendor time to resolve an issue before publishing technical details. It reduced the likelihood that public instructions would precede a platform fix.

SecurityWeek independently reported the disclosure and described AgentForger as a tailored CSRF vulnerability. Its security account also noted the required phishing click, authenticated session, Workspace Agents access, and existing connector authorization.

However, the public evidence has limits. Zenity conducted the attack in a research environment. No known incident has shown an external attacker using AgentForger against an OpenAI customer.

The phrase “rogue AI agent” can also create the wrong impression. The model did not spontaneously choose to rebel against its user. A human attacker supplied the objective, while a platform weakness allowed that objective to shape an authorized agent.

This framing matters because it points toward practical defenses. The incident concerns authorization, configuration integrity, visibility, and social engineering. It does not require assumptions about independent machine intent.

Organizations should therefore avoid treating the patch as the only necessary response. A future vulnerability could target a different builder field, connector workflow, sharing feature, or trigger mechanism. Misconfiguration could produce similar outcomes without any platform-level exploit.

Administrators first need a reliable inventory of agents. That inventory should record each agent’s owner, instructions, connectors, approval policies, triggers, sharing scope, and recent activity.

Creation events deserve particular attention. A new agent that immediately connects several applications, suppresses approvals, publishes itself, and installs recurring schedules should generate scrutiny. Each choice might be legitimate alone, but the sequence is unusual.

Scheduled activity also needs an accountable owner. Companies routinely review service accounts and automated jobs because they continue operating when no person is watching. Workspace agents require the same lifecycle discipline.

Connector permissions should follow least privilege, meaning each agent receives only the access required for its task. Reusing every connector previously authorized by a user creates unnecessary reach and makes incident containment harder.

Read and write access should be separated where platforms permit it. An agent gathering information for a summary does not automatically need permission to send external email or alter shared documents.

High-impact actions should retain independent approval controls. More importantly, ordinary agent instructions should not be able to weaken those controls without a separate confirmation step.

Security teams also need runtime detection. Build-time review cannot guarantee that an agent’s future instructions will remain safe. Monitoring should identify unusual data access, unexpected external recipients, credential searches, bulk retrieval, and new internal messaging patterns.

These signals must include the agent as an actor. Logging only the human account may hide the distinction between a person’s interactive behavior and an automated agent’s scheduled run.

Incident response procedures should support suspending an agent without disabling an employee’s entire account. Responders also need to determine which connectors the agent used, what data it accessed, and which messages it sent.

User education still has a role, but “do not click suspicious links” is insufficient. The AgentForger link used the real ChatGPT domain. Employees need to recognize that authenticated links can carry state and initiate consequential workflows.

A safer interface should make those consequences visible. If opening a link causes a builder to create, publish, or schedule an agent, the platform should require an explicit review outside the attacker-controlled content.

The strongest confirmation would summarize the resulting configuration in trusted interface text. It would show the agent’s instructions, applications, permissions, approval policy, schedule, and sharing scope before activation.

Agent Security Now Extends Beyond Human Identity

The incident pressures security teams to govern agents as durable digital actors, not merely features operating under employee accounts.

Identity and access management traditionally asks whether a user or service has permission to reach a resource. Agentic systems add another question: what autonomous process is using that permission, for which purpose, and under whose current direction?

An employee may authorize Outlook because ChatGPT helps summarize email. That authorization does not necessarily mean every future agent should read mail, send messages, and execute emailed instructions without review.

Inherited access can blur this distinction. When a forged agent operates as the victim, downstream applications may see valid requests from an approved integration. They may not know the request originated from a newly created autonomous workflow.

Security products built around endpoints face a similar blind spot. The agent can run within a vendor’s cloud rather than on the employee’s laptop. Endpoint detection may observe the initial browser visit but not each later scheduled action.

Network controls can also miss context. Connections among trusted cloud services may look ordinary. The suspicious element lies in the agent’s goal, scheduling, and cross-application behavior rather than a clearly malicious network destination.

This creates pressure for agent-specific telemetry. Administrators need to connect creation records with runtime events, connector calls, approval changes, and outbound results.

OpenAI’s documentation says Workspace Agents can be tested before publishing, shared with teams, used through Slack, scheduled, or triggered through an API. Each execution path creates a different monitoring requirement.

A manually triggered agent has a user present at the start. A scheduled agent can run while its owner is offline. An API-triggered agent may receive instructions from another automated system.

Organizations should assign risk according to those triggers. Long-running or externally triggered agents deserve stricter review than simple assistants that operate only during an active user request.

Sharing introduces another layer. An agent created under one person’s identity may become available to colleagues or a wider workspace. Security teams must understand whether shared users inherit the creator’s access or operate through their own permissions.

Governance should also account for instruction changes. An agent approved for one purpose can become materially different after its prompt, connectors, or schedule changes. Significant modifications should trigger renewed review.

This approach resembles change management for production software. A reviewed deployment does not give every future version permanent approval. Security-relevant changes create a new decision point.

Enterprise buyers should ask vendors direct questions about these controls. Can administrators enumerate every agent? Can they inspect instructions and triggers? Can they prevent agents from changing approval settings through natural language?

They should also ask whether logs distinguish human actions from agent actions. A useful audit record must show which agent acted, what instruction initiated the run, which connector it used, and what approval applied.

Retention matters during investigations. If detailed agent activity disappears quickly, responders may be unable to reconstruct data access or outbound communication after discovering a suspicious workflow.

Cross-platform agents make this harder. A single agent can combine email, messaging, storage, calendars, and business systems. No individual application sees the complete sequence.

The agent platform may therefore hold the best evidence of intent and orchestration. Application vendors still need enough metadata to identify automated requests and enforce their own policies.

Regulators and auditors will eventually confront the same attribution problem. A company remains responsible for actions performed through its authorized systems, even when an agent selected the specific steps.

AgentForger offers a useful warning without a reported victim. It shows that an attacker may not need to compromise each connected application separately. Controlling the orchestration layer can expose them together.

What to Watch After AgentForger

The next test is whether agent platforms make intent verifiable, agent activity observable, and inherited access narrow by default.

The first signal to watch is OpenAI’s treatment of agent creation and configuration changes. Stronger confirmation should occur before publishing, scheduling, connecting applications, or reducing approval requirements. That would reinforce the conclusion that the company sees agent intent as a separate security boundary.

The second signal is improved administrative visibility. OpenAI says administrators can use governance controls and compliance data for Workspace Agents. Buyers should watch for complete inventory, searchable configuration histories, agent-level activity records, and direct suspension controls.

Better visibility would help organizations find a forged or misconfigured agent before it performs repeated actions. Limited logs would weaken confidence that customers can independently detect the next attack chain.

The third signal is how competing enterprise agent platforms respond. Microsoft, Google, Salesforce, and other vendors do not need the same URL flaw to face similar questions. Their responses should clarify how builders validate external input, protect approval settings, and distinguish human intent from automated configuration.

Organizations do not need to wait for those changes. They can restrict agent-building access, reduce connector scope, review recurring agents, and preserve approval gates for outbound or destructive actions.

They can also test their own detection assumptions. Would a newly published agent with several connectors appear in an alert? Would repeated external email from scheduled runs look different from ordinary employee activity?

The OpenAI Workspace Agents vulnerability is fixed, and there is no public evidence of exploitation. Its larger lesson remains relevant because agent platforms are becoming execution environments, not only conversational interfaces.

A trusted domain cannot make every embedded instruction trustworthy. A valid identity cannot prove that every agent reflects the owner’s intent. An approved connector cannot justify every future use of its permissions.

For developers, enterprise buyers, and knowledge workers, the practical question is now simple: can you see every autonomous agent acting through your accounts and explain why it has each permission?

Review that inventory before connecting another system. Check schedules, approval policies, external recipients, and dormant agents. Then ask vendors for controls that treat agent creation as a security event.

That is the standard the next workspace agent release must meet.