Model Context Protocol (MCP) is an open standard that lets a coding agent call external tools directly, security scanners included. An agent can start a scan against the running build, read each finding with the request and response that produced it, draft a fix, and rescan to confirm the finding is gone, while a human approves the merge.
It is a genuinely good answer to a real problem. It is also an answer to only one of the two problems AI-assisted development created, and the second one is the harder of the two.
Key takeaways
- MCP closes the loop between finding a vulnerability and fixing one, for people who work through a coding agent.
- What makes that loop trustworthy is underneath it: an agent needs retained evidence and a repeatable scan, not a severity label.
- AI-assisted development also turned people who are not developers into shippers of software. None of them will ever run an agent against a scanner.
- The usual ways of reaching an application, a pipeline, a repository, a security champion, an inventory, are all missing for that second group.
- Both groups produce applications that land on the same AppSec team. What bridges them is how testing reaches the application, not who drives it.
The half MCP solves
For an engineering team, MCP changes where security testing runs, not who is accountable for it. The agent that just wrote the endpoint can test it: launch the scan, pull the findings, read the evidence behind each one, propose a change, and run the scan again to prove the behavior changed. Testing stops being a separate destination someone visits and becomes a tool call inside the work.
That is a meaningful change in cycle time. It is not, by itself, a change in assurance. Whether the loop produces fixes worth merging depends entirely on what the agent is handed.
An agent needs evidence, not a severity label
Hand an agent a vulnerability class and a severity score and it will produce a fix. It will be well-structured, confidently explained, and frequently wrong in ways that are difficult to notice, because the model is pattern-matching against what that class of bug usually looks like rather than against what your application actually did.
There is direct evidence that confident-looking output is the failure mode to design against. In the Stanford study Do Users Write More Insecure Code with AI Assistants?, participants working with an AI assistant wrote significantly less secure code than those without one, and were more likely to believe their code was secure. Fluency and correctness came apart, and the fluency was persuasive enough to suppress the instinct to check.
Evidence is what closes that gap. An agent handed the actual HTTP request that triggered the issue, the response that came back, and a command that reproduces it has something to test its own work against. It can make the change, rerun the scan, and observe that the behavior it was pointed at no longer happens. That is a different epistemic position from proposing a fix for a category name.
Why determinism is the load-bearing property
A verification loop only works if the test is repeatable. If two scans of the same build return different findings, an agent cannot distinguish between a fix that worked and a scan that happened to miss the issue that time, and neither can the human reviewing the pull request. Non-deterministic findings do not just add noise; they quietly break the ability to prove anything was resolved.
So the interesting question about an agent-ready scanner is not whether it has an MCP server. It is whether the thing behind the MCP server produces the same findings, backed by the same retained evidence, every time it runs.
Anyone’s agent can fix a finding. What matters is the scanner underneath it. Determinism on the finding, agents on the fix, humans on the merge.
The half it does not solve
AI-assisted development did something else, quietly, at the same time. It lowered the cost of shipping software far enough that shipping software stopped being something only engineering does.
Finance stands up a dashboard. HR wires a portal to a vendor API. Operations builds a low-code workflow. Internal tools get generated wholesale by an assistant and deployed by whoever asked for them. These are real applications with real endpoints, frequently handling real data.
The code underneath them is not safe by default either. Veracode’s 2025 GenAI Code Security Report, which analyzed output from more than 100 large language models across Java, JavaScript, Python, and C#, found AI-generated code introduced security flaws in 45% of tests. That number describes code written for professional developers to review. It is not more reassuring when nobody reviews it at all.
And the people who built these applications are not going to install an MCP server, configure an agent, or read a findings payload. That is not a training gap or a maturity problem. It is a description of their job. A financial analyst who built a reporting dashboard is not going to triage a security finding, and no enablement program will change that.
MCP is a developer-workflow protocol, and it assumes a developer workflow. Where there is no agent, no repository, and no pipeline, it has nothing to attach to. So the applications least likely to have been security tested are exactly the ones the agent story does not reach.
Why the usual playbook does not reach them either
This is not only an MCP limitation. Most of the standard ways a security program reaches an application quietly assume things this second group does not have.
| The usual approach | What it assumes | Why it misses |
|---|---|---|
| Gate the pipeline | The app moves through CI | It was assembled in a builder or deployed by hand, and never passed through a build |
| Scan the source | There is a repository you can reach | The code may live somewhere you do not have, in a form you cannot parse, or not exist as a repo at all |
| Enable a security champion | There is a developer on the team | The team is finance, HR, or operations; nobody there owns application security |
| Ask teams to register apps | Teams know they built something in scope | You get the applications people remembered to report, and the gap is where the risk sits |
What makes this expensive is that nothing turns red. The dashboard stays green, the scan schedule keeps passing, and the report reads clean, because the application nobody onboarded was never in scope to begin with. Coverage does not fail loudly. It decays silently, and the metric that would have told you keeps reporting success.
Both halves land on the same team
These look like two different audiences, and in one sense they are: one uses security tooling, the other never will. But they resolve to the same buyer. The AppSec team owns the outcome for the code an agent wrote at 2am and for the dashboard finance shipped last quarter.
What differs is what that team is buying. For engineering, it is leverage on developers who already have agents and are already moving faster than review can keep up. For everyone else, it is coverage over builders who will never adopt anything, which means the testing has to work without their participation entirely.
Neither of those is a case for a smaller security team. Agents absorb volume; they do not set the standard, judge whether a fix is real, or decide what ships. The reviewer did not disappear, and the judgment did not get automated. What changed is how much surface one team can stand behind.
Same team, far more surface, with the judgment staying exactly where it belongs.
The bridge is how testing reaches the application
The useful question is not who drives the scan. It is how testing gets to a given application at all. There are four ways in, and a program that covers both halves uses all of them.
| Way in | What it needs | What it covers |
|---|---|---|
| Black box | A URL, and credentials if the app has a login | Any reachable application, including the ones built outside engineering |
| Gray box | Access to the source | Endpoints no crawl or spec would reveal, discovered from the code itself |
| CI/CD | A pipeline | Every build, gated on conditions the team chooses |
| Agent-native | An MCP-capable coding agent | Testing inside the workflow where the code is being written |
The rungs are not competing products, and they are not a maturity ladder you graduate along. They are four doors into the same engine, running the same checks and returning the same evidence, so a finding means the same thing regardless of which door it came through. That matters more than it sounds: if the black-box path returns weaker findings than the agent path, you have not covered the second group, you have just logged them.
Read this way, the agent story stops being the whole strategy and becomes the top rung of one. A program with only the fourth rung covers the people who already had help. A program that starts at the first one covers the applications nobody remembered to mention.
Questions worth asking
If you are evaluating how your program handles either half, these separate a working loop from a demo:
- Can your agent launch a scan, read the evidence, propose a fix, and verify it? All four, not just the first and last.
- Does a finding carry the request and response that produced it? If triage starts from a category and a score, the agent is guessing and so is the reviewer.
- Do two scans of the same build return the same findings? Without that, nothing downstream can be proven fixed.
- Can you test an application you have no source for? This is the whole second half. If the answer requires a repository, it does not cover the dashboard finance built.
- Does authenticated testing work when the builder is not involved? Most of the interesting surface sits past a login, and the person who set it up is not on your team.
- Who approves the change? The answer should be a human, and the tooling should make that easy rather than incidental.
Frequently asked questions
What does MCP actually do for security testing?
It lets a coding agent operate a scanner as a tool rather than a separate destination. The agent can start a scan, retrieve findings with the request and response evidence behind them, propose a code or configuration change, and rerun the scan to verify the finding is gone. NightVision publishes an open-source MCP server and agent skills for exactly this, and a human still reviews and approves the merge. See NightVision for coding agents.
What about applications built by people who do not write code?
They get tested without their involvement. A discovery-driven DAST platform can test any reachable application from a URL alone, fully authenticated when credentials or a recorded login are supplied, with no source access and nothing for the builder to install. The security team onboards the application; the person who built it never has to change how they work. See securing apps built outside engineering.
Why does determinism matter if an agent is writing the fix?
Because a fix is only verifiable if the test that failed can be run again and produce the same result. If findings vary between runs, an agent cannot tell whether its change fixed the issue or the scan simply happened to miss it that time. Deterministic findings backed by retained evidence are what turn an agent’s proposed fix into something a reviewer can confirm.
Can an agent replace security review?
No, and the loop works better when it does not try. The agent absorbs volume: reading evidence, locating the responsible code, drafting a change, and rerunning the scan. Deciding whether the fix is genuinely correct, whether it introduces something new, and whether it meets the standard is review, and it stays with the team that owns the application.
Does any of this reduce the need for an AppSec team?
No. It changes what the team spends its time on. Agents absorb the triage and remediation drafting that a review queue could never scale to, and the security team keeps the work only it can do: setting the standard, judging whether a fix is real, and approving what ships.
Where should a program start if it has neither half covered?
Start with the applications you cannot currently reach, because that gap compounds silently while the agent gap is at least visible to the developers living in it. A black-box authenticated scan of a handful of internal applications nobody onboarded usually says more about a program’s real coverage than another integration on the pipeline that already works.
Go deeperThe fundamentals behind all of this, including how the testing approaches differ and where each one is blind, live in our guide to application security testing.
If your program has an agent story but no answer for the applications nobody onboarded, that is the gap worth closing first. Book a demo to see all four ways in against your own applications, or start free and point a scan at the one you are least sure about.