OpenEdison: A Security Proxy for AI Agents That Access Your Data

Hook

Your AI agent just accessed your customer database, scraped 10,000 records, and sent them to an LLM API. Did you notice? Would you even know?

Context

The rise of agentic AI has created what security researchers call the 'lethal trifecta': AI agents with tool-calling capabilities, access to sensitive company data, and the autonomy to make decisions about what information to retrieve and transmit. Unlike traditional applications where data access patterns are deterministic and auditable, agents make runtime decisions based on LLM reasoning—decisions that are often opaque, unpredictable, and difficult to monitor.

The Model Context Protocol (MCP) from Anthropic has emerged as a standardized way for AI agents to interact with data sources and tools. While MCP provides a clean interface between agents and systems of record, it doesn't inherently solve the security challenge: once you connect an agent to an MCP server exposing your CRM, database, or file system, you've granted access with little visibility or control over what gets read and transmitted to LLM providers. OpenEdison addresses this gap by functioning as a security gateway—a proxy that sits between your agents and MCP servers, intercepting every request to enforce policies, detect exfiltration patterns, and provide observability into agent behavior.

Technical Insight

OpenEdison's architecture is built around the proxy pattern, positioning itself as a transparent intermediary in the MCP communication flow. When you deploy OpenEdison, it exposes MCP protocol endpoints that agents connect to, while it maintains connections to the actual MCP servers on the backend. This allows OpenEdison to inspect, validate, and potentially block every tool invocation and resource access before it reaches your data.

Integration with existing agent frameworks is remarkably lightweight. For LangGraph-based agents, OpenEdison provides a decorator-based instrumentation approach that requires minimal code changes:

import { edison } from '@edison-watch/client';
import { StateGraph } from '@langchain/langgraph';

const workflow = new StateGraph({
  channels: { messages: [] }
});

// Wrap your agent execution with Edison tracking
@edison.track({
  mcpServers: ['salesforce-mcp', 'postgres-mcp'],
  policies: {
    'salesforce-mcp': {
      allowedTools: ['query_contacts', 'search_accounts'],
      deniedResources: ['sensitive_fields/*']
    }
  }
})
async function runAgent(input: string) {
  const result = await workflow.invoke({
    messages: [{ role: 'user', content: input }]
  });
  return result;
}

Under the hood, the @edison.track() decorator reconfigures your agent's MCP client connections to route through OpenEdison's proxy endpoints instead of directly to MCP servers. The policies configuration defines what each MCP server can do—which tools the agent is allowed to invoke and which resources it can access. When your agent attempts to call a tool or read a resource, OpenEdison evaluates the request against these policies before forwarding it.

The policy engine supports pattern-based resource filtering using glob syntax, allowing you to express rules like 'allow access to customer records but deny SSN fields' or 'permit read operations but block deletions.' Policy violations generate events that flow into OpenEdison's observability layer, which maintains an audit trail of all agent-data interactions. This is exposed through both a web UI for real-time monitoring and REST APIs for programmatic access.

Data exfiltration detection operates on heuristics rather than simple access control. OpenEdison monitors patterns like unusually large data retrievals, rapid sequential queries across sensitive resources, or access to data unrelated to the user's stated task. These signals feed into a scoring system that can trigger alerts or automatically throttle agent behavior when anomalies are detected.

Deployment flexibility is a key design consideration. OpenEdison can run as a standalone service via Docker, making it trivial to add to existing infrastructure:

docker run -p 8080:8080 \
  -v ./config.yaml:/config.yaml \
  -e EDISON_CONFIG=/config.yaml \
  edisonwatch/open-edison

The configuration file defines MCP server connections, policy rules, and observability settings. For Python-heavy environments, installation via pip or uvx provides a more native experience. The system uses a Python backend (FastAPI) for the core proxy logic and policy enforcement, with a TypeScript/React frontend for the management UI—a pragmatic choice that leverages Python's dominance in AI tooling while providing a modern web interface.

What sets OpenEdison apart from general LLM observability platforms is its MCP-native design. Rather than trying to trace LLM calls after the fact, it operates at the protocol level where agent-data interactions occur. This gives it semantic understanding of what tools are being invoked and what resources are being accessed, enabling more precise policy enforcement than generic API monitoring could achieve.

Gotcha

OpenEdison's open-source version is explicitly single-user, which means it's unsuitable for organizations needing to support multiple teams or implement role-based access controls. Features like multi-tenancy, SSO integration, SIEM connectors, and advanced compliance reporting are gated behind the commercial EdisonWatch offering. This is a reasonable open-core business model, but teams evaluating the open-source version should understand they're essentially getting a proof-of-concept that will require upgrading for production use in most enterprise contexts.

The proxy architecture introduces a point of failure and latency overhead in your agent's critical path. Every MCP call now requires an additional network hop through OpenEdison, and if the proxy goes down, your agents lose access to data sources. For latency-sensitive applications—particularly agents that make many small, rapid tool calls—this overhead can degrade user experience. The project is young (278 stars) and while the core concept is sound, you should expect limited community support, potential bugs, and documentation gaps compared to more mature projects. Production deployments will likely require running your own fork and contributing fixes upstream.

Verdict

Use OpenEdison if you're building AI agents that access sensitive company data, need compliance audit trails, or operate in regulated industries where data governance is non-negotiable. It's particularly valuable when deploying agents that interact with systems of record (CRM, databases, HR systems) where the risk of data exfiltration outweighs the cost of proxy latency. The decorator-based integration makes it low-friction enough to adopt incrementally—you can start with monitoring before enforcing strict policies. Skip it if you're building simple prototypes without production data access, need ultra-low latency (sub-100ms response times), or require enterprise features like SSO and multi-tenancy—in those cases, either evaluate the commercial EdisonWatch product or build custom middleware directly into your agent framework. Also skip if you're not using MCP; this tool is protocol-specific and won't help with agents using custom APIs or other communication patterns.