Securing API keys and exchange credentials

A trading bot is only as trustworthy as the credentials it carries. An exchange API key that can trade and withdraw is, in the wrong hands, a direct line to someone else’s balance. Yet keys are routinely committed to repositories, pasted into chat, baked into container images, and handed the broadest possible permissions "to keep things simple". The discipline of credential hygiene is unglamorous and, when it fails, catastrophic.

§01Scope to the minimum

The first principle is least privilege. A key that only needs to place and cancel orders should never carry withdrawal permission — most venues let you disable it, and you should. Where the exchange supports it, bind keys to a fixed set of source IP addresses so a stolen key is useless from anywhere but your own infrastructure. Separate read-only keys for monitoring from the trading keys that can move risk. The goal is that no single leaked credential can both act and exfiltrate.

§02Store secrets like secrets

Credentials do not belong in source control, environment files checked into a repo, or a plaintext config on a shared box. They belong in a dedicated secrets manager or hardware-backed store, injected at runtime, never written to disk in the clear. Container images and log lines are two of the most common places a key quietly escapes; scrub both. Assume every log aggregator and crash dump is a place a secret can leak, and design so it cannot.

§03Rotate, and be ready to revoke

Keys should have a lifecycle: created, rotated on a schedule, and revocable in seconds. Rotation only works if it is automated and rehearsed — a rotation procedure you have never run is a procedure that will fail during the incident. Equally important is detection: alert on credential use from an unexpected address or at an unexpected rate, because the first sign of compromise is often a key doing something slightly wrong before it does something disastrous.

§04Assume breach

Mature security does not assume the perimeter holds; it assumes a key will eventually leak and limits the blast radius in advance. Withdrawal disabled, IP-bound, tightly scoped, monitored, and quick to revoke — a key with all five properties turns a compromise from an emergency into an inconvenience. This advisory is educational and illustrative and is not security or investment advice for any specific deployment.