Case Study
Redis pinned every MCP dependency after we flagged the risk
By Michael K Onyekwere
Two days from a public GitHub issue to all MCP package versions pinned in RedisInsight. No email threads, no sales pitch, no contract. Just the scan, the evidence, and a maintainer who cared.
This is the consumer-prevention leg of the case-study set. Redis pinned. Agions rewrote risky code. NodeBench improved scanner precision through public technical pushback.
- MCP deps flagged
- 5
- Time to action
- 2 days
- Versions pinned
- All
What we found
RedisInsight is Redis's official GUI for managing Redis deployments. Its MCP configuration installed five npm packages via npx -y with no version pinning:
- -
@modelcontextprotocol/server-github:85/100 - -
@modelcontextprotocol/server-memory:95/100 - -
@modelcontextprotocol/server-sequential-thinking:95/100 - -
@upstash/context7-mcp:95/100 - -
@playwright/mcp:100/100
Every package scored well on the day we scanned. That was the point. npx -y pulls whatever is latest on every run, which means a future compromise of any of those maintainers lands inside RedisInsight with no warning. The March 31 axios incident was still fresh in everyone's memory.
What we showed them
We opened redis/RedisInsight#5763 on April 11 with the five scan reports, the axios parallel, and a capability analysis showing what each MCP server would grant their AI: repository write, file system write, outbound network, plus browser automation via Playwright. That reframed the question from "is this package safe today" to "what happens when one of these changes."
What they did
“Thanks for flagging this! You're right that unpinned MCP dependencies are a risk. We've gone ahead and pinned all our MCP package versions to exact versions, so we're no longer pulling whatever's latest on each run. For now, we'll manage version updates manually, but we appreciate you bringing this to our attention!”
Two days from first report to every MCP dependency pinned. The issue was closed on April 14. The supply-chain surface that existed on April 11 is closed today.
The next layer
Pinning versions is the right first step. It is not the last one. Teams eventually bump versions, and the question becomes: did the new version add capabilities the old one didn't have? Did the publisher posture change? Did the score drop?
The public security memory answers the first half of that question: what changed, when, and why it matters. The Agions case shows the maintainer-remediation path. NodeBench shows the precision-feedback path. Redis is the consumer-prevention path: pin first, then decide deliberately when to move.
The AgentScore Policy Gate answers the second half automatically on every PR. Version bumps become deliberate decisions with visibility, not blind updates. The install is one YAML block and auto-provisions via GitHub OIDC.
Want the same visibility for your repo?
Drop the workflow in, push, done. Free for public repos.