Skip to main content
CISO Daily
Risk Analysis

AgentForger: When a Phishing Link Becomes a Persistent AI Insider

7 min read
CISO Daily
AgentForger: When a Phishing Link Becomes a Persistent AI Insider

Zenity Labs published research yesterday naming a vulnerability class they call AgentForger — a cross-site request forgery attack against enterprise ChatGPT Workspace Agents that creates an attacker-controlled AI agent inside a target organisation via a single phishing link. OpenAI patched the specific implementation flaw on June 8, four days after disclosure. The vulnerability itself is fixed. The threat model it demonstrates is not.

This briefing covers what happened, why it matters for enterprise AI governance, and the structural risk it surfaces that no patch fully resolves.

What AgentForger Did

ChatGPT’s Workspace Agents feature allows enterprise users to build and deploy autonomous AI agents within their organisation’s ChatGPT environment. These agents can be authorised to access enterprise applications: email, calendar, cloud storage, collaboration platforms such as Slack and Microsoft Teams.

The AgentForger vulnerability was a CSRF flaw in the agent creation endpoint. Because ChatGPT’s Workspace interface did not validate the origin of agent creation requests, an attacker who could get an authenticated enterprise user to visit a crafted URL could trigger the creation of a new agent in that user’s workspace — entirely without the user’s knowledge or consent.

The created agent was invisible to the victim. It inherited whatever application authorisations the victim had already granted to their ChatGPT environment. And it took instructions from the attacker: email subjects beginning with TASK were treated as commands. The agent executed them autonomously and emailed results back.

The capability set available to the rogue agent included:

  • Reading and searching email content
  • Accessing calendar and contacts
  • Querying cloud storage accessible to the user
  • Posting messages or sending emails as the victim
  • Conducting internal reconnaissance against the organisation’s connected applications

This is business email compromise with an AI execution layer — no phishing response analysis required, no manual session maintenance, no need for the attacker to understand the specific tools in use. The agent navigates the enterprise environment on the attacker’s behalf.

Why the Patch Doesn’t Fully Solve the Problem

OpenAI fixed the CSRF flaw rapidly. The specific AgentForger attack vector no longer works. This is the right outcome from a vulnerability response perspective.

What it doesn’t resolve is the architectural pattern that made the vulnerability dangerous: enterprise AI agents are granted persistent access to sensitive business applications, and the security model for that access is thin.

Consider what made AgentForger work:

Agents are persistent and autonomous. Once created, the rogue agent continued to operate without any further input from the victim or the attacker. It was, by design, self-directing.

Agent authorisation inherits from the creating user. The victim’s prior authorisation decisions — granting ChatGPT access to email, calendar, Slack — became the rogue agent’s access. The agent didn’t need to separately authenticate; it inherited a trusted identity.

Agent activity was indistinguishable from legitimate activity. The rogue agent’s email reads, calendar queries, and Slack messages looked, at the application level, identical to the victim’s own activity. Standard DLP and UEBA tools have no visibility into what an AI agent is doing on the user’s behalf.

There was no approval gate for agent creation. Enterprise users could create agents and grant them access without organisational approval. Security teams had no oversight of what agents existed, what they were authorised to do, or who created them.

The patch closed the CSRF vulnerability. It did not create approval workflows for agent creation, it did not limit agent authorisation scope, and it did not add visibility into agent-level activity. Those are governance decisions, not patch decisions.

The Governance Gap This Surfaces

Most enterprises that deploy ChatGPT Enterprise or similar AI agent platforms have implicitly accepted a new category of privileged access without applying the governance frameworks they would apply to human or service account access.

If a service account had access to an executive’s email, calendar, and Slack, it would go through approval, be logged, and be subject to access review. If that same access is granted to an AI agent by a user clicking through an authorisation prompt, it typically bypasses all of that.

The questions every CISO should now have answers to:

What AI agents are currently authorised in your environment? Most organisations cannot answer this. The agent inventory problem parallels the service account sprawl problem of the early cloud era — except that agents can act autonomously, at scale, and at machine speed.

What authorisations have those agents been granted? An agent with access to email and Slack has, effectively, the access of the employee who created it — across all applications the employee had authorised. The blast radius from a compromised or maliciously created agent is the employee’s full application access scope.

How would you detect a rogue agent? DLP tools monitor data movement. UEBA tools detect anomalous user behaviour. Neither is designed to attribute activity to a specific agent rather than the user the agent is acting as. Rogue agent activity is likely invisible in current enterprise monitoring architectures.

Who has authority to create agents and grant authorisations? In most ChatGPT Enterprise deployments, this is effectively any user. There is no workflow equivalent to IDAM provisioning.

What Should Change

Establish an agent inventory. Know what AI agents exist in your ChatGPT and broader agentic AI environments. This is a prerequisite for any security governance of those environments.

Audit existing agent authorisations. Identify which agents have access to sensitive application categories — email, HR systems, financial applications, code repositories. Revoke or scope-limit access where the business case is unclear.

Implement agent creation governance. Require approval before agents can be created with access to sensitive applications. The approval flow doesn’t need to be onerous — but it needs to exist. Currently, most organisations have no control gate at all.

Work with vendors on agent-level audit logging. Push OpenAI and equivalent vendors for logs that attribute application access to the specific agent, not just the user account. Without this, detection of rogue agent behaviour is not feasible.

Add AI agent authorisation scope to your access review cycles. Quarterly access reviews should include AI agent authorisations, not just user and service account access. An agent authorised to read an executive’s email is a privileged access grant that should be treated as such.

Include agentic AI in your threat model. When evaluating new agentic AI deployments — ChatGPT Workspace, Microsoft 365 Copilot agents, Salesforce Agentforce, and equivalents — the relevant security questions are: what can an agent authorised in this platform do, what would a rogue or compromised agent look like, and how would you detect it?

The Broader Pattern

AgentForger is one instance of a vulnerability class, not an isolated flaw. The same pattern applies to Microsoft 365 Copilot agents, Salesforce Agentforce, Google Workspace AI features, and any enterprise AI platform where agents are granted persistent access to business applications.

The velocity at which enterprise AI agent capabilities are being deployed outpaces the security governance frameworks organisations apply to equivalent non-AI access grants. The gap between deployment and governance is where the next AgentForger-class attack will operate — likely without an identifiable CVE, exploiting not a software bug but an authorisation design that was never intended to withstand adversarial pressure.

The strategic position for CISOs: AI agent access is a new category of privileged access. Apply the same governance rigour you would to service accounts and API keys — because that is functionally what an AI agent is.

Sources