In May 2026 a developer posted a small, unsettling screenshot to r/OpenAI: the first thing they saw when they Googled "OpenAI Codex app" was a fake malware website, ranked right at the top. It got hundreds of upvotes because everyone recognized the trap. We have trained an entire workforce to find AI tools by searching for them, and attackers have noticed.
The uncomfortable truth is that search ranking, app-store placement, and a slick landing page prove nothing about whether a tool is real. For a small team with no security staff, the person installing the tool is also the person who has to catch the fake, and right now most have no method for doing that.
TL;DR: Attackers now register fake sites and lookalike packages for popular AI tools, and these sometimes outrank the real product in search and app stores. One viral example, the top result for "OpenAI Codex app" was a malware site. Before your team installs any AI tool, run a 7-step check: confirm the official domain, verify the publisher, check the real package name and download counts, watch for typosquats, require company-managed installs, and route new tools through one approval step.
Why AI tools are a prime target for fakes
Three things make AI tools unusually easy to impersonate right now.
They are searched constantly. AI tools are some of the most-googled software in the world in 2026, and high search volume is exactly what makes a fake worth building. Register a lookalike, buy an ad, and you sit above the real product for people who do not know its exact URL.
They change fast. New tools, new CLIs, new SDKs launch weekly, so users have no settled muscle memory for "the real one looks like this." When a tool is three weeks old, a convincing clone is hard to distinguish from the original.
They are installed everywhere. AI now arrives as web apps, desktop installers, browser extensions, IDE plugins, and packages on npm and PyPI. Each of those is a distribution channel an attacker can poison, and developers install from several of them every day, often on machines with access to source code and production credentials.
The result is a supply-chain problem that starts before installation. You can have a perfect vendor security review of the real tool and still get compromised because someone installed a lookalike of it. That is why vetting has to happen at the moment of download, by whoever is doing the downloading.
The 7-step AI tool vetting check
Run this before installing any AI tool that is new to your team. It takes a few minutes and catches the overwhelming majority of fakes.
-
Get the official URL from the vendor, not from search. Find the real domain through the company's verified social account, official documentation, or a known-good link, then go there directly. Never trust the first search result or an ad as proof of legitimacy.
-
Verify the publisher, not just the name. On app stores, package registries, and extension marketplaces, check the publisher or author identity. A real popular tool is published by a verified, recognizable account. An unknown publisher with a familiar tool name is the classic fake.
-
Check the real package name and stats. For npm, PyPI, or extension stores, confirm the exact package name from the vendor's docs, then look at download counts, version history, and publish date. A genuinely popular AI tool has high, consistent download numbers and a real release history; a brand-new package with a popular name and few downloads is a red flag.
-
Watch for typosquats and lookalikes. Compare the domain and package name character by character against the official one. Look for misspellings, extra words, swapped letters, alternate top-level domains, and hyphenated variants. These are the entire mechanism of the attack.
-
Treat extensions and plugins as high-risk. Browser extensions and IDE plugins run with broad access to your sessions and code. Install only the one linked directly from the vendor's official site, and check its publisher, install count, and recent reviews before granting permissions.
-
Install through company-managed accounts. Personal accounts and side-loaded installers are where fakes slip in. Where possible, require company-managed app installs, managed browser profiles, and approved package sources, so a random download is not one click away from production.
-
Route it through one approval step. Before a new AI tool is adopted, one person confirms the source, the publisher, and what data the tool will touch, then records it in your tool register. The register is what lets the next employee confirm what is sanctioned instead of searching and guessing.
What a fake looks like versus the real thing
| Signal | Real tool | Likely fake |
|---|---|---|
| How you found it | Vendor's official site or docs | Top search result or an ad |
| Publisher | Verified, recognizable account | Unknown or recently created |
| Package downloads | High and consistent over time | Few, despite a popular name |
| Domain / name | Exact match to official | Misspelled, extra word, odd TLD |
| Release history | Long, regular versions | Single recent version |
| Permissions requested | Scoped to the tool's purpose | Broad, unexplained access |
No single row is proof on its own. A fake usually trips several at once: you found it through an ad, the publisher is unknown, the package is days old with a handful of downloads, and the name is one letter off. When two or three of these line up, stop and find the real source.
Where the fakes actually hide
The screenshot that went viral was a search result, but search is only one of five channels, and the others are easier to miss.
Search ads and results are the obvious one: a sponsored link or a high organic ranking that points to a lookalike domain. App and extension stores are worse, because the store's presence feels like a vetting step it is not, and stores are full of clones of popular AI assistants with names one word off from the real one. Package registries like npm and PyPI are the highest-stakes channel, since a malicious package named like a real AI SDK installs straight onto a developer machine with a single command. GitHub repositories that promise "free" or "unlocked" versions of paid AI tools are a classic lure, often shipping a poisoned installer. And direct messages or community posts sharing a "new AI tool you have to try" move fast in exactly the channels where AI tools spread.
The common thread is that none of these channels verify identity for you. A store listing, a high search rank, a GitHub star count, and a confident Discord recommendation are all forgeable. The only reliable anchor is the vendor's own official source, which is why every step of the check above routes back to it.
If someone already installed a fake
Assume it will happen eventually, and decide the response before it does. Speed matters more than blame.
If you suspect a fake or malicious AI tool was installed, treat it as a credential compromise, because that is usually the goal. Disconnect the affected machine from anything sensitive, then rotate every credential that machine could reach: API keys, tokens, SSH keys, and any saved passwords or sessions in the browser. Infostealers harvest exactly these. Check for unexpected outbound activity and review recent account logins for the services that machine touched. Remove the tool, and if it was a package, audit your lockfile and CI for the malicious version so a teammate does not reinstall it. Finally, tell the team what the fake looked like, the lookalike name or domain, so the same trick does not work twice.
The reason to write this down in advance is that the first hour decides the damage. A team that knows to rotate credentials immediately turns a scary incident into a contained one. A team improvising during the incident loses the time that matters most. This is the same response loop covered in the AI vendor security incident guide, applied to a tool you installed rather than a vendor you bought from.
Copy-paste AI tool vetting rule
Add this to your acceptable use or shadow AI policy. Adapt the bracketed fields.
[Company Name] AI Tool Vetting Rule
Source. New AI tools are obtained only from the vendor's official site or an approved registry, never from a search result or ad. The official source is confirmed before installation.
Publisher and package. The publisher identity and exact package or app name are verified against the vendor's documentation, including download counts and release history.
High-risk installs. Browser extensions, IDE plugins, and desktop installers require publisher verification and are installed through company-managed accounts where available.
Approval and register. No new AI tool is adopted without [role] confirming source, publisher, and data access. Approved tools are recorded in the [AI tool register] so employees can check what is sanctioned.
Keep it alongside your shadow AI governance process, since the same approved-tool register that fights shadow AI is what stops people from searching and installing a fake in the first place.
Checklist (copy/paste)
- Official tool URLs sourced from the vendor, not from search
- Publisher identity verified on every store and registry
- Exact package names confirmed against vendor docs
- Download counts and release history checked for new installs
- Domains and package names compared for typosquats
- Extensions and IDE plugins treated as high-risk
- Company-managed accounts required for installs where possible
- One approval step before adoption; tool added to the register
Where this fits in your governance
Vetting at download time is the front door of AI supply-chain security. It pairs with the AI vendor due diligence checklist, which reviews the real vendor once you know you have the real tool, and with embedded AI governance for third-party tools, which handles AI features hidden inside software you already use. The single highest-leverage control is the most boring one: a maintained AI tool register that lets people confirm what is approved, so the answer to "is this the real one?" is a lookup, not a guess.
