OpenEdison - MCP Gateway for Agent Data Security

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

What it is

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 motivation 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 is purpose-built to detect and block that combination.

It’s written in Python (3.12+) and deploys via uvx or Docker. The commercial sibling, EdisonWatch, adds multi-tenancy, SSO, and SIEM integration for teams that need a managed version.

Getting it running

The fastest path uses the official installer script:

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

That installs `uv` and launches OpenEdison via `uvx`. If you have MCP tools that need Node.js, install it separately:

```bash
# macOS
brew install node

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

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

Or run directly through PyPI without the installer:

```bash
uvx open-edison
```bash

A Docker image is also published for containerized deployment:

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

## Configuring permissions

OpenEdison enforces three permission files that classify what an agent is allowed to do:

**`tool_permissions.json`** decides which MCP tools are usable. A typical entry marks read/write operations, whether the tool touches private data, and an ACL level:

```json
{
  "_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" }
  }
}
```bash

**`resource_permissions.json`** controls resource access patterns (e.g., `file:*`, `https://*`). **prompt_permissions.json** classifies prompt types by risk level. All three support wildcards: `server_name/*` for tools, `scheme:*` for resources, `type:*` for prompts.

Unknown tools, resources, or prompts are denied by default. That's a deliberate secure-by-default stance — you opt in to new capabilities rather than discovering later that an agent picked them up.

## Wiring it into Python agents

For LangGraph and LangChain codebases, the `@edison.track()` decorator adds immediate observability and policy enforcement to any tool or agent function:

```python
import open_edison as edison

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

That one-line change is the most useful integration path if you already have a Python agent stack — no need to rewrite tool registration.

How the lethal trifecta actually gets detected

Every agent session carries three concurrent risk flags tracked independently:

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

The interesting part is what happens when all three are active simultaneously. Each individual tool call might be authorized in isolation, but the combination triggers a higher-risk state. OpenEdison blocks further potentially dangerous operations and surfaces an alert via the get_security_status tool. That combination logic is what distinguishes it from a normal permission system — most ACL models evaluate calls in isolation, not as a session-level risk posture.

Each tool call is also evaluated against five criteria: enabled/disabled status, write operation flag, private data read flag, untrusted public data read flag, and an 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 your configuration.

How it compares to other MCP gateways

The project maintainers publish a comparison blog positioning OpenEdison against Wombat, MCPJungle, and other MCP security tools. The core differentiation is the lethal-trifecta tracking layer — most MCP gateways treat each tool call as an isolated decision, which misses the combination risk.

When it makes sense

OpenEdison is single-user in the open-source version. If you need multi-tenancy, SSO, or SIEM integration, that’s the EdisonWatch commercial tier.

For self-hosted deployments, the Docker image lets you run the proxy behind a corporate firewall with no external calls. The GPL-3.0 source is auditable — useful if you’re in a regulated environment that needs to verify the security implementation yourself.

If your agents touch production data, OpenEdison is worth evaluating as a security boundary at the tool-call layer. It’s not a full SIEM or zero-trust network tool — it sits at the MCP layer specifically, which is where the lethal-trifecta risk actually manifests.

Source and Accuracy Notes

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