The leak is in the connector setup, not the model

A file, not a model

That shape - a personal access token typed straight into an env block in mcp.json - is the official-looking way most quickstarts tell you to wire a connector. It works. It also means the token now lives on disk in plaintext, in a file that's often gitignored and never reviewed by anyone.

The numbers

GitGuardian's 2026 State of Secrets Sprawl report found 24,008 unique secrets in public MCP-related configuration files on GitHub, 2,117 of them unique and valid - 8.8% of the total. Token Security, drawing on their own customers' data (13 May 2026), found that 20% of endpoints with Claude Code or Cursor installed have hardcoded secrets written into MCP config files.

Neither number is about careless developers. It's about a setup pattern that official documentation keeps teaching.

Why git scanners miss it

A git secret scanner watches commits and repository history. mcp.json, settings.json, and settings.local.json are workstation config, frequently gitignored on purpose, and often never pushed anywhere. The secret is local, valid, and outside the one control most teams already run.

The same anti-pattern, a new surface

Grok Bot's own help documentation says to use the secure secret card, not to paste secrets into chat or ordinary files. Its catalog GitHub connector is still a GITHUB_PERSONAL_ACCESS_TOKEN setup field. The connector install disagrees with the product's own guidance, the same way an MCP quickstart disagrees with the advice to keep secrets out of config. It's not a session-forensics story - it's a config-time one, and it's the same pattern skarn vet already catches in a Cursor or Claude Code MCP file.

What skarn vet does

skarn vet statically checks the local AI assistant configuration - hook commands, MCP server definitions, permission grants, and installed plugins and skills - across Claude Code, Codex CLI, Cursor, GitHub Copilot, Gemini CLI, Grok Build, Grok Bot, and Microsoft Scout. Read-only, offline, and no license required.

It reports patterns including:

• MCP endpoints pointed at remote hosts, and launchers with no pinned version or digest
• Permission grants that approve a whole class of actions, or let the assistant widen its own authority
• Hooks that exfiltrate local content or fetch and execute remote code
• A plaintext credential store whose file permissions grant group or other read access

That last one already has a named check for Grok Bot specifically: vet-config-credential-world-readable flags a world-readable token file by permission metadata alone, never by reading its contents. A second check, vet-grokbot-localexec-channel, flags Grok Bot's standing local-exec and egress posture from declared configuration flags, not from watching live traffic.

Run it, and a finding for that first check reads like this, naming the path and the mode and nothing from inside the file (observed on Grok Bot 0.29.0, 2026-08-28):

vet doesn't rewrite the file, rotate anything, or fix the permission. By default it also doesn't fail a build - it exits 0 unless you set --fail-on-severity or --fail-on-scan-error, so wiring it into CI is a deliberate choice, not something that happens by accident.

What good looks like

An environment-variable reference instead of an inline token. A GitHub App or OAuth flow instead of a personal access token - GitHub's own guidance prefers Apps over PATs for exactly this kind of long-lived integration. The secret card, where the product offers one, instead of a paste into chat.

skarn vet doesn't replace GitGuardian, Nightfall, or a secrets manager - they own the git history and the SaaS-config path. vet is the workstation MCP and hook-config file, checked locally before the next connector gets wired up.