Security overview

How API keys are handled

Pilotbot connects to Binance and Bybit through API keys that you create yourself, in your own exchange account. The only permission the product needs is the one that lets it read your advertisements and change their price. Withdrawal permission is never requested and is not used by any code path — if a key with withdrawal rights is supplied anyway, nothing in the platform would call those endpoints. This is the single most important property of the design: even in the worst case, where an attacker obtains a stored key, that key cannot move funds out of your exchange account.

Keys are encrypted at rest with AES-256-GCM before they reach the database. The encryption key itself lives outside the database, is loaded into the worker processes at start-up, and is rotated independently of application deploys. Decrypted key material exists only in the memory of the process that is about to sign an exchange request. It is never written to logs, never returned by an API response, and never rendered into a page — the interface shows a masked fragment so you can tell two keys apart, and nothing more.

What the automation is allowed to do

A trading automation that can set any price is a liability, no matter how well its credentials are protected. Pilotbot therefore constrains the output of the pricing engine before it ever becomes an exchange request. Three boundaries apply to every single price decision:

• Hard corridor. An absolute cap on how far a price may deviate from the reference rate. It is enforced in the worker after every calculation and is not user-configurable upward. No strategy, no manual override and no artificial-intelligence decision can push a price through it.
• Soft corridor. Your own preferred operating range, narrower than the hard corridor. Normal trading happens inside it.
• Fallback price. When the market moves outside your soft range, the engine snaps to a defined safe boundary rather than chasing the market or leaving a stale price in place.

Every write to an exchange is also idempotent and ownership-fenced: a repeated or delayed job cannot apply the same change twice, and two worker processes cannot both believe they own the same advertisement. Read more about the mechanics in how pricing works.

Account access

Accounts support passkeys (the FIDO2 / WebAuthn standard, where the private key never leaves your device and there is no shared secret a server breach could expose) and time-based one-time-password two-factor authentication. Sessions are bound to short-lived access tokens with silent renewal, so an intercepted token has a narrow window of use.

Inside a team, access is role-based: owners, operators and viewers see and can change different things, and the boundary is enforced on the server for every request rather than by hiding buttons in the interface. Database rows are additionally protected by row-level security policies, so a query that somehow escaped the application layer still cannot read another tenant's data. See roles and permissions and two-factor authentication.

Transport and browser hardening

The public site and the application are served over HTTPS only, with HTTP Strict Transport Security advertised for two years including subdomains. Every response carries a Content-Security-Policy that restricts which origins may supply scripts, styles, frames and network connections; framing is denied outright, so the interface cannot be embedded in a third-party page for a click-jacking attack. A Permissions-Policy switches off device capabilities the product does not use — microphone, geolocation, USB, motion sensors — and allows camera access only on the hosted identity-verification screen, where the browser still asks you for permission separately.

Infrastructure and operations

The platform runs on dedicated infrastructure under a process manager that restarts a failed worker automatically, with an external watchdog that detects a process which is technically alive but no longer doing work. Health checks, structured logs and metrics cover the pricing cycle end to end, so a stalled price is an alert rather than something a trader discovers hours later.

Requests are rate-limited per account and per endpoint. Calls to exchanges pass through circuit breakers with exponential back-off, so a degraded exchange slows the system down instead of triggering a storm of retries that would get the account throttled. Backups are taken on a schedule and restore procedures are exercised, not assumed.

Organisational practice

Production access is limited to the engineers who operate the platform and requires two-factor authentication. Changes reach production through review, automated type checking and an automated test suite; database migrations are applied in a defined order with a documented rollback path. Dependencies are monitored for published vulnerabilities, and secrets can be rotated without redeploying the application.

What Pilotbot deliberately does not do

• It does not request or use withdrawal permissions.
• It does not custody your funds — assets stay in your exchange account at all times.
• It does not ask for your exchange password or your exchange two-factor codes.
• It does not sell or share trading data with third parties.
• It does not log decrypted key material, anywhere, at any log level.

Reporting a problem

If you believe you have found a vulnerability, please use the coordinated disclosure process rather than the public contact form, so the report reaches the right people immediately and without a public trail. For a deeper technical treatment, see the security whitepaper; for what data is collected and how long it is retained, see the privacy policy and the data processing agreement.