Agent creation arrived through the URL

ChatGPT Workspace Agents are built to perform recurring work across connected business services. A user can describe an agent in natural language, attach tools such as Outlook or Slack, set approval rules, test the configuration, and publish it on a schedule.

That workflow contains several decisions that ought to belong to the user. Which services can the agent reach? Can it send messages or delete data without asking? Should it run again tomorrow? Does the configuration deserve to go live at all?

Zenity Labs found that two URL parameters could drive those decisions. template_name selected a starter agent, while initial_assistant_prompt supplied instructions to the builder. The second value was automatically submitted when the page loaded. A prompt embedded in a link became an executing instruction inside the victim's authenticated ChatGPT session.

The attack still required a click. The target also had to be logged into ChatGPT, have access to Workspace Agents, and have at least one previously authorized connector. Those conditions are meaningful limits. They are also routine conditions in the enterprise environment the product was designed to serve.

One click built the operator

Zenity's proof of concept used the Chief of Staff template and instructed the builder to complete the entire setup without follow-up questions. The prompt attached already connected services, switched their approval policies to Never ask, created recurring schedules, told the agent to process specially labeled emails from an attacker, and ordered it to publish itself.

The builder complied. It created an agent, connected available services, removed approval prompts for write actions, scheduled repeated runs, and invoked Preview Mode. Preview was not a harmless rendering of future behavior; it executed the agent against the connected accounts using the newly weakened approval settings.

Zenity offset several schedules so the agent woke roughly every five minutes. On each run it checked for emails from the attacker with a TASK subject, performed the instructions through connected applications, and emailed results back. The original link created persistence. Later commands arrived through the victim's own inbox without requiring another click or an open browser tab.

Calling this a forged insider is fairer than the usual breathless security nickname. The resulting agent operated with the user's identity, inherited approved connections, and communicated through trusted internal channels. It did not need to steal a password each time it ran because the product had already handed it durable authority.

Connected services became one searchable office

In the second part of the research, Zenity tested what the forged agent could do inside a controlled organization. The agent searched Outlook, Slack, Teams, Google Drive, SharePoint, and calendar data to build a map of employees, projects, meetings, and internal workstreams.

It located mock merger documents, board material, employee compensation data, invoices, passwords, and service credentials. Because the connected tools exposed several systems through one agent, the attack did not have to search each application manually. The model gathered context across them, ranked what appeared useful, summarized it, and sent results out by email.

The researchers also instructed it to send phishing messages through Teams and Slack, prepare a wire-fraud lure, and contact internal users from the victim's trusted identity. An external phish has to imitate an employee. This agent had already been granted the employee's channels.

These outcomes were demonstrations with mock data. Zenity did not report compromised companies, stolen real credentials, or completed fraudulent transfers. The blast radius describes what the reproduced product behavior allowed, not a body count quietly hiding behind the word "could."

Why the AI workflow mattered

AgentForger included a traditional web-security failure: attacker-controlled URL input triggered authenticated, state-changing behavior without a proper cross-site request forgery boundary. A plain URL-driven settings bug at an AI company would normally belong in a vulnerability database rather than this cemetery.

The harmful sequence depended on the agent builder treating natural-language instructions as authority over security controls. The same prompt that defined the agent's job could attach connectors, lower approval requirements, create schedules, publish the agent, and launch it. The product translated hostile text into a durable autonomous identity with tools.

That conversion is the AI-specific defect. A normal preference page might toggle one setting through a bad request. Here, one auto-submitted prompt assembled an ongoing operator that interpreted future commands, selected actions across applications, and used the company's own collaboration tools to return data.

The builder also let the prompt disable the approval mechanism that was supposed to protect sensitive actions. A guardrail controlled by the untrusted instruction it is meant to constrain is closer to a suggestion than a security boundary.

Four days to patch, years of old assumptions

Zenity reported the issue to OpenAI through Bugcrowd on June 4, 2026. It was triaged and accepted the next day, then fixed on June 8. SecurityWeek's report confirmed the disclosure and described the required phishing click, existing connector access, hidden agent, and recurring email command channel.

The response time was fast. The architectural problem is older than this product: software often assumes that an authenticated user initiated whatever happens inside an authenticated session. Agent builders add another delegation layer. The user may click a link, a prompt may configure the agent, and the agent may later act on an email. By the time a sensitive operation occurs, the original human intent is several handoffs away.

Secure agent creation needs deterministic checkpoints around those handoffs. URL content should never auto-submit a state-changing prompt. Attaching an existing connector should require fresh, visible confirmation. Approval policies should not be editable by the same untrusted prompt that defines the job. Publishing and scheduling deserve separate review, especially when the agent can send messages or export data.

Organizations also need an inventory of agents running under employee identities, including their schedules, connectors, approval settings, and recent actions. A scheduled agent that nobody remembers creating should look suspicious before it has time to become the most diligent employee in the phishing department.

OpenAI closed this particular route before public disclosure. AgentForger still earned its plot because the shipping workflow accepted one attacker-controlled link and turned it into persistent delegated authority. Enterprise agents are supposed to save people from repetitive work. Quietly taking assignments from somebody else's mailbox was not among the advertised efficiencies.