PositionPilot.pro
Request DemoJoin access

Security

You keep custody. PositionPilot uses restricted exchange access.

PositionPilot connects to supported exchanges through dedicated API keys with withdrawals disabled for ordinary spot workflows. Credentials are handled inside a dedicated security boundary, and trading-enabled access is tied to user-approved position workflows.

Designed for account-connected position workflows through supported exchanges.

Explore the productRequest walkthrough

Restricted access model

User account, restricted key, secure credential layer and approved workflow

User exchange account

Assets remain on the supported exchange account

Restricted API key

Account-read and spot-trading permissions only where needed

Secure credential layer

Encrypted envelopes, opaque references and audited resolve paths

Position workflow

Trading actions belong to the approved position workflow

Runtime access / Audit trail

Every approved workflow call keeps a lifecycle and audit context.

Withdrawals disabled

Raw credentials hidden

Disable, revoke, rotate

Security model

Exchange access is restricted, isolated and tied to approved workflows.

PositionPilot connects to supported exchange accounts through dedicated no-withdrawal API keys, encrypted credential envelopes, opaque credential references and audited runtime access.

Read the full explanation

PositionPilot does not take custody of user assets. Users keep assets on their own supported exchange accounts. To connect account data and execute approved spot workflow actions, PositionPilot may ask the user to create a dedicated exchange API key.

That key should use least-privilege permissions: account-read where needed, spot-trading only where needed, withdrawals disabled, and no margin, futures, transfer or withdrawal permissions unless a future reviewed product scope explicitly supports them. Withdrawal-disabled keys reduce withdrawal exposure, but they do not remove trading risk: trading-enabled API access can place or cancel spot orders inside the approved workflow.

Example

A user creates a dedicated Binance spot API key, enables account-read and spot-trading, keeps withdrawals disabled, then connects it to PositionPilot. The product stores the credential inside a dedicated boundary and uses opaque references inside the position workflow.

Request security walkthrough

API key safety path

Exchange account, dedicated API key, credential boundary, opaque reference, approved workflow and exchange execution stay separated.

Dedicated key

A separate exchange key for PositionPilot makes permission control, rotation and revocation clearer.

Withdrawals disabled

The ordinary Position Intelligence workflow does not need withdrawal permission.

Credential boundary

Raw API secrets are not ordinary profile data and are not shown to partner/admin dashboards.

Trading risk remains

A key with trading permission can still place or cancel orders inside the approved workflow.

Recommended setup

Recommended API key setup

The setup is meant to be understandable: create a dedicated key, grant only the required permissions, keep withdrawals disabled, and rotate or revoke the key from the exchange when needed.

Create a dedicated PositionPilot API key on the exchange. Enable account-read and spot-trading permissions only where needed. Keep withdrawals disabled.

Read the full explanation

Connect PositionPilot with a dedicated product key whenever the exchange supports it. A dedicated key keeps the permission set easier to inspect and makes rotation or revocation clearer later. The ordinary spot workflow needs account-read and spot-trading permissions where supported; it does not need withdrawal permission.

Dedicated PositionPilot API key

Step 1

Account-read permission

Step 2

Spot-trading only where needed

Step 3

Withdrawal permissions disabled

Safety lock

Security model

Security is built into the exchange-connect workflow.

Security is not a separate promise at the bottom of the site. It is part of the exchange-connect workflow: permissions, credential isolation, runtime access and user-approved plans work together.

The product model is deliberately specific: dedicated exchange keys, withdrawal-disabled setup, credential isolation, audited runtime access and account-connected position workflows.

Read the full explanation

Traders can see what PositionPilot can access, what it cannot access, where credentials are handled, and how trading-enabled API access is tied to the approved position workflow. The security model is explained as part of the workflow rather than as a loose list of claims.

Exchange access model

Users keep assets on their own supported exchange account. PositionPilot uses restricted API access for account-connected position workflows.

Credential isolation

Exchange credentials are handled by a dedicated security layer with opaque references, encrypted envelopes and controlled runtime access.

Encryption framing

Credential storage is described through industry-standard envelope encryption, authenticated encryption and key lifecycle patterns.

Partner and admin visibility

Partner and support dashboards are designed around scoped views, permissions and operational context instead of raw credential exposure.

Lifecycle controls

Credential security includes connect, verify, disable, revoke, rotate and reconnect paths.

Runtime guardrails

Trading-enabled access is scoped to supported position workflows, lifecycle controls, audit history and clear account-level permissions.

Exchange connectivity note

Restricted access is one layer of responsible exchange connectivity.

Trading-enabled access is scoped to supported position workflows, lifecycle controls, audit history and clear account-level permissions.

Trading-enabled keys can place or cancel spot orders inside the approved workflow.

Orders may be delayed, rejected, partially filled or filled at a different price.

A trader-approved plan can still produce losses.

Security is part of the product workflow.

PositionPilot connects restricted exchange access, credential isolation, approved plans, runtime controls and clear account workflows.