Exchange API-key permissions control which account actions software can request. Disabling withdrawals is necessary for a KLINEO trading connection, but trading access can still place unwanted orders and cause losses. Use a separate, narrowly scoped key, retain available IP restrictions, and know how to revoke it at the exchange. Revocation stops future use of that credential; it does not undo fills or close existing positions.
At 08:40, a trader sees an order they do not recognize. They check the key's settings: withdrawals are disabled. That is reassuring about withdrawal access. It says little about the order now sitting in the account.
The following incident is hypothetical, not a report of a KLINEO breach. It shows how a correct permission setting can coexist with a serious trading problem, and how to avoid losing time to the wrong question.
08:40: the withdrawal setting does its job
In this example, a trader reused one exchange key across two applications. One copy was exposed. The key permits spot trading but no withdrawals. An unauthorized order converts part of the account's cash balance into an asset the trader never intended to hold.
No transfer to an outside wallet is needed for the account to suffer a loss. An unfavorable execution, fees and a subsequent price move can reduce its value while every asset remains at the exchange. If derivatives permissions were also present, the questions would include open contracts, collateral and liquidation risk. Those are different exposures with different consequences.
This is why “non-custodial” needs a precise reading. For KLINEO's centralized-exchange connections, trading funds remain in the exchange account. That describes where they are held. It does not mean connected software lacks authority to trade them, and it does not remove the exchange's own operational risk. KLINEO explains these boundaries in its connection security guidance and trading risk disclosure.
The first useful question is: What can this exact credential still do, in this exact account?
Read the permission boundary, not the key's nickname
“Bot key” and “trade only” are labels people give credentials. The exchange's actual permissions determine authority. Binance's Spot API, for example, distinguishes trading access from private account information and explicitly includes placing and canceling orders within trading access. Its documentation also describes using separate keys for trading and monitoring. Binance request security.
Use the following map when reviewing a connection. It describes common capabilities; permission names and combinations differ by venue and account type.
| Capability | What you are authorizing | Decision before connecting |
|---|---|---|
| Private read access | Access to supported balances, orders, positions or account records | Does this application need these private records? Read access still exposes financial information. |
| Spot trading | Supported order placement and cancellation | Can this task justify changing the account's asset holdings? Grant only the market access it needs. |
| Derivatives trading | Supported contract and position actions | Have you reviewed collateral, leverage, margin mode and the account exposed to losses? |
| Transfers | Movement between supported account or balance areas | Keep disabled for the trading connection described here. Fund the appropriate account through the exchange's own interface. |
| Withdrawals | Supported movement of assets out of the account | Keep disabled. A request to enable withdrawals is a reason to stop the KLINEO connection process. |
Permission screens deserve a fresh reading each time. Bybit documents trading, wallet transfers, withdrawals and bound IPs as distinct fields in its API-key information. KuCoin documents separate read, spot, futures, withdrawal and transfer capabilities. A familiar-looking screen is not proof that last year's choices still mean the same thing. Bybit API-key information, KuCoin API permissions.
KLINEO's API connection policy requests the credential type needed by the selected venue. A KuCoin API passphrase is created for the API credential; it is not the exchange login password. A Hyperliquid connection uses an account address and an approved API wallet key. Never substitute a seed phrase or primary wallet private key. Hyperliquid calls these delegated signing credentials “API wallets” or “agent wallets.” Hyperliquid API-wallet documentation.
08:42: contain the credential, then inspect the exposure
The trader now suspects a leak. Waiting to identify which application exposed the shared key would leave the credential usable. They open the exchange's official website directly and revoke the affected key.
For a known-exposed credential, provider revocation is the priority. Stopping an application alone does not invalidate a secret another party already possesses. OWASP treats revocation as a distinct part of a secret's lifecycle. OWASP Secrets Management Cheat Sheet.
Then comes a separate job: reviewing what the exchange already accepted. The trader examines recent fills, open orders and current holdings. If an order is still open, they decide whether to cancel it through the exchange. If it already filled, deleting the key cannot reverse the trade.
Avoid a reflexive “cancel everything” instruction. Some open orders may be protective exits for positions that remain open. Identify what each order does before removing it, and use the exchange's own controls to manage the remaining exposure. If you cannot determine the account state, contact the exchange through its official support channel.
KLINEO has product stop controls and a Revoke action in Settings. These serve different purposes from revoking the provider credential. The connection service can refuse disconnection while active work or recovery needs reconciliation. If you suspect compromise, do not wait for that application workflow before revoking the key at the exchange. Follow the incident and revocation steps, then check the exchange account directly.
Build a connection you can identify and revoke
The fictional trader's shared key created a second problem: revoking one credential interrupted both applications. Separate keys give you a clearer inventory and a way to withdraw one application's access without intentionally disabling another's.
Give each key a label that records the application, environment and intended account, such as KLINEO-live-spot. Keep a non-secret record of its creation date, permissions and purpose. Store the secret securely; keep it out of screenshots, chat histories and support tickets.
Separate keys do not separate the money. Two trade-enabled keys for the same account can still act on the same balances. If you need a distinct pool of trading capital, investigate the exchange's supported account or subaccount structure and verify that the exact account type works with the KLINEO feature you intend to use. Do not infer isolation from a new key label.
Account separation also needs careful reading. Shared collateral or transfer authority can change the boundary you expected. A dedicated account is useful only to the extent that its actual permissions and financial relationships support the intended separation. This article does not assert that every exchange subaccount is supported by KLINEO or that any arrangement guarantees a fixed maximum loss.
Match the environment as carefully as the account. Production credentials belong to production connections. A successful simulated run does not prove production permissions, balances or order handling. Use the Virtual, testnet and Live guide to distinguish those paths.
An IP restriction answers one narrower question
An IP allowlist limits where a permitted API request may originate. It can reduce opportunities to use a stolen key from elsewhere. It cannot decide whether an order submitted from an allowed system is sensible or authorized by your strategy.
Use the confirmed outbound addresses for the system actually sending exchange requests. For a hosted trading service, that is not automatically your laptop's public IP. Obtain current instructions through the service's official connection flow or support; do not copy an address from an unrelated tutorial.
Binance's current API guidance strongly recommends IP restrictions when granting more than reading permission and describes security controls for unrestricted system-generated keys. Do not disable a protective exchange setting merely to make a connection error disappear. If you cannot establish a supported restricted configuration, pause and resolve the requirement first. Binance API-key setup and restrictions.
No current KLINEO outbound IP list was verified for this article. The useful next step is to confirm the correct configuration, rather than publish an address readers may later trust after it changes.
09:10: replacement is a new authorization decision
After containment, the trader has two tasks left: understand the exposure and decide whether the connection should exist again. Creating a replacement key immediately would only reproduce the original uncertainty.
For a suspected leak, establish a credible explanation and secure the affected account, email or device before reconnecting. Preserve useful non-secret details: the approximate time, exchange, application involved and relevant order identifiers. Do not send a secret to support to prove that it was exposed. Use KLINEO's official contact page for a report.
For a planned retirement, use a calmer sequence:
- Review the bot or workflow, its open orders and any positions it manages. Use the appropriate stop controls and inspect the resulting state.
- Arrange how remaining exposure will be managed directly at the exchange before removing its automation.
- Retire the saved KLINEO connection when the application permits it, and revoke the key at the exchange. Confirm each action separately.
- If access is still needed, create a new key with the required permissions and restrictions. Verify the intended account, environment and market before enabling trading again.
The Binance connection guide and KuCoin Classic connection guide give venue-specific steps. A connection test is evidence about a reported connection state. It is not a guarantee of a future fill, continued API availability or regional account eligibility.
What a secure connection still cannot promise
KLINEO stores connection credentials encrypted. Encryption protects a different part of the system from the exchange's permission controls; the service still needs to use those credentials for authorized requests. Encryption is not proof that compromise is impossible, and this article makes no claim of an independent audit or certification.
As of this article's review date, KLINEO's own two-factor enrollment is not available in the current build. Use available protection on your email and exchange accounts, while recognizing that those settings do not activate KLINEO account 2FA.
When deciding whether a connection is ready, look for three observable facts: you know what the credential authorizes, you know which account it can affect, and you can revoke it through the provider's official controls. Keep the withdrawal boundary closed. Treat the trading authority that remains as real authority over capital.
Editorial method: This guide was prepared with AI assistance using current official exchange documentation and a review of KLINEO's connection implementation and public policies on 19 October 2026. The incident is fictional. No live exchange account or credential was used in that review. It is operational guidance, not a security audit or a recommendation to trade.