The next useful AI coding agent will not just write code faster. It will know when to stop and run the boring checks before the mistake becomes a repository problem.
That is the practical signal in GitHub's May 5 MCP Server updates. GitHub made secret scanning through the GitHub MCP Server generally available, and put dependency scanning through the same MCP path into public preview.
The thesis: AI coding agents need security tools in the commit path, not just security reports after the fact.
Why This Matters Now
Most software security tools still feel downstream. A developer writes code, opens a pull request, waits for checks, then reacts to red lights. That loop works, but it is badly timed for AI-assisted development.
Agents change the pace. They can edit multiple files, add packages, generate configuration, and prepare pull requests in a single flow. If the security check only arrives at the end, the agent may have already built on top of a bad dependency or leaked credential pattern.
GitHub's MCP updates move part of that feedback earlier. GitHub says an MCP-compatible coding agent or IDE can scan current changes for exposed secrets before a commit or pull request. It also says the new dependency scanning preview can use the MCP Server's `dependabot` toolset to check added dependencies against the GitHub Advisory Database and return affected packages, severity, and recommended fixed versions.
That turns security from a dashboard the human visits later into a tool the agent can call while work is still in motion.
The Commit-Path Security Stack
Teams adopting AI coding agents should think in four layers.
1. Secret checks before commit. Credentials are easiest to fix before they land in history. GitHub says MCP secret scanning can surface exposed keys, tokens, and credentials in the agent session before they are pushed. That does not eliminate the need for push protection, but it gives the agent a chance to repair the change while context is fresh.
2. Dependency checks before the package spreads. AI coding agents are good at adding libraries. That is useful and dangerous. GitHub says the dependency scanning preview can return structured vulnerability results, including severity and fixed versions. The important product pattern is not "the agent installed a package." It is "the agent checked the package before treating it as part of the solution."
3. Tool boundaries by lane. GitHub's MCP Server repository documents configurable toolsets, including `dependabot`, `secret_protection`, `code_security`, and `security_advisories`. It also documents read-only behavior. That matters because not every agent task deserves every tool. A triage agent, a coding agent, and a release agent should not share one giant permission surface.
4. Durable systems of record. GitHub Docs says MCP-invoked secret scanning findings are ephemeral in the current agent session and are not persisted as GitHub alerts. That is an important constraint. Agent-time checks are a fast feedback layer. They are not a replacement for repository alerts, branch protection, CI, dependency review, or incident records.
What Builders Should Copy
Do not copy the feature names. Copy the workflow shape.
First, define required security calls for each agent job. A dependency-changing task should run a dependency check. A configuration or environment-related task should run a secret check. A release task should verify that durable CI and repository gates passed.
Second, make the result actionable for the agent. "Vulnerable dependency found" is less useful than "upgrade this package to this fixed version or explain why the package is removed." The agent should receive enough structure to repair the work, not just enough warning to fail.
Third, keep ephemeral and durable checks separate. Pre-commit agent checks should reduce avoidable mistakes. Durable systems should still preserve audit trails, enforce rules, and catch anything the agent skipped or misread.
Fourth, measure invocation quality. The new failure mode is not only "the scanner missed something." It is "the agent forgot to ask the scanner." Track whether the right tools are invoked for the right task classes before trusting the workflow.
Where This Can Break
This does not make agentic coding automatically safe.
Preview tools can change. MCP clients vary. A developer can ignore an agent-session finding. A scanner can miss a secret or vulnerability. A tool can return the right result and the agent can still make the wrong repair. A broad MCP toolset can also become an unnecessary permission expansion if teams enable everything for convenience.
The lesson is narrower and more useful: as agents do more software work, security has to move closer to the moment of code creation.
The Takeaway
AI coding agents should not be judged only by how much code they generate. They should be judged by whether they know when to pause, inspect the change, call the right security tool, and repair the result before the work crosses a repository boundary.
For builders and operators, the immediate checklist is simple: map which agent tasks can introduce secrets or dependencies, wire the relevant checks into the agent flow, keep durable CI and alerting in place, and measure whether the agent actually uses the tools.
The winners will not be teams with the most autonomous agents. They will be teams whose agents have the right brakes in the right part of the workflow.
Sources
- https://github.blog/changelog/2026-05-05-secret-scanning-with-github-mcp-server-is-now-generally-available/
- https://github.blog/changelog/2026-05-05-dependency-scanning-with-github-mcp-server-is-in-public-preview/
- https://docs.github.com/en/code-security/how-tos/use-ghas-with-ai-coding-agents/scan-for-secrets-with-github-mcp-server
- https://github.com/github/github-mcp-server