Your developers are already using AI coding assistants. Some of these assistants connect to external servers through Model Context Protocol (MCP). You likely have no visibility into which servers they're connecting to, what credentials those servers are storing, or whether any of those servers are malicious.
In 2025, researchers documented the first confirmed malicious MCP server. CVE-2025-6514 scored 9.6 on the CVSS scale for a remote code execution flaw in mcp-remote. If your Continuous Threat Exposure Management (CTEM) program doesn't account for MCP, you're missing an entire attack surface.
Here's how to integrate MCP risk discovery into your existing CTEM workflow.
Why This Matters Now
Anthropic introduced MCP in late 2024. Within months, it became the standard way for AI assistants to connect to external data sources and tools. Your developers use it to query databases, access internal APIs, and interact with third-party services—all from within their coding environment.
This creates blind spots similar to those during the shadow IT era. Developers install MCP servers without security review, hardcode credentials in configuration files, and connect to community-maintained servers with no security guarantees.
Unlike shadow IT, MCP servers often run with elevated privileges and direct access to production systems. A compromised server can execute arbitrary code in your developer's environment, which likely has access to your source code repositories, internal APIs, and deployment pipelines.
What You Need Before Starting
Inventory access:
- Read access to developer workstations (via endpoint management or configuration management tools)
- Access to your source code repositories
- Network traffic logs from developer VLANs
Tools:
- Your existing CTEM platform (or manual tracking if you don't have one)
- File system scanning capability (osquery, PowerShell, or similar)
- Secret scanning tool (TruffleHog, GitGuardian, or git-secrets)
Stakeholder buy-in:
- 30 minutes with your developer relations or engineering productivity team
- Agreement on acceptable MCP server sources (internal only, approved vendors, or open community)
Time budget:
- Initial discovery: 2-4 hours
- Policy development: 2-3 hours with stakeholders
- Ongoing monitoring: 15 minutes weekly
Step-by-Step Implementation
Phase 1: Discover Existing MCP Deployments
Start with file system scanning. MCP configuration lives in predictable locations:
# macOS/Linux
find ~/Library/Application\ Support -name "*mcp*" -type f
find ~/.config -name "*mcp*" -type f
# Windows
Get-ChildItem -Path $env:APPDATA -Recurse -Filter "*mcp*"
Look for JSON configuration files containing mcpServers objects. These define which servers your developers connect to.
In your source code repositories, search for MCP configuration:
git grep -i "mcpServers" --all-match
git grep -i "stdio.*command" --all-match
Document every unique MCP server you find:
- Server type (stdio, SSE, HTTP)
- Source location (npm package, local binary, remote URL)
- What it accesses (database, filesystem, API)
- Who's using it (team, individual)
Phase 2: Identify Hardcoded Credentials
MCP servers often require authentication to external services. Developers frequently hardcode these credentials in configuration files or environment variables.
Run your secret scanning tool against:
- MCP configuration files you discovered in Phase 1
- Environment variable definitions (
.env,.bashrc,.zshrc) - Any custom MCP server code in your repositories
Flag every credential you find. For each one:
- Determine what it accesses
- Check if it's still valid
- Identify who created it and when
Phase 3: Assess Server Provenance
For each MCP server, determine its origin:
npm packages: Check the package registry for maintainer information, download counts, and last update date. Look for packages with fewer than 1,000 weekly downloads or no updates in 90+ days.
Local binaries: Review the source code if available. If it's compiled without source, treat it as high-risk until proven otherwise.
Remote servers: Identify who operates them. Community-run servers with unknown operators should be flagged for removal or replacement.
Add each server to your CTEM program as an asset with a risk score based on:
- Provenance (unknown = critical, community = high, internal = medium)
- Access scope (production data = critical, development only = medium)
- Credential exposure (hardcoded secrets = critical, no auth = high)
Phase 4: Create an MCP Server Allowlist
Work with your engineering productivity team to define acceptable MCP server sources. Consider a tiered approach:
Tier 1 (pre-approved):
- Internal MCP servers you build and maintain
- Servers from vendors you already have security reviews for
Tier 2 (review required):
- Well-maintained open source servers with active communities
- Requires security review before use
Tier 3 (prohibited):
- Unknown or abandoned packages
- Servers that require production credentials
- Any server that failed security review
Document this policy in your developer handbook. Make it clear that using non-approved MCP servers violates your security policy the same way installing unapproved software does.
Phase 5: Deploy Continuous Monitoring
Add MCP server discovery to your weekly CTEM scans:
# Example osquery pack query
SELECT
f.path,
f.size,
f.mtime,
u.username
FROM file f
JOIN users u ON f.uid = u.uid
WHERE f.path LIKE '%mcp%'
AND f.path LIKE '%.json'
Configure alerts for:
- New MCP configuration files
- Changes to existing configurations
- New credentials in MCP-related files
Review your MCP asset inventory monthly. Remove servers that are no longer in use. Re-assess risk scores for servers that have been updated or had their provenance change.
Validation - How to Verify It Works
After your first full scan:
- You should have a complete inventory of MCP servers in use
- Every server should have a risk score
- Every hardcoded credential should be documented and scheduled for rotation
- Your allowlist should be published and accessible to developers
Test your monitoring by having a developer install a new MCP server. Your scanning should detect it within one week.
Test your policy by asking your engineering team if they know where to check if an MCP server is approved. If they don't know, your documentation isn't visible enough.
Maintenance - Ongoing Tasks
Weekly:
- Review new MCP servers detected in scans
- Check for new CVEs affecting MCP packages you've approved
Monthly:
- Re-scan for hardcoded credentials (developers add new servers)
- Review your allowlist with engineering productivity team
- Update risk scores based on server activity
Quarterly:
- Audit MCP server usage against your allowlist
- Remove unused servers from your inventory
- Review and rotate any credentials that can't be moved to a proper secrets manager
MCP isn't going away. Every major AI coding assistant now supports it. Treating it as part of your continuous threat exposure management program means you'll catch problems before they become breaches—just like you do with every other technology your developers adopt.
