AI Agent Security: the AgentForger CSRF Flaw

In June 2026, researchers at Zenity Labs found a way to forge an entire AI agent from a single malicious URL, inside an organization's trust boundary. The flaw, named AgentForger, does not forge a single request: it forges an autonomous attacker-controlled agent.

Direct answer: AgentForger is a Cross-Site Request Forgery (CSRF) attack that exploits the ChatGPT Workspace Agents builder. A logged-in victim who clicks a malicious link triggers, with no further interaction, the creation of an AI agent that connects to already-authorized accounts (Outlook, Gmail, Slack), disables approval controls, and keeps running through a schedule. For companies processing personal data, it is a blunt reminder of the security risks that AI agents introduce.

What is AgentForger?

AgentForger is a Cross-Site Request Forgery (CSRF) attack discovered by Zenity Labs in the ChatGPT Workspace Agents builder. A malicious URL pre-fills and automatically executes an instruction that creates an attacker-controlled autonomous agent, disables approval guardrails, and gives it access to the victim's already-connected accounts, inside the organization's trust boundary. OpenAI fixed the flaw four days after disclosure.

How does the Workspace Agents builder normally work?

OpenAI's Workspace Agents connect to Outlook, Gmail, Slack, Google Drive, SharePoint, and Teams, can execute actions on those services, and run on a schedule. They are built through a conversational builder: the user describes the agent in natural language, picks a starting template, configures tools, decides which actions require approval, tests in Preview mode, and publishes.

In that sequence, several moments assume human control: choosing the template, providing the instructions, approving connected tools, reviewing approval settings, and deciding whether to go live. AgentForger neutralizes exactly that control.

How does the attack forge the agent?

The builder lives at chatgpt.com/agents/studio/new. Researchers found it accepts initialization state through URL parameters. Two matter:

• template_name : selects a prebuilt starter template, such as chief-of-staff.
• initial_assistant_prompt : holds the instructions given to the builder. On page load, this value is not merely placed in the prompt box: it is automatically submitted and executed.

The instruction embedded in the URL therefore becomes the first command the builder acts on. The attacker needs no interaction with the victim's browser: they send a regular phishing-style link:

https://chatgpt.com/agents/studio/new?template_name=chief-of-staff&initial_assistant_prompt=[attacker's instruction]

When a logged-in victim clicks, ChatGPT opens the builder in their authenticated session and automatically submits the prompt contained in the URL.

What conditions does the attack require?

The attack requires a victim logged into ChatGPT, with access to Workspace Agents and at least one already-authorized connector. That point is central: because the connector is already authorized, the attack triggers no new OAuth consent screen. No consent prompt appears, which makes the whole flow invisible to the user.

What does the payload look like?

In its proof of concept, Zenity Labs structured an instruction that walks the entire creation flow: connect all already-authorized connectors, exclude custom MCPs, switch each connector to "never ask" (no approval for reads or writes), create several schedules offset by five minutes, then at each run process incoming emails and send results back to an attacker-controlled mailbox.

Concretely, the builder:

• Created an agent named "TASK Mail Operator" from the chief-of-staff template.
• Attached existing connectors, including Outlook and template defaults such as Gmail, Calendars, Slack, and Teams, with no new consent screen.
• Disabled the approval gate: writes default to "always ask", but the instruction forces Outlook to "never ask".
• Published the agent live, with several offset hourly schedules creating a check-in every five minutes.
• Invoked Preview mode for immediate execution.

Preview mode, meant to let users test before publishing, actually executes the agent against the victim's connected accounts with the freshly configured approval settings. Since the prompt already switched Outlook to "never ask", the run triggers no confirmation.

How does the attacker keep control?

The Workspace Agents scheduler, useful in normal use to automate a recurring task, becomes the persistence mechanism here. Once the agent is published, the attacker needs no new click and no revisit: the agent wakes up on schedule, reads the victim's inbox for instructions to execute, acts on connected services, and sends results back.

The agent becomes a persistent operator: the initial click installs it, the schedule keeps it alive, and the connected apps provide both a source of commands, access to sensitive data, and a path to send results out.

What are the root causes?

Researchers identified two behaviors that combine:

1. Cross-site auto-execution, no CSRF protection: the builder treats initial_assistant_prompt as executable input rather than user content requiring confirmation. An attacker-controlled URL therefore triggers state-changing operations inside the victim's authenticated session, without explicit intent.

2. Security-sensitive configuration exposed to natural-language instructions: the same prompt can change security settings, including approval policies and execution schedules. The mechanism meant to require human approval for sensitive actions can itself be disabled by the executed instruction.

Together they complete the lethal trifecta: an untrusted input (the URL), access to private data (the connectors), and a way to exfiltrate (sending email). Where most exploits must bypass guardrails, this one is handed a build tool and told to construct an agent with the guardrails already off.

According to Zenity Labs, the second part of this research details the blast radius after the agent goes live: organization reconnaissance, sensitive data harvesting, credential recovery, victim impersonation, internal phishing, and staging business email compromise.

What does this mean for data protection (GDPR)?

Even though the flaw is fixed, it illustrates risks companies must bake into any AI agent deployment. Can an agent that accesses personal accounts without validation remain GDPR-compliant?

Several articles apply directly:

Security of processing (GDPR Article 32): the controller must implement appropriate technical and organizational measures to ensure a level of security appropriate to the risk. An exploitation chain that exposes personal data to an unidentified operator is the textbook failure of this requirement.

Integrity and confidentiality (Article 5(1)(f)): data must be processed in a way that ensures appropriate protection against unauthorized access or use. As the CNIL stresses, data security is one of the founding principles of the regulation.

Data protection by design and by default (Article 25): minimal approval settings, the impossibility of disabling controls through a single instruction, and limiting exposed connectors all fall under protection by design and by default.

Transfers outside the EU (Article 44): an agent that processes personal data through a US-hosted model performs an international transfer subject to Article 44 requirements. The CLOUD Act (2018) still aggravates this risk, letting US authorities demand access to data held by US companies, even on European infrastructure.

How do you secure AI agents in the enterprise?

The AgentForger case pushes toward concrete habits, whatever agent provider you use:

• Limit the connector surface: expose only the tools strictly needed for the task, never every personal account.
• Never let a prompt disable approval controls: any change to the approval policy must go through a human channel.
• Audit published agents and schedules: spot unknown agents, attached connectors, and unusual processing times.
• Log every agent action (Article 5(2)) to be able to demonstrate compliance in case of an incident.
• Favor limited access and expiring sessions, as I detail in my post on AI agent governance.
• For sensitive data, prefer EU infrastructure: the topic connects to the discussion on RAG agent data leaks.

As an AI integration consultant specialized in GDPR-compliant AI, I recommend addressing these points before any production rollout. The audit framework and permission practices are part of my AI agent integration services. This is not about alarm: the flaw only proves that AI agent security is not guaranteed by default and must be built.

TL;DR

AgentForger is a CSRF that does not forge a single request: a malicious URL pre-fills the ChatGPT Workspace Agents builder, executes an instruction that creates an attacker-controlled autonomous agent, removes approval controls, and uses its schedule to run commands continuously. OpenAI fixed the flaw within four days. For companies, the incident echoes security obligations already set by the GDPR (Article 32, Article 25) and argues for agents with minimal permissions, audited, and where possible hosted in Europe.

Evaluating the security of your AI agents or preparing a GDPR-compliant deployment? Let's talk.