Use this trading API key safety checklist before connecting any external trading tool, sharing support evidence, or mixing paper review with live-account permissions.
Trading Boy does not execute live trades, hold funds, or provide financial advice. A paper-trading workflow can review simulated decisions, journal quality, risk behavior, and AI-agent output without a live exchange API key.
The safest paper-trading key is usually no exchange key at all. If a separate external tool asks for a key, use the checklist below before creating or sharing anything.
| Check | Pass condition | Fail condition | Action |
|---|---|---|---|
| Purpose | The key is not needed for the paper workflow, or the separate tool has a clear read-only need. | The product asks for a key before explaining why paper review needs it. | Use the no-key workflow first. |
| Permission scope | Read-only if absolutely required by a separate external tool. | Trade, withdrawal, transfer, margin, futures, or live order permissions. | Reject the setup for paper review. |
| Storage | The key is stored only in a proper secret manager or exchange tool settings. | The key appears in screenshots, logs, prompts, spreadsheets, or support messages. | Rotate the key and remove the leaked copy. |
| Network restrictions | The exchange supports IP restrictions and the user understands the allowed source. | The key is long-lived and usable from any network. | Prefer no key or tighten restrictions before use. |
| Rotation | The key can be disabled quickly and has a documented owner. | No one knows where the key is used or how to revoke it. | Create a rotation note before any experiment continues. |
| Paper boundary | The paper journal remains separate from live balances and execution. | Paper wins are used as an argument to increase live exposure. | Return to paper-trading limitations and readiness review. |
Scenario: A trader wants to test an AI-assisted paper workflow. A separate bot asks for exchange read, trade, futures, and transfer permissions. The trader has not yet collected a stable paper sample.
Checklist result: The paper workflow does not require live permissions. Trade, futures, and transfer access are unnecessary and create a live-account risk that has nothing to do with simulated journal review.
Decision: The trader does not create the key. They start with paper trading, use AI trading agent permission boundaries, and review the first sample with the AI paper trading agent evaluation checklist.
Use permission labels, not credential values. For example: "The external tool requested trading permission and futures permission; I declined and used a no-key paper workflow." That statement gives reviewers enough context without leaking a secret.
For paper-trading context, share sanitized journal fields from the paper trading data privacy checklist: setup, timeframe, simulated risk, invalidation, result, and review note.
A tightly scoped API key can reduce credential risk, but it cannot prove a strategy is ready for live execution. It says nothing about fill quality, slippage, liquidity, fees, emotional pressure, sample size, market regime, or future returns. Those questions belong in paper review, not in a credential checklist.
Use this page as a gate before any external tool receives access. Then use paper trading results validation, sample size review, and readiness review to decide whether the paper process itself is even consistent enough to discuss.
If a separate external experiment ever requires a read-only key, record the owner, exchange, permission labels, creation date, expected removal date, and the paper workflow it supports. Delete the key when the experiment ends. A key with no owner, no expiry, or no written purpose should be treated as a failed checklist item, even when it has no trade permission.
Paper trading should not need withdrawal, transfer, trade, margin, futures, or live order permissions. A simulated review workflow can usually run without any exchange API key.
No. Do not paste full or partial API keys, secret keys, seed phrases, or recovery codes into support tickets, AI prompts, screenshots, or public pages.
No. Scoped permissions reduce credential risk, but they do not validate strategy quality, live execution, slippage, future returns, or suitability.