GitHub adds dependency and secret scanning to its MCP server to prevent leaks

GitHub’s MCP server is turning into a security product, not just a connector. That’s the real news here. On May 5, GitHub made secret scanning generally available in its MCP server and added dependency vulnerability scanning in public preview, so AI coding agents can catch leaked credentials and risky packages before code gets committed. (github.blog) ### What changed this week? Two things landed at once. Secret scanning for the GitHub MCP server moved from public preview to general availability, and dependency scanning showed up as a new preview feature through the server’s Dependabot toolset. In plain English, your agent can now check for exposed tokens and vulnerable dependencies while it’s still helping you write code, not after the mess is already in the repo. (github.blog) ### Why does MCP matter here? MCP — Model Context Protocol — is the layer that lets tools like Copilot, Claude Code, Cursor, and Windsurf call outside services. That sounds boring, but it changes the attack surface. Once an assistant can open PRs, read files, query services, or hit databases, the connector stops being plumbing and starts b(github.blog) it bundles security toolsets, read-only modes, and OAuth-based access into the managed server. (github.blog) ### What does the secret scanning piece actually do? It lets an MCP-compatible agent scan current changes for exposed keys, tokens, and credentials before you commit or open a pull request. GitHub says the feature is available for repositories with GitHub Secret Protection enabled, and the MCP server now respects existing push-protection customizat(github.blog) rules in normal Git workflows and a weaker set inside agent workflows. (github.blog) ### What’s the catch with those scans? They’re not a system of record. GitHub’s docs are pretty explicit here — MCP-invoked secret scan findings are ephemeral. They show up in the agent session, but they do not become persistent GitHub alerts in the Security tab or APIs. Basically, this is a pre-commit guardrail, not your audit trail. If the agent catches something, you still need to fix it before it lands in history. (docs.github.com) ### How does dependency scanning fit in? The new dependency scanning flow rides on the Dependabot toolset. When an agent is asked to check dependencies, the MCP server sends dependency information to the GitHub Advisory Database and returns affected packages, severity, and recommended fixed versions. There’s also a more tho(docs.github.com)rompt-time checks and deeper post-change review. (github.blog) ### Why are people suddenly nervous about MCP connectors? Because the model can be tricked through the connector. GitHub has already described one version of the problem with prompt injection in public content. Supabase makes the same broader point from the database side — if you connect an assistant to a project through MCP, you should scop(github.blog)sion controls are still coming. That’s a polite way of saying the convenience layer is ahead of the security granularity in some setups. (github.blog) ### So what should teams do now? Treat MCP credentials and permissions like production access. Scope the server as narrowly as possible. Prefer OAuth or dedicated MCP keys over reusing broad user credentials. Keep read-only modes on unless write access is necessary. Rotate keys. Log what the agent can touch. The practical guidance showing up arou(github.blog), because “the assistant did it” is not a control. (supabase.com) ### Bottom line? GitHub’s update matters because it moves security checks into the exact place where agent mistakes happen — the tool call. That won’t solve prompt injection or over-broad access by itself. But it does mark a shift: if AI agents are going to operate inside real developer workflows, the MCP layer now has to enforce the same kind of scanning, policy, and traceability teams already expect everywhere else. (github.blog)