One crafted URL stood up an attacker-controlled AI agent inside the org. No stolen credential, no malware.
The reflex when a rogue AI agent turns up is to ask who provisioned it. AgentForger is the case where nobody intentionally provisioned it—the agent was forged inside a real employee's authenticated session.
What AgentForger actually did
Zenity Labs found and named the flaw; researcher Mike Takahashi is credited. It sat in the Agent Builder behind ChatGPT Workspace Agents, which took initialization state straight from URL parameters—template_name and initial_assistant_prompt—and auto-submitted the embedded prompt inside the victim's authenticated session. No click-to-confirm, no OAuth consent dialog.
One link did all of this in a single shot: create an agent from the chief-of-staff template—a more capable one than the defaults; attach every connector the victim had already authorized; flip every connector's approvals from "Always ask" to "Never ask"; publish it live; and stagger schedules so it effectively ran every five minutes.
Command and control ran through the victim's own inbox: the agent polled Outlook for attacker mail with TASK in the subject, ran the instructions through the connected apps, and mailed results back. Preview mode wasn't a dry run either—it executed against the live connected accounts.
Disclosure was responsible and the fix was fast: reported via Bugcrowd on June 4 and fixed four days later by removing the parameter. None of the linked coverage reports a published CVE, and none reports exploitation in the wild.
Why the usual defenses missed it
Identity didn't fail; it worked as designed. The agent held a real employee's authorized connectors, so everything it did was legitimately attributed. OAuth consent was granted once at connector creation and never re-verified per action. And per Zenity's own analysis, the victim gets no indication anything is happening at all.
Zenity Labs' follow-up write-up mapped the blast radius: org-chart recon across mail, Slack, Teams and Drive; M&A documents and vendor-payment data pulled across connectors; authentication material searched out of Slack; and impersonation of the victim to push a wire-transfer request, tested with a $242,500 lure in a hypothetical scenario.
Note what "Never ask" means structurally: approval was a setting inside the surface the agent controlled, so the thing being governed could switch off its own governor.
Where this stops being a ChatGPT story
AgentForger is a SaaS-connector attack; Alpacon governs execution on infrastructure, so it was not in this path and would not have stopped it.
The pattern transfers. Swap the agent holding Outlook and Drive for one holding production shell access, and every step still works: legitimate identity, inherited authorization, approvals set wherever the agent was configured, and an audit trail nobody reads until there's an investigation. Whether that substitution already holds in your estate is the question worth asking, and most teams cannot answer it: CSA and Token Security found 82% of enterprises have AI agents—of any kind—they don't know about, and 65% had an AI-agent incident in the past year.
What changes when approval doesn't live where the agent runs
Three properties do that work for any agent running inside a Work Session, and none of them are settings an agent can reach:
→ An agent can't admit itself. Agent-mode session admission always routes to a human approval request, even when the requester is a superuser—auto-approval is allowlisted to human requesters only. An agent standing itself up is exactly what that allowlist forbids.
→ Approval is designed to be redeemed out of band. Requests go out over web, and the channel that made the request is barred from redeeming it. That separation keeps self-approval attempts visible to human approvers in a separate channel.
→ Widening the scope isn't the session's call. A session declares its intent and carries a scope ceiling; adding servers, widening scopes, or expanding sudo policy all route into the approval queue rather than resolving inside the session. The forged agent's power came from aggregating everything at once—all connectors, all approvals off, live. A scoped session is the opposite shape.
Underneath all three sits the gate that makes them enforceable: every privileged action a Work Session carries is checked against the session's declared scope ceiling and a risk verdict before it runs, not just against who is asking.
Three limits. Signed-command enforcement is still rolling out: it ships in monitor mode by default, so not every deployment blocks a high-risk command today. Tying an action back to the human who delegated it is planned, not shipped. And these three properties bind a Work Session specifically—a bare service or API token acting outside a session is judged and audited but not held, and closing its standing privilege is planned work, not shipped.
What is shipped is the record: session history, commands, file transfers, approval history, and terminal recording on interactive sessions. An agent nobody can see, stop, or audit isn't only a security problem—where the system is high-risk under the EU AI Act, it's Art. 14 (human oversight, including the ability to stop) and Art. 12 (record-keeping), plus a SOC 2 evidence gap either way.
The takeaway
Identity was never broken here; it was borrowed. Which leaves the gate in front of what the agent executes, sitting somewhere the agent can't configure. So ask it of your own estate: could an agent change any property of its own authorization—what it can reach, what it can run, how long it holds it? Anything but a flat no is the gap.
