One Link, One Insider: AgentForger and the New Agent CSRF
One Link, One Insider: AgentForger and the New Agent CSRF
The old CSRF question was whether a malicious link could make a logged-in user submit a request. The new agent question is whether that link can create a persistent worker that keeps acting after the user leaves.
On July 23 and 24, 2026, security researchers disclosed AgentForger, a vulnerability in ChatGPT Workspace Agents that OpenAI had already patched. The research described a simple but important failure mode: a crafted ChatGPT Agent Builder URL could cause a logged-in user to create and deploy an attacker-controlled autonomous agent inside the user’s workspace.
That is not normal phishing. A normal phish tries to steal a token, a password, a session, or a file. AgentForger showed a higher leverage target: use the victim’s identity to manufacture a new agent that inherits the user’s connected apps, workflows, and approvals.
The tactical bug was fixed quickly. The architectural lesson will outlive it.
Why this matters
Agent creation is not a preference. It is an identity, permission, persistence, and automation event. Treating it like a normal UI action is how a link becomes an insider.
What happened
Zenity Labs reported that AgentForger abused the Agent Builder workflow through URL parameters. The dangerous behavior was that an attacker-controlled initial prompt could be accepted as builder input and acted on when the victim opened the link. The proof of concept showed the Builder creating, configuring, publishing, and scheduling an agent in the victim’s workspace.
According to Zenity, the forged agent could inherit access to enterprise apps the employee had already authorized, including email, calendar, cloud storage, and collaboration tools. SecurityWeek summarized the impact as an attacker being able to create, insert, and remotely control an invisible autonomous AI agent inside an organization.
OpenAI removed the risky parameter after responsible disclosure. The public reporting says the issue was fixed before disclosure and there was no indication of malicious exploitation in the wild. That matters. This is not a panic story.
It is a control-plane story.
The attack chain in one screen
The interesting part is not that a link could carry malicious input. Web security has known that class of bug for decades. The interesting part is the object being forged.
In classic CSRF, the attacker forges a request. In agent CSRF, the attacker forges a worker.
That worker can have memory. It can have scheduled execution. It can have connector access. It can read and write across SaaS. It can interact with people through trusted enterprise channels. Most importantly, it can keep going after the browser tab is gone.
Why this is not just “phishing, but AI”
Security teams are good at thinking about account takeover. They are less prepared for account delegation takeover, where the employee remains legitimate but a new delegated actor appears underneath the employee’s identity.
AgentForger sits in that gap.
Identity inheritance
The forged agent does not need its own password if it can inherit the employee’s already authorized connectors and workspace permissions.
Persistence by design
A scheduled agent is supposed to run later. That turns a one-click event into an ongoing foothold unless creation and scheduling are audited.
Trusted channel abuse
Email, files, calendar, and chat become command and exfiltration routes because the agent is acting from inside the collaboration graph.
This is what makes the vulnerability useful as a warning even after the patch. Enterprises are turning “create an agent” into a low-friction productivity path. That is reasonable for adoption. It is dangerous for security if the act of creating an agent does not receive the same treatment as creating an OAuth app, a service account, an automation rule, or a privileged API key.
The control plane everyone forgot
Agent builders are becoming internal platform engineering surfaces. They assemble prompts, schedules, tools, connectors, and policy settings into a runnable unit. That makes the builder a control plane.
The control plane should answer five questions before an agent is allowed to exist:
| Question | Weak answer | Security answer |
|---|---|---|
| Who created it? | Whatever user session loaded the page | Explicit creator identity plus high-risk confirmation |
| What can it access? | Whatever connectors the user already authorized | New agent-specific grant with least agency scope |
| Can it run later? | Schedule accepted as a normal setting | Separate approval for persistence and recurring actions |
| Can approvals be disabled? | Agent instructions can request lower friction | Approval policy is admin-owned and cannot be prompt-owned |
| How is it detected? | It looks like user activity | Agent creation, connector binding, and scheduled runs emit distinct events |
The most important row is the fourth. Approval behavior must not be configurable by the same untrusted instruction stream that defines the agent’s goal. Otherwise the attacker does not only create the worker. They also tell it which brakes to remove.
policy.agent_creation
actor = employee_session
source = external_url
requested_connectors = email, drive, calendar
requested_persistence = recurring_schedule
requested_approval_mode = never_ask
decision = deny_or_escalate
That is the policy shape security teams need. The product can still be easy to use. But the high-risk transition from “assistant draft” to “persistent delegated actor with connectors” needs deterministic governance that cannot be talked around.
OWASP Agentic Top 10 mapping
The OWASP Top 10 for Agentic Applications (2026) is useful here because AgentForger is not one clean category. It crosses identity, tools, memory, governance, and human trust.
| OWASP risk | How it appears in AgentForger | Control priority |
|---|---|---|
| ASI01 Goal Hijack | External instructions become the seed goal for a newly created agent. | Separate natural language setup from privileged configuration. |
| ASI02 Tool Misuse | The agent can use connected applications for collection, exfiltration, and impersonation. | Require agent-specific grants and action-level policy checks. |
| ASI03 Identity Abuse | The forged agent operates under the victim employee’s identity and app access. | Make agent identity visible and distinct from human identity. |
| ASI07 Repudiation | Activity can look like normal user-driven workspace behavior. | Log creation, prompt source, connector binding, policy changes, and every scheduled run. |
| ASI10 Rogue Agents | A persistent delegated actor can remain after the initiating click. | Inventory, owner review, expiry, kill switch, and anomaly detection for all agents. |
The OWASP framework defines the risk shape. The operational takeaway is simpler: do not let a prompt create authority.
What CISOs should ask this week
Start with discovery. Which users can create agents? Which workspaces have agent builders enabled? Which agents have schedules? Which agents can use email, files, calendars, CRM, ticketing, chat, cloud consoles, or code repositories?
Then ask how agent creation is approved. If a user can create a persistent agent with connected apps from a normal browser interaction, treat that as a privileged operation. If approval prompts can be lowered by the agent’s own configuration, treat that as a policy bypass.
Finally, inspect telemetry. The SOC should not have to infer that an agent exists from downstream file reads and email sends. The control plane should emit first-class events:
- Agent created
- Agent published
- Connector attached
- Schedule enabled
- Approval mode changed
- External URL used as creation source
- Agent action executed
- Agent owner changed or removed
These events should be queryable by agent ID, human owner, connector, workspace, and source. Without that, “find every agent created from a link this week” becomes an incident response archaeology project.
Practical line
Any workflow that creates an agent, attaches a connector, disables approval, or enables persistence should be treated like creating a new non-human identity with production access.
The design pattern that holds
The durable fix is not a better warning banner. It is a control model:
- Separate draft from deploy. Let users draft agents freely, but require a governed transition before the agent can run with connectors or schedules.
- Bind connectors to the agent, not only the user. A user may have Drive access. That does not mean every agent the user creates should inherit all Drive access.
- Make approval policy immutable from prompts. Natural language can describe desired behavior. It should not set the rules for bypassing review.
- Expire agents by default. Persistent agents should have owners, purpose, scopes, expiry, and review cadence.
- Detect creation source. Agent creation from external links, copied templates, imported files, or marketplace packages should carry different risk scores.
- Give every agent a kill switch. Disable execution, revoke connectors, stop schedules, and preserve evidence in one operation.
That is the difference between agent productivity and unmanaged internal automation.