AI
One ChatGPT Link Could Have Forged an AI Insider at Work
Zenity Labs showed that one tampered ChatGPT link could build and schedule an attacker-controlled workspace agent. OpenAI patched it in June, but the governance gap it exposed is still open.

Picture an employee opening a link that appears to have been shared from ChatGPT by a colleague. Nothing about it looks unusual, and nothing visibly happens when they click. In the proof-of-concept that Zenity Labs published on July 23, that single click was enough to create, configure, publish and schedule an attacker-controlled agent inside the victim's ChatGPT workspace.
Zenity codenamed the vulnerability AgentForger. OpenAI fixed it on June 8, after responsible disclosure, so this is not a live threat to anyone's workspace today. It is still one of the more instructive AI security findings of the year, because of what the forged agent could reach once it existed.
How the attack worked
The flaw was in the agent Builder tool, which accepted an initialization state through URL parameters. Two of those parameters carried an agent template and the prompt handed to the Builder. Crafting a link with the right parameters meant an attacker could specify what the agent would be, what it would be allowed to do, and what it would be told, then have the victim's own click authorize it.
From there the chain ran through the victim's existing app permissions, disabled security controls, and set the attacker's instructions to run on a schedule. Zenity's proof-of-concept had the agent pulling fresh instructions every five minutes, which turns a one-time phishing click into a persistent channel.
What the proof-of-concept agent could reach
The scenarios Zenity demonstrated are worth reading as a list of what a workspace agent has access to by default:
- Mapping an organisation's people and projects by trawling Outlook, Slack, Teams, calendars and file stores
- Hunting for passwords and API keys sitting in old chat messages
- Sending convincing phishing messages from the victim's own Teams account
None of that required a new exploit at each step. The agent simply used the permissions the employee already had, which is exactly the point.
Already patched, still instructive
The specific bug is closed, and OpenAI handled the disclosure properly. What does not get patched is the underlying shape of the problem: an AI agent is a piece of software that inherits a human's access, runs on a schedule, and can be configured by anyone who controls its instructions. Every one of those properties is a feature. Together they describe an insider.
Traditional phishing gets a set of credentials, and defenders have twenty years of tooling built around detecting what happens next. Agent forgery gets something closer to an employee: something that acts continuously, blends into normal automation traffic, and does not trip the alarms that watch for unusual human logins.
Questions worth asking about your own setup
If your organisation has started deploying workspace agents, the useful takeaway is not "patch this bug" but a short list of questions most teams cannot yet answer:
- Who in your organisation is allowed to create an agent, and does anyone review what gets created?
- Which connectors do your agents hold, and does anyone audit that list on a schedule?
- Would a scheduled agent quietly reading your file store for months show up in any log you actually watch?
- When an employee leaves, do the agents they built get deprovisioned along with their account?
Most companies we talk to have solid answers for user accounts and no answers at all for agents. That gap is the real finding here, and it does not close with a vendor patch.
Sources: Zenity Labs, The Hacker News, The Register, SecurityWeek

Written by
Faruk Talmaç
Co-Founder & Editor
Co-founder of YZ Uzman, with 20+ years of experience in web design and software development.