Secrets outside configs
API credentials are read from environment storage rather than written into TOML or SQLite state.
Minimum permissions. Explicit operating boundaries.
Risk enforcement requires privileged exchange access. Prop Rails is designed to keep those permissions narrow, separate observation from enforcement, and make protection failures visible.
Permission model
Different modes ask for different authority.
A read-only evaluation should not require the same key as an enforcement service. The product keeps those operational modes distinct.
| Mode | Expected access | State-changing actions | Key principle |
|---|---|---|---|
| Pilot | Read-only | None from the pilot clients | OKX pilot refuses a key with trade permission; the observation path is implemented without state-changing calls. |
| Watch | Read + Trade | Close positions, cancel orders, optional key lock where supported | No withdrawal permission is required for the enforcement workflow. |
| Bench | Read + Trade on dedicated demo account | Creates controlled exposure, then cuts it | Benchmark safety checks refuse unsafe account conditions and verify final state. |
Implementation controls
Protect secrets and fail loudly when protection is unavailable.
The current codebase keeps credentials outside configuration and database files, masks keys in logs, and isolates account startup failure so one account does not silently disable all protection.
Log masking
Sensitive key material is masked in logs instead of echoed during normal diagnostics.
Read-only pilot boundary
Observation code rejects state-changing requests and, on OKX, refuses trade-capable pilot keys.
Protection failure visibility
If one account cannot start, the supervisor reports that the account is not protected and retries with backoff.
Restart persistence
Breach latch and rule state persist so a restart does not automatically re-arm a breached account.
Account isolation
Runtime supervision is structured so a failing account does not have to terminate unrelated account protection.
Post-cut verification
The engine does not assume success from an API acknowledgement; it re-reads and verifies the resulting account state.
No withdrawal requirement
The risk-control workflow is built around trading permissions, not withdrawal authority.
Deployment principle
Security claims should be validated in your environment.
Production deployment should include your own infrastructure review: host hardening, secret store choice, network policy, exchange sub-account design, logging retention, alert routes and incident runbooks.
This page describes controls present in the supplied Prop Rails codebase. It is not a third-party security certification, penetration-test report, or guarantee against exchange, infrastructure or operator failure.
Start with the lowest required permission.
A pilot can establish the baseline before any active enforcement key is considered.