OpenEdison - MCP Gateway for Agent Data Security

TL;DR

TL;DR: OpenEdison is an open-source MCP proxy that sits between AI agents and your tools, enforcing tool/resource/prompt permissions and alerting when agents access private data, untrusted content, or attempt external writes.

Source and Accuracy Notes

⚠️ This section is MANDATORY. All links must be verified from actual source, not guessed.

• Project page: edison.watch ← MUST visit and verify
• Source repository: github.com/Edison-Watch/open-edison ← MUST read README
• License: GPL-3.0 ← verified from LICENSE file
• HN launch thread: news.ycombinator.com/item?id=44169961 ← MCP Gateway to block the lethal trifecta

What Is OpenEdison?

OpenEdison is a deterministic agentic data firewall. It runs as an MCP proxy between your AI agents and their connected tools — intercepting every tool call, resource access, and prompt to enforce a configurable security policy.

The core insight comes from Simon Willison’s “The Lethal Trifecta” problem: when an AI agent simultaneously has access to (1) private local data, (2) untrusted external content, and (3) the ability to write externally — the risk of data exfiltration or agent hijacking spikes dramatically. OpenEdison tracks and blocks this combination.

It is built in Python (3.12+) and deploys via uvx or Docker. The commercial sibling, EdisonWatch, adds multi-tenancy, SSO, and SIEM integration.

Setup Workflow

Prerequisites

• Python 3.12 or later
• uv package manager (Astral’s fast Python tool installer)
• Optionally: Docker for containerized deployment

Step 1: Install

The fastest install path uses the official installer script:

curl -fsSL https://raw.githubusercontent.com/Edison-Watch/open-edison/main/curl_pipe_bash.sh | bash

This installs uv and launches OpenEdison via uvx. If you need npx-based MCP tools, also install Node.js:

# macOS
brew install node

# Linux
sudo apt-get update && sudo apt-get install -y nodejs npm

# Windows
winget install -e --id OpenJS.NodeJS

Or install from PyPI directly:

uvx open-edison

Step 2: Configure Permissions

OpenEdison enforces three permission files:

tool_permissions.json — classify MCP tools by access level:

{
  "_metadata": { "last_updated": "2025-08-07" },
  "filesystem": {
    "read_file": { "enabled": true, "write_operation": false, "read_private_data": true, "read_untrusted_public_data": false, "acl": "PRIVATE" },
    "write_file": { "enabled": true, "write_operation": true, "read_private_data": true, "read_untrusted_public_data": false, "acl": "PRIVATE" }
  }
}

resource_permissions.json — control resource access patterns (e.g., file:*, https://*).

prompt_permissions.json — classify prompt types by risk level.

All three support wildcard patterns: server_name/* for tools, scheme:* for resources, type:* for prompts.

Unknown tools/resources/prompts are denied by default — a secure-by-default posture.

Step 3: Run

uvx open-edison

Docker deployment:

docker run -p 8080:8080 -v ./config:/app/config ghcr.io/edison-watch/open-edison

Step 4: Integrate with Python Agents

Add the @edison.track() decorator to your tools or agent functions for immediate observability and policy enforcement:

import open_edison as edison

@edison.track()
def read_customer_database(query):
    # This call is now monitored and permission-controlled
    return db.execute(query)

OpenEdison integrates with LangGraph and LangChain out of the box.

Deeper Analysis

The Lethal Trifecta Problem

OpenEdison tracks three concurrent risk flags per agent session:

1. Private data access — reading local files, databases, or private configs
2. Untrusted content exposure — processing external/web content that could be adversarial
3. External communication — ability to write or send data outside the system

When all three are active simultaneously, OpenEdison blocks further potentially dangerous operations and surfaces an alert via the get_security_status tool.

Security Model

Each tool call is evaluated against:

• Whether it is enabled/disabled
• Whether it is a write operation
• Whether it reads private data
• Whether it reads untrusted public data
• Its ACL level: PUBLIC, PRIVATE, or SECRET

If a write operation targets a lower ACL level than the session’s current maximum, it can be blocked per configuration.

Comparison with Other MCP Gateways

The project maintainers publish a comparison blog positioning OpenEdison against alternatives like Wombat, MCPJungle, and other MCP security tools.

Practical Evaluation Checklist

• Does it run behind a corporate firewall without external calls? (Docker image available)
• Is the permission model flexible enough for real-world tool sets? (wildcard support, three permission layers)
• Does it integrate with LangGraph/LangChain without invasive code changes? (@edison.track() decorator)
• Are unknown tools denied by default? (Yes — secure baseline)
• Is the commercial tier needed for team use? (Yes — OpenEdison is single-user, EdisonWatch adds multi-tenancy)

Security Notes

• Default-deny on unknown tools — any MCP tool not in tool_permissions.json is rejected
• ACL per tool — granular PUBLIC/PRIVATE/SECRET classification
• Lethal trifecta detection — cross-checks all three risk vectors simultaneously
• Session-level tracking — get_security_status exposes current risk posture at any point
• Docker isolation — run in a container to limit host filesystem access
• GPL-3.0 source — auditable security implementation

FAQ

Q: What is the difference between OpenEdison and EdisonWatch? A: OpenEdison is the open-source single-user MCP security proxy. EdisonWatch adds multi-tenancy, SSO, SIEM integration, and client-side auto-enforcement for team deployments.

Q: Does OpenEdison work with non-Python agents? A: The core proxy runs as an MCP server that any MCP-compatible agent (Claude Desktop, Cursor, etc.) can connect to. The Python @edison.track() decorator is optional for deeper LangGraph/LangChain integration.

Q: Can it block all external network calls? A: It classifies https:// resources in resource_permissions.json and can deny access based on configuration. External write operations (e.g., sending data to a third-party API) are controlled via the write-operation flag on tools.

Q: How is the lethal trifecta different from normal tool permissions? A: Normal tool permissions evaluate each call in isolation. The lethal trifecta tracks the combination of three concurrent risk conditions across a session — even if each individual tool call is authorized, the combination triggers a higher-risk state.

Conclusion

OpenEdison addresses a real gap in the MCP ecosystem: with hundreds of tools now accessible to AI agents, there is no standard way to enforce least-privilege access or detect when an agent’s combined capabilities create a data exfiltration risk. It is not a full SIEM or zero-trust network tool — it is purpose-built for the MCP layer, and the @edison.track() integration means even existing LangGraph agents can adopt it with a single decorator. If you are deploying AI agents that touch production data, OpenEdison is worth evaluating as a security boundary at the tool-call level.