Skip to content

Threat model

The protected assets are the operator’s brokerage capital, immutable approvals, order/fill state, emergency controls, AI and broker credentials, local financial history, and audit evidence. The primary objective is that untrusted prose, model output, market/broker data, browser origins, process races, or ambiguous networks cannot create unauthorized or unbounded exposure.

  • prose/model output → strict schema/validator → explicit acceptance/backtest/approval;
  • approved deployment → persisted intent → deterministic risk → user confirmation;
  • Jorli → installed Kite/Dhan subprocess; broker credentials never enter Jorli;
  • broker order/trade/position/depth responses → typed parsers and reconciliation;
  • untrusted Kite/Dhan WebSocket frames → protocol parsers → sequence/stale/checkpoint gate → mandatory CLI account/order/trade/position resynchronization;
  • browser → loopback API with host checks, CSP, no-store, confirmation, and random header token;
  • application → owner-local SQLite/conversation files and native OS keyring;
  • source/CI → self-contained binary and bundled Angular content.
  • Strategy/model injection cannot execute code or mutate a broker; only the small EMA/ATR schema is executable and live entries need two explicit approvals.
  • Shell injection is constrained by ArgumentList, no shell execution, private JSON payloads, timeouts, and typed responses.
  • Concurrent cross-broker confirmations are bounded by fresh aggregated snapshots and an atomic SQLite entry reservation.
  • Race-time fills after kill/pause still receive fill-delta stop-market protection.
  • Remote sites cannot read the dashboard mutation token; a same-user local process is already inside the OS-user trust boundary.
  • Likely keys/tokens/passwords/PIN/TOTP are rejected before chat reaches model or disk.
  • Direct-stream credentials stay in the native OS secret store, connect failures are sanitized, and stream events can never invoke a broker mutation.
  • Critical: approval/risk/confirmation bypass to live mutation; broker/AI secret leakage; unbounded duplicates; systematic unprotected fills; strategy/CLI/update code execution.
  • High: cross-account approval confusion, risk-increasing kill bypass, silent cancellation failure, loopback mutation bypass, or restart state corruption causing duplicate exposure.
  • Medium: bounded stale-data entry changes, local financial-data ACL exposure, helper-process denial of service, or material audit gaps.
  • Low: local UI metadata/cosmetic issues with no secret, mutation, or built-runtime path.

The full reusable repository threat model is maintained with the Jorli Agent source under jorli-agent/docs/threat-model.md.