AgentForger: one link spawns an AI agent in your company

Classic CSRF (Cross-Site Request Forgery) means that clicking a crafted link performs one unintended action in an application you’re logged into: changing an email address, making a transfer, deleting a resource. Unpleasant, but bounded — one request, one consequence.

Researchers at Zenity Labs showed what happens when you aim that same technique at an agent platform. The vulnerability they named AgentForger allowed a single link to create, configure, publish and schedule an autonomous agent in a victim’s ChatGPT Workspace. The result wasn’t a single request but a new, persistent entity operating inside the organisation — with tools, a schedule, approved permissions and access to already-connected connectors. OpenAI fixed the bug within four days of disclosure; the details went public in late July 2026.

It’s the most interesting flaw of the month not because it was technically hard, but because it demonstrates a new class of consequence.

Why “CSRF against an agent” is a different risk category

Zenity called it Cross-Site Agent Forgery, and the name captures the difference well. Compare:

	Classic CSRF	AgentForger
Result	one action	a new agent exists
Lifetime	the moment of the click	persistent, until found and removed
Permissions	whatever the session has, once	tools + connectors, repeatedly
Initiative	none	the agent acts on its own schedule
Visibility	a trace in action logs	looks like a legitimate company resource

The critical change is the “initiative” row. The victim clicks once, and the attacker gains something that returns to work by itself — in the described scenario the agent was triggered on a short, recurring interval. This is no longer a “steal and leave” attack but an implant: a persistence mechanism built not from malware but from the platform’s legitimate features.

The attack chain step by step

Based on Zenity Labs’ description, the flow looks like this:

1. Delivering the link. Ordinary phishing — an email, a chat message, a document. The victim must be logged into their ChatGPT Workspace environment (and they are, because it’s a work tool).
2. Forcing background actions. The click causes requests to the agent panel in the context of the victim’s authenticated session. No visible wizard, no conscious consent.
3. Creating and configuring the agent. The attacker defines the agent’s system instructions (its “purpose”), assigns tools and approvals.
4. Publishing and scheduling. The agent is published into the workspace and given a recurring trigger — so it resumes work without the victim’s involvement.
5. Operating on someone else’s permissions. The agent uses the victim’s already-authorised connectors: cloud drives, chat, mail. It doesn’t need to break authentication — it inherits access the organisation deliberately granted to a human.
6. Pursuing the attacker’s goal. In the researchers’ scenario that meant reconnaissance, collecting sensitive documents and capturing passwords mentioned in conversations.

Note step 5 — that’s the crux. No “break-in” occurred in the classic sense. What occurred was abuse of delegated trust: the company let an employee connect tools to an assistant, and the attacker hijacked that delegation.

The autonomous insider — why it’s hard to detect

Traditional threat detection looks for unusual things: unknown executables, strange processes, traffic to suspicious domains. AgentForger produces none of those signals.

From a monitoring perspective you see: a company account, a company SaaS tool, a previously authorised connector, access to documents the employee is entitled to anyway. Everything looks legitimate, because formally it is. The only anomaly is intent and rhythm — an agent nobody knowingly commissioned, running regularly and reaching wider than its supposed owner.

This is exactly the class of problem we described under non-human identities (NHI): an agent is an account that holds permissions, performs actions and should have a lifecycle — and in most companies it has none. We covered the related browser-side risk in browser agent security.

What this means for defenders

Treat “create an agent” as a high-risk operation. Like an MFA reset or granting an admin role. It should require deliberate, CSRF-resistant confirmation — ideally an extra approval when the agent gains a schedule or access to data connectors.

Inventory your agents. Ask the question most organisations can’t currently answer: how many agents run in our workspace, who created them, what tools do they hold and when did they last act? Without that list you’ll never notice one extra agent. It’s the same discipline as discovering shadow AI.

Limit connector scope. Least privilege applies to integrations exactly as it does to accounts. A connector to the entire company drive “because it’s convenient” is a ready-made exfiltration channel the day someone hijacks the agent. Worth revisiting the fundamentals of OAuth 2.0 security — scopes, consent and the ability to revoke it.

Log and alert on agent lifecycle events. Creation, changes to system instructions, tool additions, schedule assignment, publication. These are your 4720/4732 of the agentic world — if you don’t collect them, you have no way to spot an implant.

Include agents in your response plan. Answer in advance: who can immediately disable an agent? how do we revoke connector consent? how do we establish what the agent reached? We laid this out in AI incident response.

Test the agent platform like an application. The vulnerability lived in the product’s web layer, not in the model. Classic AppSec questions — are state-changing operations protected by a token, is SameSite set sensibly, do critical actions require re-authentication — mattered more than anything LLM-specific. For the whole picture, an AI/LLM security audit and an agent red-team harness help.

Frequently asked questions (FAQ)

Was this a model vulnerability or an application one? Application. It wasn’t prompt injection or “tricking” the model, but a missing protection on state-changing operations in the agent panel. The model did exactly what its instructions said — the problem was that the attacker wrote the instructions.

The flaw is fixed — why care? Because one instance of a general pattern was fixed. Every platform that lets you create agents with tools, schedules and data access shares this attack surface. AgentForger is a proof of feasibility, not an isolated case.

How do we check whether something like this is running in our tenant? Review the list of agents/assistants in your workspace: who authored them, what instructions, schedules and connectors they hold. Look for entities with no owner, a recurring trigger and broad access. Then check connector logs for reads at regular intervals outside working hours.

Does banning AI at work solve it? No — it moves the problem into shadow IT, where you have no visibility at all. A controlled path works better: approved tools, restricted connectors, an agent registry and event logging.

Summary

AgentForger shows that in agentic architectures an old web vulnerability yields a new quality of consequence. One click no longer ends in a single action but in the creation of an autonomous worker running on the victim’s permissions, following the attacker’s instructions, on the attacker’s schedule. Defence needs no exotic tooling: an agent inventory, minimal connector scopes, lifecycle logging and treating agent creation as a privileged operation. If you’re rolling out AI agents and want to know what happens after one employee’s click — let’s find out together.

---

Sources and further reading: Zenity Labs — AgentForger, The Hacker News, The Register, OWASP Top 10 for LLM Applications.