On November 25, 2024, Anthropic released the Model Context Protocol (MCP), an open standard for how large language models and coding agents call external tools and data sources. Within a year it had been adopted well beyond its origin — OpenAI, Google DeepMind, and IDEs including Cursor, GitHub Copilot's ecosystem, Claude Code, and Claude Desktop all support it as a common wire format for tool calls. That adoption matters for a specific reason: the same protocol that lets an AI assistant read your files or query a database can just as easily let it invoke a static analyzer or dependency scanner mid-session, before code ever reaches a pull request. That matters because the code these assistants write is not automatically safe. Pearce et al.'s "Asleep at the Keyboard?" study (NYU, IEEE S&P 2022) evaluated GitHub Copilot across 89 scenarios spanning 18 CWE categories drawn from MITRE's Top 25 and found that roughly 40% of the resulting security-relevant code suggestions contained exploitable vulnerabilities. A separate Stanford study, Perry et al.'s "Do Users Write More Insecure Code with AI Assistants?" (ACM CCS 2023, dl.acm.org/10.1145/3576915.3623157), found something more troubling: developers using an AI assistant were more confident their code was secure than developers who wrote it unassisted, despite it being measurably less secure. This piece explains that trust gap and the MCP-based architecture pattern for closing it.
Why does AI-generated code need a different scanning workflow than human-written code?
AI-generated code needs a different workflow because the volume and confidence profile of the risk are both different. A human developer writing an unfamiliar API call tends to slow down, check documentation, or flag uncertainty in a PR description; an AI assistant produces a fluent, confident-looking answer regardless of whether the underlying pattern is safe. Pearce et al.'s ~40% vulnerability rate is only half the picture — Perry et al.'s separate finding is that participants who used the AI assistant rated their own code as more secure than the control group did, even though independent evaluation showed the opposite. That combination — higher volume of suggestions accepted, plus misplaced confidence — means vulnerable patterns like string-concatenated SQL queries, missing input validation, or insecure deserialization can enter a codebase faster than a human reviewer can catch them by reading diffs alone. The fix isn't to scan less often; it's to make scanning a tool the assistant itself can call, not a separate step a reviewer has to remember to run later.
What is MCP and why does it make scanner integration different from a CI plugin?
MCP is a client-server protocol: an MCP client (a coding assistant like Claude Code, Cursor, or Claude Desktop) connects to an MCP server that exposes a set of callable "tools," each with a defined name, input schema, and description the model can read and decide to invoke. This differs from a CI plugin in an important way — a CI check runs only after a commit or PR is pushed, on a fixed schedule dictated by your pipeline. An MCP-exposed scanner can be called during the coding session itself, as soon as the assistant finishes drafting a function, because the model can decide mid-conversation that "this looks like it touches untrusted input, I should check it" — or a developer can simply ask it to. The protocol standardizes discovery (the client asks "what tools do you have?") and invocation (structured JSON arguments in, structured JSON results out), so the same scanner can be wired into Claude Code, Cursor, or ChatGPT's connector interface without three different integrations.
What does a real MCP-based scanning setup look like in practice?
Safeguard runs a hosted MCP server reachable at https://mcp.safeguard.sh/mcp/anthropic for Claude specifically, with general SSE and HTTP-streaming endpoints at https://mcp.safeguard.sh/mcp/sse and /mcp/http for other MCP clients, authenticated with a bearer sg_api_ API key. Once connected — via Claude Desktop's claude_desktop_config.json, Claude Code's claude mcp add command, or Cursor's ~/.cursor/mcp.json — the assistant gains access to a documented tool surface for querying vulnerabilities, SBOMs, and findings, and for triggering scans, all scoped to the connecting tenant. The practical pattern: a developer working in Claude Code accepts an AI-drafted function that shells out to a subprocess with a user-supplied filename, then asks the assistant to check it — the assistant calls the connected scanning tool instead of relying on its own (unverified) judgment about whether the pattern is safe.
Can a scanner reachable through MCP actually catch what pattern-matching linters miss?
It depends entirely on what's behind the MCP tool call — MCP is transport, not detection logic. A tool that just greps for subprocess.call( will produce the same noisy, low-precision output over MCP as it would as a pre-commit hook. What changes the outcome is wiring in a scanner that does source-to-sink dataflow analysis rather than lexical matching. Safeguard's own SAST engine (documented as rolling out, with JavaScript/TypeScript, Python, and Java as phase-one languages) traces untrusted input from a source — a request parameter, a CLI argument, a file read — to a dangerous sink such as a SQL query or command execution, and returns the CWE mapping, severity, and the ordered dataflow hops with each finding. Exposed as a callable tool, that trace is exactly the context an assistant needs to explain why a suggestion is risky and propose a concrete fix, rather than issuing a generic "consider validating input" comment.
Where should the scan actually gate the merge — in the editor, pre-commit, or CI?
All three, because each catches a different failure mode, and none of them alone is sufficient. An in-editor MCP call catches issues while the developer still has full context and can fix them in seconds, but it's advisory — nothing stops a developer from ignoring the assistant's warning or from a scan simply not being invoked for a given change. A pre-commit or pre-push hook running the same scanner (for example, safeguard appsec sast --dir ./src from the CLI) closes that gap locally, without needing network access to a remote MCP server. CI is the backstop that can't be skipped: findings need to land in a shared, queryable view — safeguard findings list --engine sast --severity high — and a merge gate needs to block on results independent of whether any individual developer ran a check earlier. Treat the MCP-connected in-editor check as a fast feedback loop for the author, not a substitute for a gate that runs regardless of what happened upstream.
What should a team verify before trusting an MCP-connected scanner in its coding workflow?
Verify that the scanner's detection depth matches what you're relying on it for, and that the connection itself is scoped correctly. Safeguard's SAST and DAST capabilities are explicitly documented as rolling out — the platform wiring, unified findings model, and (for DAST) safety controls such as verified-target-only scanning and strict scope enforcement are in place today, but detection coverage across languages and rule sets expands over time, so a team should know which languages and CWE classes are actually covered rather than assuming blanket coverage. Separately, confirm tenant isolation on the MCP connection itself: findings and scan results should be scoped per X-Tenant-Id/X-Org-Id, and API keys used for MCP auth should be scoped to least privilege and rotated, since a coding assistant with a broad key can now trigger scans and read findings across more of your organization's data than a single project warrants. An MCP tool call is only as trustworthy as the scanner and the credential behind it.