in this guide
At Black Hat in August 2026, researchers from Zenity showed a demo that started with “summarize this email” and ended with the victim’s Gmail exfiltrated, their Drive shared out, and their Slack account taken over.
Zero clicks. The email did the work. Zenity named five affected AI browsers: Claude in Chrome, Gemini in Chrome, Perplexity Comet, ChatGPT Atlas and Copilot in Edge. It calls the vulnerability class PleaseFix.
The same week, the same team documented a campaign of malicious agent “skills” distributed through Vercel’s skills.sh registry, at over 1.7 million aggregate installs by Zenity’s count, quietly turning agents into credential thieves.
A few days earlier, at the end of July, “Sign in with ChatGPT” went into beta, with Airtable, GitLab, HubSpot, Notion, Supabase and Vercel among the first partners, and OpenAI widened it at its developer conference in late September. OpenAI became a login button inside tools your company runs on.
Three stories, a few weeks apart. The coverage treated them as three separate product problems. They are one problem at three layers, and it lands harder on companies like yours than on the enterprises the conference badges were written for.
the census everyone is running is the wrong census
Most companies are somewhere in the middle of the same exercise: counting AI tools. Which chatbots, which notetakers, which coding assistants. Someone owns a spreadsheet. The spreadsheet has a column for “approved”.
The count is honest work, and it measures the wrong thing. A tool is a name on an invoice. What matters is the doors: the places where software you did not hire can pick up access that was granted to a person.
That summer opened three kinds. Each one breaks a different assumption your current controls quietly depend on.
door one: the session
An AI browser is a browser. It sits inside the same profile where you are logged into Workspace, your CRM, your bank. When an agent in that browser acts, it acts with your cookies, your sessions, your logged-in everything.
Nobody granted the agent that access. There was no consent screen, no OAuth scope, no row in the admin console. The access was granted to the human, years ago, one login at a time. The agent inherits it by sitting where the human sits.
That is what made the Zenity demo work. The attacker never touched credentials. They put instructions where the agent would read them, an email, a calendar invite, a web page, and the agent carried them out with the session it inherited. The delivery mechanism is content, and you cannot stop an agent from reading content. Reading content is the product.
So the fix lives where it always lives: in what the session can reach when the instruction arrives. The agent guide makes the same point about agents in general.
door two: the plugin
A skill is a piece of third-party code you bolt onto an agent to make it better at something. Registries of them are growing fast, and installs are one click.
You have seen this before. It was called browser extensions, and the industry spent a decade learning that a marketplace of one-click add-ons running with the host’s permissions becomes a malware channel. The skills version is worse in one specific way: an extension could read your tabs, and a skill can read everything the agent can reach, which after door one is your logged-in everything.
The 1.7 million installs are Zenity’s number, from registry data, and Zenity sells agent security, so treat the magnitude with care. The mechanism needs no number. Unreviewed code, the agent’s permissions, one click.
door three: the login button
“Sign in with ChatGPT” is the quiet one, and probably the biggest.
An employee opens Notion or Airtable or HubSpot and signs in with their ChatGPT account. A personal account, most likely, because the button doesn’t ask. From that moment there is an identity active inside your stack that your identity provider does not know exists. It is not in Workspace. It never appears in your user list. It has no offboarding path, because the person who leaves takes the ChatGPT account with them, still bound to whatever it was bound to.
Your directory now has a competitor, and the competitor’s admin console is not yours.
To be fair to OpenAI, every platform that ever shipped a “Sign in with” button did this to somebody. Google did it to Microsoft shops for a decade. The difference is timing: this button arrived while the same vendor’s agents were learning to act inside those same tools, and while the admin controls for it were still catching up.
three doors, one summer
- the sessionan AI browser acts with every login the person already has
- the pluginunreviewed skills run with the agent's reach
- the login buttonan identity your directory never sees
- the AI tool listcounts names on invoices, sees none of the three
access that never passed through your admin console
what the summer is telling you
The doors ship before the locks, every time, and the gap is measured in quarters.
The browsers shipped before session isolation for agents existed. The registries shipped before skill review existed. The login button shipped before admin controls caught up. None of this is malice. It is the normal sequence of a platform race, and it means the controls a company your size actually gets, defaults, consoles, revoke buttons, arrive last, after the enterprise customers complain.
You do not have quarters, but you do have one advantage the enterprise doesn’t: your company is small enough to see. The census below takes about an hour.
the one-hour door census
Door one, the session. Ask in your all-hands channel who runs an AI browser or a browser agent. This is a survey, and there is no console alternative; these browsers do not report to your admin panel. You are not banning anything. You are finding out how many inherited sessions exist, and whether the people running them keep work and AI browsing in one profile. Separate profiles is the cheapest meaningful fix available.
Door two, the plugin. For whoever showed up in answer one: which skills, which extensions, from which registries. Then the general version in Workspace: Admin console, then Security, then Access and data control, then API controls, then Manage Third-Party App Access. Review what has been granted recently. Skills won’t all appear there, and that is itself worth knowing.
Door three, the login button. Open the admin panel of Notion, Airtable and HubSpot, whichever you run, and check which sign-in methods are permitted. If single sign-on is enforced, other sign-in methods should be blocked; Vercel, for one, says team requirements such as SSO still apply to the ChatGPT button. Test it with a non-admin account anyway. If you are on a plan without SSO enforcement, write down that the door is open, because that fact belongs in the next tooling-budget conversation.
One hour. Three lists. The count you end up with is your real AI census, and it will not match the spreadsheet with the “approved” column.
The tools were never the inventory. The doors are.
on the record
- Brewer v. Otter.ai, 2025"it's just a notetaker"
- MCP tool poisoning, 2025"a tool's description can't carry an attack"
sources
- Zenity Labs: the full scope of PleaseFix, zero-click attacks across agentic browsers (Business Wire, August 2026)
- Dark Reading: AI browsers and zero-click agent hijacking
- Zenity Labs: 1.7 million install malicious skills campaign (Business Wire, August 2026)
- OpenAI Help Center: Sign in with ChatGPT
- Supabase: Sign in with ChatGPT beta
- Vercel changelog: Sign in with ChatGPT is now available on Vercel (29 July 2026)
- Google Workspace Admin Help: control which third-party and internal apps access Workspace data
