If an exchange API credential may be exposed, revoke the affected key or delegated wallet approval through the provider's official controls promptly. Then inspect open orders, positions and recent activity directly at the exchange. Stopping an application or deleting a screenshot does not invalidate a copied secret. Preserve non-secret evidence, secure related access and reconnect only after resolving the suspected exposure and verifying the replacement.
You discover an API secret in an old support screenshot. There is no unexplained withdrawal and no obvious unfamiliar trade. Waiting for either would leave a usable credential in circulation while you try to prove a negative.
The response needs two parallel questions: Can the old authority still be used? What exposure already exists? The first is about revocation. The second is about the account. This article provides an incident worksheet for keeping both visible without turning the evidence record into another secret leak.
Contain access through the provider
Open the exchange's official website or app through a known route, rather than following a link in an unsolicited security message. Locate the affected API credential and revoke or delete it. For a delegated API wallet, remove its approval using the provider's supported controls.
OWASP's secret-management guidance treats prompt revocation as a containment action for exposed credentials. Rotation and removal of obsolete copies follow, but removing a consumer's saved copy does not end provider authorization. OWASP secret incident response.
KLINEO has application stop controls and a saved-connection Revoke action. Those are separate from exchange-side revocation. The application can refuse a connection change while trading or recovery references need attention. Do not wait for an application workflow to finish before revoking a known-exposed provider credential. The KLINEO incident guidance makes this boundary explicit.
If you cannot access the exchange, use its official account-recovery or support channels. A blocked account login is another incident fact to record, not a reason to share the secret with someone offering help in a direct message.
Inspect the exposure that revocation cannot undo
Revocation prevents further authorized use of that credential once effective under the provider's controls. It does not reverse fills, close positions or establish that every previously accepted order is gone.
Review open orders, recent executions, balances and positions in the exact account and product. Check derivatives exposure separately from spot holdings. An empty spot-order screen does not establish that a futures position is flat.
Avoid a blind “cancel everything” response. An order may be an entry, an exit or a protective instruction associated with an existing position. Removing it changes the account's risk. Identify its purpose and manage remaining exposure through the exchange's supported controls, seeking provider assistance if the state is unclear.
The order reconciliation procedure explains why missing responses and missing open-order rows cannot establish that nothing traded. During a credential incident, retain that same discipline: uncertain stays uncertain until the exchange evidence resolves it.
Withdrawal-disabled access still matters. A trade-enabled key can create unwanted positions, unfavorable executions or fees without moving assets to an outside wallet. Read the API permission boundary if the absence of a withdrawal seems reassuring enough to postpone action.
An original incident timeline, with unresolved facts left visible
The following timeline is fictional. It is not a KLINEO incident, a response-time benchmark or a promise that these actions can always be completed within these intervals.
| Fictional time | Observation or action | Evidence status |
|---|---|---|
| 11:12 | A saved screenshot appears to contain a live API secret | Exposure suspected; exact scope not yet known |
| 11:13 | Owner revokes the affected credential in the official exchange interface | Provider action recorded; previous use still unreviewed |
| 11:15 | Owner reviews current orders and positions | Two order purposes need clarification; account not declared recovered |
| 11:24 | Original order identities and final fills are reconciled | Observed exposure recorded; source of screenshot access still unresolved |
| Later review | Affected device, sharing route and related access are investigated | Replacement deferred until a credible recovery decision exists |
The useful feature is the evidence status column. “Revoked” does not silently turn into “no loss.” “Account reviewed” does not silently turn into “source of exposure resolved.” The reader can see what each action accomplished and which uncertainty remains.
Keep a separate list of known, suspected and unverified facts. For example, “the screenshot contains the credential” can be known, while “someone else downloaded it” remains unverified. You can act on exposure without inventing an attacker, a cause or a loss figure.
Preserve evidence without circulating the secret
Record the approximate discovery time, venue, account inventory label, affected application, where the credential appeared and the exchange's revocation confirmation. Keep relevant order identifiers, status observations and non-secret event times in a protected record.
Do not forward the original screenshot to a public channel. Redact the key, secret, API passphrase, signatures, account identifiers and personal financial information from material shared for support. Preserve any necessary unredacted evidence securely under the appropriate access controls; a redacted support copy serves a different purpose.
For KLINEO, send a concise non-secret report through the official contact page. State whether provider revocation succeeded, whether account exposure remains unresolved and what the application reported. Never provide a seed phrase, exchange login password or primary wallet private key.
Evidence collection should not delay ending a known-exposed credential's authority. Nor should cleanup erase every useful timestamp or event identifier before the account can be understood. The objective is containment plus a careful record, not a large archive of reusable secrets.
If the credential was published in code or a document
Deleting the visible line does not prove all earlier copies disappeared. A repository can retain history, forks or clones; a shared document can have versions and downloads. Treat the credential as exposed even if the current view looks clean.
GitHub's own sensitive-data guidance prioritizes revoking or rotating the secret before considering repository-history cleanup. It also explains why copies outside the rewritten repository can persist. GitHub sensitive-data removal.
After revocation, coordinate cleanup with the system owner. Do not improvise destructive history rewrites during an active incident just to remove a search result. The cleanup method needs to fit the hosting system, collaborators and remaining sensitive information.
Search for other occurrences in the systems you control using an authorized process. Avoid pasting the live secret into an external search engine or a public issue to look for matches. The incident record should identify locations and ownership without creating another distribution channel.
Decide whether related access is affected
A single screenshot leak and a compromised signing server have different scopes. In the first case, one credential may be the main concern. In the second, other stored secrets, application sessions and account access may also need investigation.
Ask where the secret was available, which people or processes could read it and whether the same environment held other credentials. Check the associated email and exchange account using their available security and session controls. If account access may be compromised, change affected passwords and follow the provider's recovery process.
A new IP allowlist can restrict a replacement's request origin. It does not prove that an allowed system is uncompromised or that the old secret was never used. Likewise, a subaccount boundary needs verification; its name alone cannot establish that parent-account access was unaffected.
NIST's incident-response guidance treats preparation, response and recovery as ongoing risk-management work. That supports retaining an explicit recovery decision and learning from the incident rather than equating a new key with a completed investigation. It is not a certification that this worksheet satisfies every organizational or legal requirement. NIST SP 800-61 Revision 3.
Reconnect against conditions, not a deadline
Before creating a replacement, establish what happened to the exposed credential, how remaining exposure is managed and why the new secret will not enter the same suspected leak path. The explanation can remain limited, but it must be more concrete than “we waited an hour.”
Use a new dedicated credential with only required product permissions and appropriate restrictions. Keep withdrawals and transfers disabled for the KLINEO connection. Verify the same intended account and environment, and use a supported read-only test before any further readiness action.
The planned key rotation guide provides the account and order handoff for the replacement phase. Its planned overlap sequence should not be used to preserve a credential suspected of compromise. An emergency revocation can require a period of direct exchange management while the application remains disconnected.
Record unresolved questions and who owns them. A provider or qualified incident specialist may be needed when account access, device compromise or financial exposure remains uncertain. No worksheet can infer a clean system from the absence of a new alert.
Close the incident only with a clear account state, ended affected authority, an appropriate recovery decision and changes that address the identified failure. Keep the non-secret record so the next owner does not have to rediscover which key, account and actions were involved.
Editorial method: Prepared with AI assistance on 20 October 2026 using current OWASP, NIST, GitHub and KLINEO public guidance. The screenshot incident and timeline are original fictional teaching examples. No breach, customer account, forensic investigation, independent security certification or guaranteed recovery outcome is claimed.