why not build my own scanner?

Detection is the easy half. The hard part is deciding whether a flagged problem can actually be reached by an outsider, and that question is answered by reading code. Start as a service. Write software only for the parts you find yourself repeating.

what makes agreement between scanners useful?

Rarity. The study found an average pairwise overlap of 15.66 percent, dropping to 5.98 percent for prompt injection and 3.36 percent for data leakage, and no server was flagged by all eight. When tools that rarely agree do agree, that is a cheap signal worth checking first.

how big is the risk of clearing an alert wrongly?

Large enough to plan for. The same scanners missed about three quarters of the known bugs in the study, so absence of a real alert is weak evidence of safety. Write your reports to say what you checked and what you did not, and never write the word safe.

is scanning MCP servers even the right worry?

Partly. A second paper showed an agent being fooled 49.1 percent of the time by quote-like characters hidden in ordinary content, with no bad server involved, and an input filter caught none of those 108 attacks. Offer that test alongside your triage.

Sell alert triage to teams drowning in fake MCP warnings

The finding this rests on

A team at Fudan University and the Shanghai Innovation Institute gathered 64,611 MCP server projects and got 37,288 of them running. Then they pointed eight popular security scanners at the running servers. The scanners flagged 96.89 percent of them as risky.

Two people then read 100 of those flagged servers by hand. On average, only 45.53 percent of the sampled alerts were real. The scanners also missed most of the known bugs, catching 24.17 percent of 10 published CVEs across 38 servers. Any two scanners agreed only 15.66 percent of the time, and no server was flagged by all eight. We score that paper 5 out of 10. Read it at More than half of MCP security alerts are false alarms.

A second paper shows what the scanners are not looking for. Researchers hid quote-like characters inside a field an attacker controls, so the agent misread where one field stopped and the next began. On a public test bench the attack worked 49.1 percent of the time, while old-style prompt injection worked 0.2 percent. An input filter caught none of the 108 new attacks. We score that paper 6 out of 10. Read it at Fake quote marks fool AI agents half the time.

How strong is this? Both are preprints. The hand check covers 100 servers and the bug list covers 10 bugs, so treat the exact rates as rough. But the shape of the problem is clear. Too many alerts, and the real hole is somewhere else.

Who has this problem

Picture the one security engineer at a 70-person software company. Her team has started letting an AI agent read tickets, files and code. Every week somebody asks her to approve a new MCP server.

Her morning goes like this. She runs the free scanner. It returns 40 warnings across six servers. She opens the first one. It says a password is leaking, because a field is named token. She reads the code for twenty minutes and finds an empty box waiting for input. No secret, no leak, just a word.

She has 39 warnings left and a release on Thursday. So she does what everybody does. She skims the rest, approves the servers, and moves on.

The alert list is now decoration. It is the smoke alarm that goes off when you make toast.

What you would sell them

Sell her a verdict, not another scanner. She sends you the server, or the output she already has, and within one working day she gets back a short list. Each item says real, not real, or cannot tell, with the line of code and one sentence on how an outsider would reach it.

Your method is not clever, and that is the point. Run four scanners rather than one and start with the places where two or more agree, because agreement is rare and therefore worth something. Then a person opens the code and answers one question. Could a stranger actually do this?

On Monday morning she forwards you the weekend scan and gets on with the release.

What to charge

Test it at 500 dollars a month for up to thirty servers. Test a second price of 40 dollars for a single triaged alert, for people who will not sign up for a month. Both figures are hypotheses. Only a payment settles them.

Here is the reasoning. Do not compare your fee to a scanner, because the scanners are free. Compare it to her hour. Ask her what one hour of her time costs the company, then ask how long she spent on that fake password alert. If a month of your service costs less than the hours she burned last month on alerts that were not real, the sale argues itself.

How you would build the first version

Build no software in month one. This is a service wearing a product costume.

Use the free scanners as they come. Put their output in a spreadsheet, one row per alert, one column per scanner, and mark the rows where two or more agree. Write your verdicts in a plain email. Keep every verdict you have ever written in one file, because the same template server shows up again and again. The paper found one template repeated 537 times, so your second customer will bring you problems you already solved.

Add one extra check the scanners do not do. The second paper released its attack benchmark publicly. Run a customer’s agent through it once and report whether it can be fooled by fake field marks.

Do not build a scanner. Do not build a dashboard, a login, or an integration with anything. Do not promise real time. One working day is fine.

The one-week test

Day one. Install four free MCP scanners. Run all four over ten public servers. Put the output in one spreadsheet.
Day two. Triage those alerts by hand yourself. Time it. Write down how many were real, and how long one verdict takes.
Day three. Find ten people who approve agent tools at their company. Ask each one how many alerts they got last month and what they did about them.
Day four. Give three of them a free triage of their real alerts, delivered as one email with verdicts.
Day five. Ask all ten for 500 dollars for the first month, starting now. Send an invoice, not a proposal.

Friday gives you a yes or a no. Yes means one invoice is paid or a card is on file. No means everyone wants to talk again next quarter. Next quarter is a no.

What would kill this

The numbers may not hold outside this study. The 45.53 percent comes from hand checking 100 flagged servers, and the miss rate comes from 10 published bugs across 38 servers. The authors also say their collection leans towards projects that were easy to get running. Your customer’s servers may be nothing like that sample.
You can be wrong in the direction that hurts. Saying an alert is a false alarm is a promise. The same scanners missed about three quarters of known bugs, so a clean report from you means much less than a customer will assume. One bad clear ends the business.
The scanners could get better next month. Your whole business is the gap between what a scanner says and what is true. Free tools improve. If one of them starts checking whether a problem is reachable, the gap closes.
Hand work does not scale. If a verdict takes an hour and you charge 500 dollars a month, count how many verdicts you owe before you lose money. This stays a job until the repeated templates let you answer from a file.
The alert list is not where the risk is. The second paper shows an agent being fooled with no bad server at all, just quote marks inside ordinary content. If that is how a customer gets hurt, your neat triage report will not have saved them.
Doing nothing is free. Ignoring 40 alerts costs zero dollars today. You are selling against that, not against another vendor.

Just Out Tech explains new research in plain language. This article was drafted with AI assistance and checked by a human against the original source.