Check G22 · agent provenance family · severity CRITICAL · extension only · one of the 22 GitLab checks
The question this check asks: did an AI surface — a chat assistant or an MCP directory — lead you to this gitlab.com project? Not whether the project mentions AI. Whether the route you took to it went through one. On gitlab.com, today, the answer RepoGates gives is: not checked.
In July 2026 Island's security research named the technique AgentBaiting. Of the roughly 7,600 FakeGit repositories — every one of them on GitHub — over 800 posed as AI Skills or MCP servers, and the campaign seeded more than 600 listings into public MCP registries. No attacker ever had to send a link. When Island asked Claude Code, Gemini and ChatGPT for a capability, each assistant found a campaign repository through ordinary search, read the attacker's README as documentation, and handed over the install instructions. Gemini returned one of the fakes as its first recommendation; ChatGPT called the same repository the best place to start.
None of that has a gitlab.com twin. No typosquat, fake-maintainer or trojanised-release-asset campaign specific to gitlab.com appears in the 2024–2026 primary record, so there is no catch rate to publish here, and FakeGit's numbers are not GitLab's. But the route is host-blind: nothing in an assistant's search, or in a developer's trust in what it wrote, depends on which host the link names. A developer who would squint at a link in an e-mail will paste a command an assistant wrote for them, because the assistant's confidence reads as vetting. It is not vetting. An agent recommendation is, right now, the opposite of a trust signal, wherever it points.
This is also the one check that cannot run anywhere but the browser. The signal exists only at navigation time: which tab you came from, which tab opened this one. A backend never sees it, a command-line scanner is never invoked, and a package-registry monitor is watching the wrong thing. On gitlab.com that is exactly the difficulty: the extension's board is not on gitlab.com pages yet.
Two things have to be true before this check can run on a gitlab.com project, and neither is true today. The extension has to hold gitlab.com as a host and draw its board on the project page — a later, separate store release. And the download gate has to take the project's key from the URL you clicked, not the one the bytes arrive from: a release-asset link on gitlab.com is …/-/releases/<tag>/downloads/<path>, which answers a 302 to the link's own url — free text that may be off gitlab.com entirely — so the download the gate would hold arrives from an address that does not name the project. The archive from the project page's Code menu, …/-/archive/<ref>/<project>-<ref>.zip, answers directly; a raw file at …/-/raw/<ref>/<path> is served inline, so Save-Link-As is the download path there. Until that release ships, G22 is a no-input skip: listed on every gitlab.com verdict as not checked, and never counted as a pass.
When it runs, it scores as C22 does, from the same table. The extension holds permission for an enumerated list of eleven hosts: six AI chats (claude.ai, chatgpt.com, chat.openai.com, gemini.google.com, copilot.microsoft.com, perplexity.ai) and five MCP directories (lobehub.com, glama.ai, mcp.so, mcpmarket.com, smithery.ai). Arriving at a project from one of them — in the same tab, in a tab it opened, or by referrer — records that provenance for 30 minutes. Tab lineage is the primary signal because those surfaces commonly emit rel="noreferrer" links; the referrer is supplementary. If a download of that project starts inside the window, the verdict request carries prov=agent and the surface's hostname only. On a project that would otherwise be REVIEW, G22 is added as CRITICAL, costs 25 points and escalates the verdict to BLOCK — the default personal policy is warn_to_block; strict profiles use always_block. On a project that passes, it is recorded as an INFO line costing 5 points and the verdict stays PASS. The evidence note in the scoring table:
“C22: AgentBaiting channel; INFO row (recorded on PASS) costs a little, CRIT (escalated) a lot”
Measured on 19 September 2026 across the 100 most-starred gitlab.com projects, G22 was listed as not checked on all 100 and withheld nothing: 14 of them are PASS with that row in place, on the strength of the other 21. The GitHub control the same day, through the same engine, passed none of its 100 — the roster is strict on large, old, busy projects on either host, and that is the engine's doing, not GitLab's.
Every legitimate project an assistant recommends carries the provenance note, and assistants recommend legitimate projects far more often than not. That is the reason G22 never blocks on its own: a clean, established project you reached from ChatGPT stays PASS with a five-point information line, and the board tells you why the line is there. The escalation only bites when the project already has a problem — a fresh owner namespace, a binary release asset, an install script — and then the fact that an assistant sent you is the thing that tips a warning into a block.
A second case: you asked an assistant, then typed the project name into a new tab by hand. There is no lineage and no referrer, so G22 does not fire. The check sees navigation, not intent.
On gitlab.com there is a third, and it is the honest one: none, because the check does not run. A G22 row on a gitlab.com verdict reads not checked, and a PASS beside it is a PASS on the other 21 and nothing more.
It sees browser navigations from an enumerated list. A surface not on the list is invisible until an extension update adds it — the remote configuration can switch hosts within the list on and off, but cannot add one, by the store's own remote-code rule. It does not see what you asked, what the assistant said, or the page you were on; it sends a hostname. It does not read the project: a recommended project that trips nothing else is not blocked, because a recommendation is not evidence.
It does not see a human lure either. The one documented pattern on gitlab.com in 2024–2026 is not AgentBaiting: GitLab's threat intelligence banned 131 accounts in 2025 for North Korean malware distribution, an average of 11 a month, delivered by recruiter lures, and Microsoft's account of the same campaign has victims “instructed to clone and execute an NPM package hosted on popular code hosting platforms such as GitHub, GitLab, or Bitbucket”. A recruiter's chat is not an AI surface, and G22 would not see it on any host; the project's own shape — a young account, an editor task file, an install script — is what the other 21 checks are for.
And it does not see an agent that fetches code itself. RepoGates as a whole gates browser downloads only — it does not see git clone, package managers, curl, or fetches made by AI agents outside the browser. For that path the product offers an MCP server an agent can be told to call before it fetches — platform="gl" for a gitlab.com project — and an agent that never calls it is not stopped, and we do not say otherwise. On gitlab.com, until the board ships, the MCP server and the verdict API are where a project's verdict is served at all.
RepoGates runs the same 22 checks on a gitlab.com project that it runs on a GitHub repository, from gitlab.com's public API, under the key gl/{namespace…}/{project}. What that API withholds from an anonymous caller — fork status, a user namespace's account age, and OpenSSF Scorecard, which does not cover gitlab.com — is listed as not checked, never assumed. A self-managed GitLab is another hostname and is not assessed. The repository's code is not read on this tier: a PASS means the provenance and the declared execution surface are clean.
Without installing anything: when an assistant hands you a gitlab.com project, treat it as an unverified search result, not a referral. Open the owner's profile and read the Member since line — a group's creation date is also answered by the API anonymously, a user namespace's is not, it needs a token, and RepoGates lists G1 as not checked on those rather than guess. Open the registry listing, if there is one, and read its age. Then verify the publisher out of band — a project website, a package on a registry you already trust, a named person with a history. From a terminal, the fields that matter most, with the project path URL-encoded:
P='NAMESPACE%2FPROJECT'
curl -s "https://gitlab.com/api/v4/projects/$P" | jq '{created_at, star_count, namespace: .namespace.full_path, kind: .namespace.kind}'
curl -s "https://gitlab.com/api/v4/groups/TOPGROUP" | jq .created_atA project and an owner created the same month, recommended by an assistant, with install instructions that download an archive: that is the AgentBaiting shape end to end, and it does not change shape for the host. The vetting standard's rule is blunt — agent-discovered repositories get the full treatment and out-of-band publisher verification, no exceptions.
Does an AI recommendation mean the project is malicious? No. Assistants recommend legitimate projects all day. That is why G22 changes nothing on a project that passes every other check: it is recorded as an information line costing 5 points. It only escalates — a warning becomes a block, 25 points — when the project already has a problem. Provenance is suspicion, not evidence. And on gitlab.com, today, it is neither: the check is listed as not checked until the board ships there.
Does RepoGates see what I asked the assistant? No. The extension watches navigation on an enumerated list of eleven hosts only and sends the hostname of the surface — claude.ai, for example — with the verdict request. Never the page URL, never the conversation, never the prompt. On gitlab.com it does not yet watch the project page at all.
Does RepoGates stop an AI agent from fetching code itself? No. G22 sees a person who followed a recommendation into a browser download. An agent that clones or fetches on its own is outside the browser, and RepoGates does not see git clone, package managers, curl, or agent fetches. The MCP server is a tool an agent can be told to call before it fetches — platform="gl" for a gitlab.com project — and an agent that never calls it is not stopped.
C22 AI-agent provenance — the GitHub original · G1 Owner account age — the finding that most often turns an agent-surfaced REVIEW into a BLOCK, read for a group, not checked for a user namespace · G18 Agent config files — instruction files the agent will read before you do · G20 MCP shell-launch config — a checked-in MCP configuration whose command runs something.
Add RepoGates to Chrome Pricing
Numbers on this page: Island, AgentBaiting, 20 July 2026 (800+ Skill and MCP imposters, 600+ registry listings, assistant behaviour — all GitHub repositories); GitLab Threat Intelligence, 19 February 2026 (131 accounts); Microsoft Security, 11 March 2026 (the lure quoted); the 100 most-starred gitlab.com projects and GitHub's 100 most-starred as a control, both measured 19 September 2026. The mechanism is described in the agents guide; weights from the product's scoring table.