A Phishing Link Built a Rogue Agent. Detect the Birth, Not Just the Run.

Zenity Labs publicly disclosed AgentForger on 23 July 2026. Its researchers said a crafted ChatGPT link could drive the Workspace Agents builder inside a victim's authenticated session, create an agent, attach previously authorised connectors, change an approval setting, publish the agent, schedule it and invoke an immediate run (Zenity Labs).

This is not a warning that the reported flaw remains open. Zenity says it reported the issue through Bugcrowd on 4 June, OpenAI accepted it on 5 June and fixed it on 8 June (Zenity Labs). Zenity's disclosure does not cite a CVE, so the technical account and remediation timeline remain attributed to the researcher. Agent-building tools have carried a real CVE before; this one stopped short of a formal identifier.

The durable lesson is not "watch for bad prompts". It is that agent creation and security configuration are control-plane events. If your monitoring starts when an agent runs, you may have missed the creation, connector attachment, approval change, publication and schedule that made the run possible. It is the same shift in perspective the OWASP agentic Top 10 asks for: treat the agent as a privileged user, not a chat feature.

What did AgentForger actually prove?

Zenity's proof of concept had specific prerequisites. The victim had to be signed in to ChatGPT, have access to Workspace Agents, have at least one connector authorised from earlier legitimate use, and click the crafted link. Because the connector already existed, Zenity said its test did not trigger a new OAuth consent screen (Zenity Labs).

The researchers found that attacker-controlled initialisation content in the URL was submitted to the builder. In their pre-fix test, that content drove a sequence that created and named an agent, attached existing connectors, changed a write-action approval, published the agent, installed recurring schedules and ran Preview (Zenity Labs). This article deliberately omits the vulnerable parameter and payload.

Zenity's second report showed proof-of-concept scenarios involving organisational reconnaissance, cross-connector searches, credential discovery, internal phishing and a business-email-compromise lure. Those were researcher demonstrations, not reported customer incidents, confirmed fraud losses or evidence that an Australian financial institution was affected (Zenity Labs).

Zenity separately says there is no evidence that AgentForger was exploited in the wild (Zenity). Keep the attribution attached. An absence reported by the researcher is not proof that no unknown exploitation occurred.

Current OpenAI documentation confirms the relevant platform concepts, not Zenity's full technical account. Workspace Agents can be created, tested and published, connected to apps and tools, run on schedules or triggered by an API. Apps can use an end-user account or an agent-owned account. Supported write actions default to "Always ask", while some apps also permit "Never ask" or custom approval settings (OpenAI Help Centre).

OpenAI now says Workspace Agents are off by default at launch for Enterprise workspaces and documents separate role controls for agent use, building and publishing (OpenAI Help Centre). Those controls matter. They do not remove the need to reconcile what exists in the tenant with what the organisation approved.

Why are ordinary run logs too late?

Separate the control plane from the run plane.

The control plane records who created or changed the agent, which version was published, which connectors and authentication types were attached, what write approvals and action constraints applied, who could access it, and which schedules or triggers were created. The run plane records prompts, messages, tool calls, outputs and actions after execution begins.

Both matter, but a rogue agent can look superficially legitimate on the run plane. It may operate through an existing employee connection and invoke actions the connection is allowed to perform. An identity alert may show the expected user. A mail log may show an authenticated account. The unexplained agent and its configuration history are the missing context.

OpenAI's Workspace Agents Security Overview, dated 29 April 2026, says Enterprise and Edu customers can obtain agent configuration, change audit logs and run traces. It lists agent lifecycle events, run events, trigger changes, connector calls, connector OAuth resolution, skill events and memory events. It describes export through the Compliance Logs Platform with minutes-level target latency, not guaranteed instant prevention (OpenAI security overview). That memory events appear in the taxonomy is its own reminder that agent memory is a governed data asset, not a convenience feature.

OpenAI's Compliance Platform is available to Enterprise and Edu customers and provides immutable, append-only compliance events. OpenAI says its log platform retains data for 30 days and customers wanting longer retention should continuously export it under their own policies (OpenAI Help Centre).

That 30-day window creates an immediate operational question. Can your organisation retrieve the control-plane evidence when an investigation starts later? Validate your plan, live event schema, export health and source-system retention. Do not assume a product brochure proves your tenant is collecting every field.

Which lifecycle sequence should trigger an alert?

Start with an Agent Birth Certificate. Every approved agent, including a private agent with meaningful access, receives a record before it is allowed to operate.

This is an internal governance record, not a cryptographic identity credential or a substitute for platform access controls.

The certificate should contain:

1. Internal certificate ID, stable vendor agent ID, accountable owner and authorised builders.
2. Approved business purpose, use-case record and expiry date.
3. Creation channel, draft version and published version.
4. Instruction and configuration hash.
5. Connector IDs, authentication mode and permitted actions.
6. Write-approval settings and connector action constraints.
7. Publication audience, schedules and API triggers.
8. Approved rollback version and suspension owner.
9. Evidence location, monitoring owner and recertification date.

Reconcile those certificates against the live agent set. An active agent without a certificate is not automatically malicious, but it is not ready to be trusted. A human owner must investigate the difference.

Then build an agent lifecycle tripwire. Correlate this high-signal sequence:

agent created, existing connector resolved, write approval relaxed, agent published, recurring trigger created, run started, external outbound action observed

Any one event can be legitimate. The linked sequence is the signal. It should create a human-reviewed alert, not declare the employee compromised or disable production automatically.

Use this prompt to design the event map from actual vendor documentation. A security engineer must verify every field and join key against the live non-production tenant before a rule is deployed.

Using only [VENDOR_EVENT_DICTIONARY], map these control-plane events:
agent create; edit; publish; unpublish; connector add; authentication resolution; write-approval change; constraint change; schedule create; run start; connector call; external outbound action.

Return:
- required evidence field
- available vendor field
- source event
- join key
- retention
- proposed human-review condition
- evidence gap

Do not infer missing telemetry. Mark it NOT AVAILABLE and suggest a source-system log that may close the gap. Do not create a production rule.

Fictional worked example: [BANKNAME] has [APPROVEDAGENTCOUNT] agents in its approved register. A daily reconciliation finds [AGENTID] in the live export but no matching certificate.

The event chain shows [USERID] as owner, [CONNECTORID] resolved through an existing end-user connection, a write approval changed, the agent was published, [SCHEDULECOUNT] recurring triggers appeared and an outbound connector action went to [EXTERNALDOMAIN]. Each event could be permitted alone. Together they cross the tripwire.

[HUMANINCIDENTLEAD] verifies the raw events, preserves source-system evidence, stops further runs through the authorised administrative process, reviews the connected account and assesses affected information. The alert does not determine compromise, customer impact or regulatory notification.

Use this prompt to reconcile a redacted live inventory. An agent owner and human incident lead must verify every finding and decide any containment.

Compare [APPROVED_AGENT_REGISTER], [LIVE_AGENT_EXPORT] and [RECENT_LIFECYCLE_EVENTS].

Flag only:
1. live agents absent from the register
2. owner, connector or authentication changes
3. relaxed write approvals
4. new or unusually frequent schedules
5. external outbound actions after a configuration change
6. agents without an accountable owner

Use identifiers, not personal data. Show supporting event IDs and state what cannot be proven. Do not disable, accuse or notify anyone.

Joint Five Eyes guidance on agentic AI, published by ASD's ACSC with its US, UK, Canadian and New Zealand partners, recommends maintaining a trusted agent registry, reconciling it against the live agent set, limiting permissions, monitoring operations and testing incident response (ASD's ACSC). This is the same operating direction: inventory first, then correlate identity, privilege and action.

For APRA-regulated organisations, lifecycle telemetry can support CPS 234 controls for changing threats, information assets, detection, response and systematic testing. It does not establish compliance by itself (APRA CPS 234). Security teams still need to join agent events with identity, email, file, data-loss prevention and other source-system evidence.

Do this Monday

1. Reconcile the tenant. Export the current agent inventory and compare it with approved use cases, owners, connectors, versions, publication scope, schedules and expiry dates.
2. Reduce creation authority. Review who can build and publish agents, especially with end-user or agent-owned connections. Separate ordinary use from building and publishing where the platform permits it.
3. Inspect approvals and triggers. Find relaxed write approvals, missing action constraints, newly attached connectors and recurring schedules. Send unexplained changes to human owners.
4. Export the evidence. Confirm Compliance Platform eligibility, event coverage, minutes-level latency, deduplication and the 30-day source retention. Test the export into the approved security store.
5. Exercise containment. In a controlled workspace, practise suspending an agent, stopping its triggers, preserving events, reviewing connections and restoring a known approved state. Keep incident, customer-impact and notification decisions with authorised people.

Zenity says OpenAI removed the reported entry path before public disclosure (Zenity newsroom). These steps address the broader possibility of an unapproved agent or configuration reaching the run plane through another path.

Bottom line

Zenity describes AgentForger as a fixed, researcher-reported flaw, not evidence of a current breach. Its useful warning is that an agent's creation and configuration are security events. Give every approved agent a birth certificate, reconcile it with the live tenant and correlate the sequence from creation to outbound action. A human incident owner should decide what the sequence means and what happens next.

This article is general information and education only. It is not legal, compliance, financial or professional advice. Obligations vary by organisation and circumstance. Verify current requirements against the primary sources cited and seek advice specific to your situation.

References

1. Zenity Labs, "AgentForger, Part 1: ChatGPT Cross-Site Agent Forgery": https://labs.zenity.io/p/agentforger-part-1-chatgpt-cross-site-agent-forgery
2. Zenity Labs, "AgentForger, Part 2: The Autonomous Insider": https://labs.zenity.io/p/agentforger-part-2-the-autonomous-insider
3. Zenity, "AgentForger: Why AI Agent Security Needs More Than a Patch": https://zenity.io/blog/product/chatgpt-agentforger
4. OpenAI Help Centre, "ChatGPT Workspace Agents for Enterprise and Business": https://help.openai.com/en/articles/20001143
5. OpenAI, "Workspace Agents Security Overview": https://cdn.openai.com/business-guides-and-resources/workspace-agents-security-overview.pdf
6. OpenAI Help Centre, "OpenAI Compliance Platform for Enterprise and Edu Customers": https://help.openai.com/en/articles/9261474-openai-compliance-platform-for-enterprise-customers/
7. Australian Signals Directorate's Australian Cyber Security Centre, "Careful adoption of agentic AI services": https://www.cyber.gov.au/business-government/secure-design/artificial-intelligence/careful-adoption-of-agentic-ai-services
8. APRA, "Prudential Standard CPS 234 Information Security": https://www.apra.gov.au/standards/cps-234
9. Zenity, "Zenity Labs Uncovers AgentForger, a ChatGPT Vulnerability": https://zenity.io/company-overview/newsroom/company-news/zenity-labs-uncovers-agentforger-a-chatgpt-vulnerability