GitHub MCP Scanning Is Here. Your Review Layer Still Matters.

On May 5, GitHub made two announcements that redefine where security scanning happens in AI-assisted development. Secret scanning via the GitHub MCP Server hit general availability, and dependency scanning entered public preview. Both run inside the MCP tool loop, meaning your AI coding agent can invoke them directly during a session rather than waiting for a CI pipeline to catch problems after the fact.

This is a genuine step forward. But it also shifts the trust model in ways that aren't immediately obvious. When your scanner runs inside the same environment as the agent that wrote the code, the runner itself becomes the trust boundary. And if nothing reviews the agent's work before it reaches that runner, you've got a gap.

What Changed on May 5

GitHub's secret scanning MCP tool was in public preview since March 2026. The GA release adds support for push protection customization, so the MCP tool now honors the same bypass rules you've configured at the repository or org level. If you're using GitHub Copilot CLI or VS Code with the GitHub MCP Server, you can ask your agent to scan staged changes for exposed credentials before committing.

Dependency scanning is newer. It ships as part of the dependabot toolset in the MCP Server. When an agent adds a dependency, it can invoke the toolset to check the GitHub Advisory Database for known vulnerabilities and get back affected packages, severity levels, and recommended fix versions. For deeper checks, it can also run the Dependabot CLI locally to diff dependency graphs before and after a change.

Both tools are useful. Neither is sufficient on its own.

The Problem with Scanning Inside the Agent Loop

Traditional security scanning runs in CI, separate from the environment that produced the code. The scanner and the code author don't share a runtime. That separation matters because it means a compromised build step can't tamper with the scanner's output.

MCP scanning flips that. The scanner is a tool the agent calls within its own session. That's convenient, but it means the scanner's environment is the agent's environment. If the runner hosting that agent is compromised, the scanner's findings can be intercepted, modified, or suppressed before anyone sees them.

This isn't a hypothetical. Supply chain attacks targeting CI runners have been documented repeatedly over the past two years. An attacker who gains access to the runner environment can intercept MCP tool calls just like any other process running in that context.

Secret Scanning Catches Leaks, Not Policy Violations

GitHub's MCP secret scanning does one thing well: it detects exposed credentials in code before they reach the repository. The GA release adds push protection customization, which means it now respects your existing bypass rules. That's a clean implementation of a specific problem.

But secret scanning doesn't evaluate whether the code that reaches the runner should have been there in the first place. It can't tell you that an agent introduced an insecure authentication pattern, bypassed a required approval flow, or modified a security-critical file it shouldn't have touched. Those are policy decisions, and they need to happen before code reaches the runner, not after.

A review layer that examines the PR diff before execution catches these problems at the earliest possible point. The agent proposes a change, the review gate evaluates it against your team's policies, and only approved changes proceed to the runner where MCP scanning can do its job.

Dependency Scanning Is Reactive by Design

The new dependency scanning toolset checks added packages against the GitHub Advisory Database. It's a solid mechanism for catching known vulnerabilities in dependencies. But it runs after the dependency has already been added to the project.

That means the agent has already written code that imports the package, possibly integrated it into multiple files, and built a feature around it. If the scan flags a vulnerability, unwinding that work costs time. And if the agent is running autonomously, it might not unwind at all without explicit instructions.

A pre-execution review catches new dependencies at the PR diff level. The review gate sees that a lockfile changed, identifies the new package, and can flag it before any code runs on a runner. That's not just faster detection; it's fundamentally cheaper to fix because no downstream work has been built on top of the vulnerable dependency yet.

The Runner Is the Trust Boundary

Here's the part that gets overlooked in the MCP scanning conversation: the runner environment is the trust boundary for all MCP tool execution. The agent runs on a runner. The MCP scanner runs on that same runner. If the runner's integrity is compromised, everything running on it is suspect.

GitHub's hosted runners provide reasonable isolation, but many teams use self-hosted runners for performance or cost reasons. Self-hosted runners that aren't ephemeral accumulate state between jobs: cached credentials, modified system packages, leftover processes. That state is exactly the kind of thing an attacker uses to persist across builds.

Ephemeral runners that spin up a fresh VM for every job eliminate this risk. Tenki's runners operate on ephemeral VMs running on Tenki-owned bare metal, so each job starts from a clean state with no carryover from previous executions. That's the foundation you need before MCP scanning results can be trusted.

The Complete Chain: Review, Isolate, Verify

GitHub's MCP scanning tools aren't competing with pre-execution review. They're complementary, but only if you have the other pieces in place. The defense chain has three stages:

1. Pre-execution review. Tenki's code reviewer examines the PR diff before any code runs. It flags policy violations, unsafe patterns, new dependencies, and changes to security-critical files. This is the earliest gate, and the only one that operates outside the runner's trust boundary.
2. Isolated execution. Approved code runs on ephemeral runners with no state carried over from previous jobs. This ensures the MCP scanning tools have a clean environment to operate in.
3. Post-execution verification. GitHub's MCP secret scanning and dependency scanning run inside the agent loop, catching exposed credentials and vulnerable packages that made it through the first two stages.

Skip stage one, and you're relying entirely on scanners that share a runtime with the code they're evaluating. Skip stage two, and those scanners might be running on a tainted machine. You need all three.

What This Means for Your Team

If you're evaluating GitHub's new MCP scanning tools, enable them. They're a net positive, particularly secret scanning with push protection now that it respects org-level customization. But don't treat them as a replacement for pre-execution review.

The practical question isn't whether to use MCP scanning or a review layer. It's whether your security architecture has coverage at every stage: before the runner, inside the runner, and after the runner. GitHub just filled in the "inside" part. Tenki covers the "before" and the runner itself. Together, the chain is complete.