OpenEdison: Building a Data Firewall for AI Agents Using MCP Interception
Hook
AI agents can now read your Slack messages, query your databases, and write to your CRM—all in a single execution loop. What happens when prompt injection convinces one to email your customer list to a competitor?
Context
The Model Context Protocol (MCP) has fundamentally changed how AI agents interact with data. Instead of embedding database credentials or API keys directly into prompts, agents now connect to MCP servers that expose standardized interfaces to Slack, GitHub, PostgreSQL, or any other data source. This architectural shift solves integration complexity but creates a new problem: how do you monitor and control what an agent actually does with that access?
OpenEdison addresses what security researcher Simon Willison calls the “lethal trifecta”—the combination of prompt injection vulnerabilities, tool-calling capabilities, and access to sensitive data. When an agent processes untrusted input (like a malicious email or compromised website content), it might be manipulated into exfiltrating data through seemingly legitimate tool calls. Traditional firewalls can’t help here because the agent’s outbound requests look identical to normal operations. OpenEdison sits between your agent and MCP servers, building a deterministic graph of every data access, applying configurable policies, and blocking suspicious patterns before data leaves your infrastructure.
Technical Insight
OpenEdison’s architecture centers on MCP request interception. When you configure an MCP server in the OpenEdison UI, you’re actually creating a proxy endpoint. Your AI agent connects to OpenEdison instead of directly to the MCP server, and OpenEdison forwards requests while maintaining a complete audit trail of tool invocations and resource accesses.
The integration model uses Python decorators to minimize friction. If you’re building a LangGraph agent, you wrap your tools with @edison.track() and initialize the Edison client:
from langgraph.prebuilt import create_react_agent
from open_edison import Edison
edison = Edison(base_url="http://localhost:3000")
@edison.track()
def query_customer_database(customer_id: str) -> dict:
"""Fetch customer record from PostgreSQL"""
# Your existing database logic
return db.query(f"SELECT * FROM customers WHERE id = {customer_id}")
@edison.track()
def send_email(to: str, subject: str, body: str) -> bool:
"""Send email via SMTP"""
# Your existing email logic
return email_client.send(to, subject, body)
agent = create_react_agent(model, tools=[query_customer_database, send_email])That’s it. No refactoring required. The decorator intercepts each tool call, sends metadata to the OpenEdison server, and receives back a policy decision (allow/block/alert). OpenEdison builds a directed graph where nodes represent tool invocations and edges represent data dependencies. If an agent queries the customer database and then immediately calls send_email with data containing PII patterns, OpenEdison can detect the exfiltration attempt based on configurable rules.
The policy engine supports tool-level and resource-level permissions. You might allow an agent to read from your users table but block writes, or permit Slack channel reads while denying direct message access. Policies are defined in the web UI or via REST API, and they’re evaluated in real-time during execution. The system maintains state across tool calls within a single agent session, enabling pattern detection that simple per-request authorization can’t achieve.
For deployment flexibility, OpenEdison runs as a standalone server (via uvx open-edison or Docker) that provides a REST API for management and acts as an MCP proxy for agent connections. The project uses both TypeScript (as indicated by the repo metadata) and Python components, with the Python SDK providing the decorator interface. This separation means you can deploy OpenEdison once and secure multiple agents across different frameworks—LangGraph, LangChain, or even plain Python scripts—as long as they communicate through MCP or use the tracking decorators.
The deterministic dataflow graph is OpenEdison’s key differentiator from generic API gateways. Instead of treating each MCP request as an isolated event, it builds a causal chain: Tool A read data X, then Tool B was invoked with parameter Y derived from X, then Tool C sent Y to an external endpoint. This temporal awareness enables detection of multi-step exfiltration patterns that would evade stateless security controls. The UI visualizes this graph in real-time, showing you exactly how data flows through your agent’s execution—critical for both security auditing and debugging unexpected agent behavior.
Gotcha
OpenEdison is effective only if your agents communicate through MCP or use the tracking decorators. If you’ve built an agent that directly calls the OpenAI API with function calling and then executes those functions via subprocess or direct HTTP requests, OpenEdison won’t see those interactions. The security perimeter depends entirely on funneling agent-data communication through the proxy.
The GPLv3 license may create considerations for commercial deployments, though specific distribution obligations aren’t detailed in the README. The project offers a commercial license (EdisonWatch) for multi-tenancy and enterprise features. The open-source version is single-user focused—there’s no built-in user management, RBAC, or tenant isolation. If you need to secure agents for multiple teams with different data access policies, you’ll need the commercial EdisonWatch offering or build that layer yourself. Finally, running a proxy adds latency. Every MCP request now requires an extra network hop and policy evaluation. For agents making hundreds of tool calls per minute, that overhead could impact user experience. Note that when running via Docker, the MCP server runs on port 3000 while the API and frontend run on port 3001, which may require adjustment to your configuration.
Verdict
Use OpenEdison if you’re deploying AI agents with MCP access to sensitive data—customer databases, internal APIs, financial records—and you need defense-in-depth against prompt injection or agent hijacking. It’s particularly valuable in regulated industries (healthcare, finance) where you need auditable records of what data an agent touched and why. The decorator-based integration makes it a low-effort addition to existing LangGraph/LangChain workflows. Skip it if your agents don’t use MCP, you’re building simple single-purpose bots with read-only access to non-sensitive data, or you require zero-latency operations where even milliseconds of proxy overhead matter. Also skip if you need multi-tenant capabilities without paying for a commercial license. For teams already concerned about agentic AI security but not ready to rewrite their entire stack, OpenEdison offers a pragmatic middle ground—visibility and control without architectural upheaval.
