The trust board

The badge, board and feed on GitHub, Hugging Face and GitLab pages

On github.com, huggingface.co and gitlab.com the extension can draw three things — all display, none of them enforcement, each with its own toggle (Options → Trust board); the Hugging Face and GitLab pages reach users with the next store release:

• Trust badge — the 0–100 score beside the repository name, computed from the same 22 checks the gate enforces. The same badge appears on owner profiles for the account's repositories.
• Quick-stats board — under the page header: stars, owner age, contributors, licence, Scorecard, release downloads, and the findings behind the score, with honest "—" for anything unknown (unknown is never rendered as zero).
• Live security feed — a banner of active supply-chain campaigns and newly exploited CVEs across GitHub, Hugging Face, VS Code Marketplace, Docker Desktop, GitLab and agent skills, refreshed every 30 minutes; a platform with no active campaign is stated as quiet, never filled. The same data the active_campaigns tool returns. The ticker names every platform RepoGates watches; the board itself runs on github.com pages. VS Code Marketplace extensions, Docker Desktop extensions and agent skills are assessed through the MCP server and the Claude Code plugin, not in the browser.

The board is fed by the verdict the background already fetched to pre-warm the gate, so it costs no extra GitHub API calls — and if GitHub changes its page markup, a server-side kill-switch hides the overlay rather than rendering it broken. Enforcement is unaffected either way.

The repository checker

On your account page: paste owner/repo or a GitHub URL and click Check. You get the same verdict the extension would enforce — badge, findings sorted by severity, when it was scanned, whether it came from cache, and the raw response if you want it. A new repository spends one of your 10 free checks; a repository you already checked is free to check again.

AgentBaiting — C22

C22 is the one check that cannot run on any backend, because the signal only exists in the browser at navigation time: did an AI surface lead this person to this repository? Attackers seed AI-recommendable fakes precisely because an assistant's recommendation reads as a trust signal. It is not one.

How the extension sees it, and everything it sends:

• It watches navigation on an enumerated list of surfaces only — AI chats (claude.ai, chatgpt.com, chat.openai.com, gemini.google.com, copilot.microsoft.com, perplexity.ai) and MCP directories (lobehub.com, glama.ai, mcp.so, mcpmarket.com, smithery.ai). It holds no permission to see any other site, and deliberately requests neither tabs nor webNavigation.
• Arriving at a GitHub repository from one of those surfaces — same tab, a new tab it opened, or via referrer — records that provenance for 30 minutes.
• If a download of that repository then starts, the verdict request carries prov=agent and the surface's hostname only — never the page URL, never the conversation.
• Policy then escalates: by default a warn-grade verdict becomes a block when the repository was agent-surfaced (warn_to_block; strict profiles use always_block), and the decision page says plainly that an AI surface led you there.

The check has its own page — C22, AI-agent provenance — with the scoring, the false positives and the limits; the technique it answers is described at AgentBaiting.

C22 and the MCP server are the two halves of the agent problem: C22 covers the human who follows an agent's recommendation into a browser download; the MCP tools cover the agent that fetches code itself — when it asks. Neither half claims the other.