The honest premise, up front: the scanner underneath this service is
MIT-licensed and public. You can pip install jaimenbell-mcp-security-scanner
(or clone it), wire mcp-scan --fail-on P1 into your own CI, and gate your builds with it for
$0, forever — I say this in every sales conversation, not just here. Managed
Watch does not sell you the binary. It sells the human work a public repo cannot do for
itself: triaging every net-new finding against your baseline, keeping the ruleset current,
and being someone you can ask.
What Managed Watch actually is
The open-source mcp-security-scanner
runs as a GitHub Action inside your CI — on push, plus a weekly scheduled
run — checking your MCP server against seven detector families: codegen/template
injection, tool-parameter injection into a shell or eval, auth/network posture gaps,
secret handling, write-tools-on-by-default / tool-scope-creep, secret-leak-via-tool-response,
and job hazards in cron/CI/deploy files. A P0/P1 finding fails the build instead of merging
silently. On top of the raw scan, findings are graded for reachability (does a
registered MCP tool actually reach this code path) and tool-parameter taint — never
dropping a finding, only raising or lowering its confidence.
That grading is Python-only, because it needs an AST call-graph and the
scanner builds one for .py only. Findings in JavaScript, TypeScript, YAML or
shell are reported ungraded and are labelled as such — they are pattern
matches that a human still has to confirm, not reachability-confirmed defects. Most MCP
servers are TypeScript, so on a typical repo this is the majority of the output. Stated
here rather than discovered on your invoice.
That part is the free, self-serve CI gate. Managed Watch is the recurring layer wrapped around it: once a month I pull your latest scan, diff it against your per-client baseline, give every net-new finding a plain human verdict — real, false positive, or accepted risk — and send a short written digest. False positives get suppressed in your baseline so they never nag your team again. If a P0 turns up real at any point, you hear about it the same day, not at the next digest.
Who this is for
The recurring value only holds if all four of these are true — otherwise a one-time scan is the honest answer, not a subscription.
- A fleet, not a hobby projectTwo or more MCP servers in production. One static server is a one-shot scan, not a watch.
- The servers actually changeWeekly-plus commits. Continuous scanning earns its keep against regression — a frozen repo gets nothing a single scan didn't already give it.
- Real capability exposureWrite tools, shell/DB access, or endpoints reachable by untrusted agent input — something where a net-new P0/P1 is a genuine "glad we caught that."
- Security-conscious, no dedicated appsec hireA small eng team that cares but has nobody whose job is to re-run SAST and separate real hits from heuristic noise. The triage is the thing you can't staff yet.
Said plainly, who this is not for: a solo dev with one unchanging MCP server (the free CI gate is enough — don't pay for a watch on a picture that doesn't move), and large enterprises already running their own SAST/appsec function. Selling a watch to a static repo is a churn risk and an honesty problem, not a sale worth making.
What you get
CI security gate
The scanner runs on every push plus a weekly scheduled scan, via a ten-line GitHub Action addition. A P0/P1 finding fails the build.
Monthly human-triaged digest
Every net-new finding gets a real verdict — REAL / FALSE POSITIVE / ACCEPTED RISK — against your baseline, not a bot re-running the same rules at you.
Rule freshness
The ruleset ships as versioned releases as the MCP threat landscape moves. Your digest tells you when a pin bump is worth it — nothing auto-updates underneath you.
A human to ask
A confusing finding gets a plain-language email answer from the person who wrote the detection rule — not a ticket queue.
Cadence and report format
| Cadence | What happens |
|---|---|
| Every push + weekly | CI Action runs the scan; a P0/P1 finding fails your build (--fail-on P1). |
| Monthly | Net-new findings triaged against your baseline; a written digest covers: TL;DR, net-new findings (triaged), what resolved since last month, baseline changes, rule updates worth a pin bump, a trend table, and an honest coverage note stating exactly what the digest is and isn't based on this month. |
| Any time | A P0 verdict of REAL triggers a same-day short email — the only pager-shaped obligation, and it's triggered by triage, not by your CI failing (that's your build gate doing its job). |
Remediation guidance
Every finding in the underlying report already carries a severity, an honest confidence
(high / medium / low), a file:line, and a concrete fix — that's the free
report format. The Watch's added value is the monthly human layer on top: telling you
which of those findings are real for your repo versus heuristic noise, and being
reachable when a fix isn't obvious. Turning a finding into a shipped, re-verified fix is
the separate Fix-It add-on below, priced per finding once a scan scopes the work.
The privacy model, stated once, in full: the scan runs on your CI runner. Your source code never reaches me — full stop. The findings report lands in your artifact store. An optional counts-only webhook (off by default, no code, no paths, no finding text) is the only thing that can leave your environment, and only if you turn it on. I hold no credentials, ever. Funded competitors who take code custody — a dashboard you upload your repo to — cannot say this structurally; a solo operator with no hosted infrastructure can.
Pricing
- Everything in the free CI gate, wired in for you
- Monthly human-triaged digest against your baseline
- Rule freshness on a stated release cadence
- A human to ask, plain-language answers
- Each finding fixed and re-verified
- Follow-up scan confirms it's cleared
- Natural bolt-on to an audit or the watch
FAQ
The scanner is free and MIT-licensed. Why pay monthly?
Because a clone gives you the scan, not the triage. The subscription buys three things a public repo structurally can't: a human verdict on every net-new finding against your baseline (so you never chase a false alarm), a ruleset kept current as MCP threats evolve, and a person to ask when a finding is confusing. The automation is the hook; the human work is what's actually being paid for.
Will this touch or break our production systems?
No. The scan is static-only: it reads git-tracked source and never runs, deploys, or executes anything in your repo. It runs inside your own CI runner — nothing of yours is executed, modified, or deleted by me at any point.
What if the scan finds nothing?
Then the digest says so, plainly — it does not manufacture a finding to justify the fee. A clean bill isn't a guarantee of security; static analysis has a stated scope, and every report says what it can and can't prove.
Do you hold our code or credentials?
Never. The scan runs on your CI runner; the full report lands in your artifact store. The only thing that can leave your environment is an optional counts-only webhook (off by default), and even that carries no code, no file paths, and no finding text.
We only have one MCP server. Should we still sign up?
Probably not yet — the free CI gate covers a single, slowly-changing server just fine. The recurring watch earns its keep against a multi-server fleet that changes regularly. Ask on a scoping call and I'll say honestly if the watch is overkill for your shape.