From Problem to Solution
If you read our last post, you know the MCP ecosystem has a security problem. Tools with root level access are installed without review. Traditional security tools are blind to MCP specific threats. The attack surface is growing faster than defenses can adapt.
But here's what we didn't tell you: We discovered these vulnerabilities because we're security engineers who couldn't ignore what we were seeing.
The Origin Story
As security engineers, we were excited about MCP. The Model Context Protocol promised to unlock a new era of AI productivity. Claude and other assistants could finally interact with real tools, real data, real systems. The potential was obvious.
But so were the risks.
Within days of exploring the MCP ecosystem, uncomfortable questions emerged:
- Who is reviewing these tools before developers install them?
- What happens when a malicious actor publishes a typosquatted package?
- How would an enterprise even know what MCP tools are running across their organization?
The more we dug, the more alarmed we became. MCP tools are being installed through the same shadow IT channels that have plagued enterprises for decades. Except now these tools have direct access to codebases, credentials, and sensitive data. Developers find a useful looking MCP server on GitHub, add it to their config, and suddenly an unvetted third party has root level access to their development environment.
We searched for existing solutions. Container scanning tools don't understand MCP protocols. EDR solutions see localhost traffic and move on. SIEM platforms can't parse the semantic meaning of AI operations.
There was nothing.
The gap between MCP's rapid adoption and security oversight is a ticking time bomb. We decided to build the solution ourselves.
Why Traditional Security Fails for MCP
Before diving into our solution, let's understand why existing security tools can't solve this problem.
The Protocol Gap
MCP operates at the application protocol level. Your security stack sees: - HTTPS traffic between processes - JSON RPC messages over stdio - WebSocket connections to localhost
What it doesn't see: - Semantic meaning: Commands like "read all files in /secrets/" - Intent analysis: Is this data access legitimate or exfiltration? - Behavioral patterns: A tool suddenly accessing 10x more files than normal
Traditional tools operate at the wrong layer of abstraction.
The Permission Model Problem
Mobile apps taught us to be skeptical of permission requests:
"This app wants to access your contacts"
[Allow] [Deny]
MCP tools bypass this entirely. There's no standardized permission model. No granular controls. No user facing consent dialogs.
Most tools request everything and trust developers to review the code. That review almost never happens.
The Supply Chain Blindspot
npm audit catches known CVEs. Docker Scout scans for container vulnerabilities. But who's auditing MCP tools?
- No centralized vulnerability database
- No standardized security metadata
- No review process before publication
- No chain of custody verification
The same supply chain attack patterns that plagued npm, PyPI, and Docker Hub are now being applied to MCP with even less oversight.
Introducing Ocellus: Three Pillars of MCP Security
Ocellus is built on three interconnected pillars, each addressing a critical aspect of MCP security. At the core of everything is the Ocellus Engine, our detection and analysis system that powers the security insights across the platform.
The Engine performs deep analysis of MCP servers: static code analysis, permission mapping, and dependency auditing. Tools in the registry have been analyzed by the Engine. Platform users can also use the Engine to evaluate custom or internal MCP servers that are not in the public registry.
┌─────────────────────────────────────────────────────────────┐
│ OCELLUS │
├───────────────────┬───────────────────┬─────────────────────┤
│ REGISTRY │ PLATFORM │ AGENT │
│ │ │ │
│ Security scores │ Governance & │ Runtime visibility │
│ Hash lookups │ Policy engine │ Protocol tracking │
│ Tool metadata │ Audit logging │ File monitoring │
│ │ │ │
├───────────────────┴───────────────────┴─────────────────────┤
│ OCELLUS ENGINE │
│ Detection & Analysis for MCP Security │
└─────────────────────────────────────────────────────────────┘
Pillar 1: The Ocellus Registry
The Problem: Developers discover MCP tools through GitHub searches, Twitter recommendations, and npm listings. There is no way to know if a tool has been security reviewed.
Our Solution: A registry of analyzed MCP tools with comprehensive security metadata. The registry uses hash based lookups to quickly identify known tools and retrieve their security analysis.
What the Registry Provides
Security Scoring
Every tool in the registry receives a security score based on: - Static code analysis for dangerous patterns and obfuscated code - Permission analysis to determine what access it actually needs - Dependency audit including transitive vulnerability analysis - Maintenance health to check if the tool is actively maintained
Detailed Analysis Reports
For each tool in the registry, you get a comprehensive security breakdown:
┌─────────────────────────────────────────────────────────────┐
│ [MCP Server Name] Score: X.X │
├─────────────────────────────────────────────────────────────┤
│ Permissions Requested: │
│ ├── Filesystem: [Access Level] (Risk Rating) │
│ ├── Network: [Access Level] │
│ └── Exec: [Enabled/Disabled] │
│ │
│ Security Findings: │
│ ├── [SEVERITY] Finding description │
│ ├── [SEVERITY] Finding description │
│ └── [INFO] Compliance notes │
│ │
│ Dependency Analysis: │
│ ├── Direct: N packages (vulnerability count) │
│ └── Transitive: N packages (vulnerability count) │
│ │
│ Behavioral Notes: │
│ └── Observed behavior patterns │
└─────────────────────────────────────────────────────────────┘
Tool Discovery
When you submit a tool hash to the registry, you get immediate visibility into whether that tool has been previously analyzed and what security concerns exist. This helps teams make informed decisions before deploying MCP tools into their environments.
Registry in Action
The registry exposes a simple API for tool lookups:
# Submit a tool hash for analysis
POST /api/registry/lookup
{
"hash": "sha256:abc123..."
}
# Response includes security metadata
{
"status": "known",
"security_score": 7.2,
"risk_level": "medium",
"findings": [...]
}
You can also explore the registry through our web interface at registry.ocellus.dev.
Pillar 2: The Ocellus Platform
The Problem: Even with vetted tools, enterprises need governance. Who can install what? What data can tools access? How do you audit usage?
Our Solution: A centralized platform for policy enforcement, monitoring, and deployment management.
Policy Engine
Define granular policies that match your security requirements:
# ocellus-policy.yaml
policies:
- name: "engineering-team"
rules:
# Only allow tools with score > 7
- condition: "tool.security_score >= 7"
action: "allow"
# Block tools with exec permissions
- condition: "tool.permissions.exec == true"
action: "deny"
# Require approval for network access
- condition: "tool.permissions.network == true"
action: "require_approval"
approvers: ["security-team@company.com"]
# Restrict filesystem access to project directories
- condition: "tool.permissions.filesystem == true"
action: "scope"
allowed_paths: ["$PROJECT_ROOT", "$HOME/.config"]
Policies can be: - Team specific: Different rules for engineering vs. finance - Environment specific: Stricter in production, flexible in development - Role based: Junior developers need approval, seniors self service - Temporal: Allow experimental tools during hackathon week
Policy Evaluation and Logging
The platform tracks what is happening across your MCP deployment:
Policy Engine: - Evaluate tool requests against defined rules - Track policy violation attempts - Record approval workflows
Audit Logging:
Every MCP operation can be logged with: - Timestamp - User and session identity - Tool identifier - Operation type - Resources accessed - Policy evaluation result
{
"timestamp": "2025-01-15T10:23:45Z",
"user": "developer@company.com",
"tool": "[tool-name]",
"operation": "read_file",
"resource": "/path/to/resource",
"policy_result": "allowed",
"risk_score": 2.1
}
Pillar 3: The Ocellus Agent
The Problem: Static analysis tells you what a tool could do. But what is it actually doing when it runs?
What We've Built: The Ocellus Agent provides runtime visibility into MCP operations:
- Protocol monitoring: Observing MCP interactions between clients and servers in real time using native OS instrumentation (DTrace on macOS, eBPF on Linux, ETW on Windows)
- File monitoring: Tracking filesystem access by MCP tools as it happens
- Tampering detection: Verifying file integrity through hash based monitoring to detect unauthorized modifications
- Quarantine system: Isolating suspicious tools while preserving evidence for analysis
This gives you visibility into what tools are actually doing, not just what their code suggests they might do. The agent works across all major platforms, using the most efficient instrumentation available on each operating system.
On Our Roadmap: - Behavioral baselines: Learning what "normal" looks like for each tool - Anomaly detection: Alerting when behavior deviates from expectations
Static analysis and runtime monitoring work together. The registry helps you vet tools before installation. The agent helps you see what they do after.
The Ocellus Difference
Built for MCP, Not Retrofitted
Unlike traditional security tools trying to adapt to MCP, Ocellus was designed from day one for the unique challenges of AI tool security:
| Challenge | Traditional Tools | Ocellus |
|---|---|---|
| Protocol Understanding | HTTP/TCP only | Native MCP support |
| Permission Analysis | Binary allow/deny | Granular, contextual |
| Supply Chain | Package scanning | Full tool analysis |
| Security Metadata | None for MCP | Purpose built scoring |
Security Without Friction
We know that security tools only work if developers actually use them:
- Transparent operation: No workflow changes required
- Fast analysis: Security scores in seconds, not hours
- Developer experience: API first design with web interface and documentation
- Clear guidance: Actionable recommendations, not just "blocked"
What We're Seeing in the Ecosystem
As we've been exploring the MCP landscape, several concerning patterns have emerged:
- Broad permission requests are the norm: Many tools request full filesystem access when scoped access would suffice
- Execution capabilities are common: Tools frequently include the ability to run arbitrary system commands
- Dependency chains are deep and unaudited: Transitive dependencies introduce hidden risk that's difficult to trace
- Maintenance varies wildly: Many tools show signs of abandonment or inconsistent updates
- Security documentation is rare: Few tools explain their permission requirements or security model
These patterns mirror what we saw in the early days of npm and Docker Hub. Those ecosystems later experienced significant supply chain attacks.
In upcoming posts, we'll share deeper analysis of specific MCP tools and the security issues we've uncovered. The goal isn't to name and shame. It's to raise awareness about the types of risks that exist so developers and security teams can make informed decisions.
Key Takeaways
-
Traditional security tools can't protect against MCP threats. They operate at the wrong layer of abstraction.
-
The MCP ecosystem needs purpose built security. Retrofitted solutions won't cut it.
-
Ocellus provides three pillars of protection:
- Registry: Know what you're installing
- Platform: Control what can run
-
Agent: See what tools actually do
-
Security doesn't have to slow you down. Ocellus is designed with developer experience in mind.
-
The time to act is now. MCP adoption is accelerating faster than defenses.
What's Next
This is just the beginning. In the coming weeks, we'll share:
- Week 3: Deep dive into MCP tool security patterns we've observed
- Week 4: Technical analysis of how malicious MCP servers could exfiltrate data
- Week 5: The shadow IT challenge of MCP adoption
- Week 6: Building security into your MCP deployment workflow
Get Involved
We're building Ocellus in the open and looking for feedback from the security community. If you're:
- Deploying or planning to deploy MCP tools
- Concerned about AI supply chain security
- A security researcher interested in MCP threats
- An organization looking for visibility into AI tool usage
We want to hear from you. Join the waitlist to get early access as we roll out new capabilities.
Take Action Today
Join the Waitlist to get early access as we launch
Explore the Registry to browse our MCP tool security analysis
Try the Demo to see Ocellus in action
About Ocellus
Ocellus is the first comprehensive security platform designed specifically for Model Context Protocol tools. We're building the visibility, governance, and protection that organizations need to safely adopt AI assistants.
Founded by security engineers who recognized the critical gap in MCP security while exploring the ecosystem, we're building the security layer that should have existed from day one.
Last week: "The Hidden Danger in Your AI Infrastructure: MCP Supply Chain Attacks"
Next week: A deeper look at MCP security patterns and what they reveal about the ecosystem