Security Model

Threat Model

All communication is localhost-only. No data leaves the machine.

User's Machine (trust boundary)
├── Claude Code (LLM agent, local)
├── MCP Server (Node.js, local, stdio)
├── Chrome + CDP (localhost:9222)
├── TradingView (web app in Chrome)
└── Dashboard (localhost:8000)

What the System Does NOT Do

1. Connect to TradingView servers directly (all access via local Chrome)
2. Store or redistribute market data
3. Bypass TradingView authentication
4. Execute real trades (Paper Trading / replay only, until broker layer is built)
5. Access other users' data
6. Send data to external services

Input Validation

Layer	Mechanism
MCP Tool Parameters	Zod schema validation
CDP JavaScript Injection	safeString() — JSON.stringify escaping
Numeric Parameters	requireFinite() — blocks NaN/Infinity
CLI Arguments	node:util parseArgs strict mode

Risks

CDP is Powerful

The Chrome DevTools Protocol gives full control over the page. ui_evaluate can run arbitrary JavaScript. This is necessary for the system to work, but means: - Any tool can read page content (including session tokens) - Any tool can modify page state - ui_evaluate has no sandboxing

Mitigation: All tools run locally by the user. No remote access.

Undocumented APIs

The system depends on internal TradingView JavaScript objects that can change. This is a stability risk, not a security risk.

Broker Credentials (Future)

When broker API tools are added, credentials must be: - Stored in environment variables, not code - Never logged or returned in tool output - Scoped to minimum required permissions - Demo/paper environment by default