Security Assessment¶
System: QuantDinger
Assessment scope: public backend, MCP server, release workflows, and the
documented interfaces to the separately released frontend and mobile clients
Last reviewed: 2026-10-25
Security objectives¶
QuantDinger must protect account identity, broker and exchange credentials, strategy code, trading permissions, order integrity, auditability, and tenant separation. A research result must not silently gain live-trading authority.
Actors and actions¶
| Actor | Permitted actions | Security boundary |
|---|---|---|
| Anonymous user | Read public information and use explicitly public endpoints | No account, strategy, credential, or trading access |
| Authenticated user | Manage owned research, strategies, settings, and connected accounts | Tenant ownership and authorization checks |
| Administrator | Operate the deployment and manage authorized users | Administrative authorization and audit trail |
| Strategy or AI agent | Request only explicitly granted research or execution operations | Tool registry, execution policy, risk limits, and credential isolation |
| Broker or data provider | Return market/account data and accept authorized requests | Approved endpoint, TLS, provider authentication, and request validation |
| CI/release workflow | Test, scan, build, attest, sign, and publish releases | Minimal GitHub token permissions and protected secrets |
The detailed runtime components and data flows are documented in the architecture guide, while public HTTP interfaces are defined by the committed OpenAPI specification and Agent Gateway specification.
Primary risks and controls¶
| Risk | Impact | Current controls |
|---|---|---|
| Credential disclosure | Unauthorized account or trading access | Local-first deployment, environment isolation, encrypted stored credentials, secret scanning, log redaction guidance |
| Authentication or authorization bypass | Cross-user access or privilege escalation | Strong deployment secret validation, authoritative database checks, route authorization tests, coordinated disclosure process |
| Untrusted strategy execution | Host compromise or secret access | Restricted execution boundary, process isolation, resource controls, documented trust assumptions |
| Server-side request forgery | Internal network or credential exposure | Approved broker endpoints, URL validation, and provider adapters |
| Incorrect or duplicate orders | Financial loss | Risk limits, idempotency and reconciliation logic, transactional execution accounting tests, paper-trading path |
| Supply-chain compromise | Malicious build or dependency | Pinned Actions and images, Dependabot, pip-audit, CodeQL, Bandit, Gitleaks, CI-built images, provenance, SBOM, and keyless release signing |
| Cross-tenant data leakage | Confidentiality breach | Ownership checks, isolated runtime state, authorization regression tests |
| Unsafe AI output | Unreviewed live-trading action | Typed tool boundaries, permission checks, auditable decisions, and explicit execution controls |
Assessment method¶
The project reviews architecture boundaries, publicly reported vulnerabilities,
dependency findings, static-analysis findings, secret scans, authentication and
authorization tests, and release workflow permissions. Confirmed issues are
triaged under the severity and remediation targets in SECURITY.md.
Residual risk¶
Self-hosted deployments remain responsible for operating-system, network, reverse-proxy, database, and secret-store security. Third-party brokers, exchanges, AI providers, and market-data sources retain their own security and availability risks. QuantDinger does not guarantee strategy profitability or eliminate market risk.