Security Model
Technical architecture of the Lethal Trifecta protection.
Edison Watch prevents data exfiltration by detecting and blocking the combination of capabilities required for an attack.
The Threat: Prompt Injection
AI agents are vulnerable to prompt injection-malicious instructions hidden in external content (like a web page or file) that manipulate the AI into exfiltrating sensitive data.
The Lethal Trifecta
Exfiltration requires three capabilities. Edison Watch tracks these via per-session monotonic flags:
| Capability | Security Flag | Action |
|---|---|---|
| Private Data Access | read_private_data | AI reads internal files, DBs, or docs. |
| Untrusted Content | read_untrusted_public_data | AI fetches data from the internet. |
| External Communication | write_operation | AI sends data out (Slack, Email, APIs). |
Enforcement Logic: If a session has accessed both Private Data AND Untrusted Content, any subsequent External Communication is paused for human approval.
Session State
State is tracked in the Edison server and is monotonic: once a flag is set (e.g., Private Data accessed), it cannot be unset for that session. This prevents "reset" attacks.
Access Control Levels (ACL)
ACLs prevent sensitive data from flowing to lower-sensitivity destinations regardless of the Trifecta state.
| Level | Rule |
|---|---|
| PUBLIC | Can flow anywhere. |
| PRIVATE | Cannot flow to PUBLIC. |
| SECRET | Cannot flow to PRIVATE or PUBLIC. |
Example: If an agent reads a database marked SECRET, it is immediately blocked from posting to a PUBLIC Slack channel.
Data Tracking
| Data Type | Logged | Retention (Default) |
|---|---|---|
| Tool Calls | Metadata & Params | 90 Days |
| Results | Truncated Output | 90 Days |
| Security Events | Flag changes & Blocks | 1 Year |
| Approvals | User decisions | 1 Year |
Privacy: Raw file contents and full conversation histories are not tracked or stored on Edison servers.
Transport & Auth
- Auth: HMAC-signed API keys or SAML 2.0/OIDC.
- Transport: TLS 1.2+ mandatory.
- Isolation: Clients communicate only with the Edison server; no direct client access to MCP backends.
Dependency Pinning
Edison Watch prevents supply-chain attacks by automatically pinning MCP server dependencies on first run.
Purpose
MCP servers installed via package runners (npx, uvx) can be vulnerable to supply-chain attacks if dependencies are updated maliciously. Pinning ensures:
- Reproducible execution: Same exact code runs every time
- Tamper resistance: Lockfiles are stored securely and cannot be modified without admin action
- Version control: Exact package versions are locked, preventing unexpected updates
How It Works
-
First-Run Resolution: When a server using
npxoruvxis first mounted, Edison Watch:- Resolves the full transitive dependency graph
- Generates a lockfile (npm:
package-lock.json, Python:uv.lock) - Stores the lockfile in the local SQLite database (
sessions.db)
-
Ephemeral Runtime: On each mount:
- Creates a temporary runtime directory
- Installs dependencies from the stored lockfile (not from package registries)
- Executes the server from the isolated runtime environment
-
Fail-Closed: If pinning fails (network issues, corrupted lockfile), the server will not start. This ensures no unpinned code executes.
Admin Controls
All pinning management is done through the admin dashboard:
- View Status: See pinned package versions and dates in server overview
- Clear Pin: Remove cached lockfile to force re-pinning (useful after package updates)
- Clear All Pins: Bulk operation to clear all server pins
No command-line or environment variable configuration is required-all controls are UI-driven for security and auditability.