---
title: "API key security and leak response"
description: "Scope management credentials and respond to a leak with immediate revocation, request-ID investigation and controlled recovery."
slug: "/docs/v1/security/api-key-leak-response"
section: "Security"
order: 22
audience: "all"
level: "advanced"
last_updated: "2026-10-17"
version: "v1"
related: ["/docs/v1/security/signed-responses","/docs/v1/security/threat-model"]
draft: false
---
Keep [developer API keys](/docs/v1/start/glossary#developer-api-key) on trusted servers and revoke an exposed key before relying on removal of the public copy.

## What you will learn
- Use the three registered management [scopes](/docs/v1/start/glossary#scope).
- Rotate without assuming a grace overlap.
- Investigate and recover from confirmed or suspected exposure.

## Prerequisites
- Read [authentication](/docs/v1/start/authentication).
- Have authorized access to your workspace's API keys, API logs and audit logs.
- Do not paste secrets into support messages or documentation feedback.

## Prevent exposure
Use one named key per service, [product](/docs/v1/start/glossary#product) and environment where practical. Store it in backend secret configuration and give its service account the minimum access. [Sandbox](/docs/v1/start/glossary#sandbox) and [Live](/docs/v1/start/glossary#live) credentials must not be interchangeable.

| Scope | Current public operations |
| --- | --- |
| [licenses](/docs/v1/start/glossary#license):read | Read a license by ID |
| licenses:write | Create, revoke, suspend, restore and renew licenses |
| [devices](/docs/v1/start/glossary#device):write | Reset devices for a license |
An arbitrary scope string does not add a permission. A read-only integration does not need licenses:write. A desktop app uses the [public App ID](/docs/v1/start/glossary#public-app-id) and installation token, never an lmp_ key.

Scan release packages, repository changes, CI logs, screenshots and crash reports. Do not put credentials in URLs, shell history or analytics. Redact Authorization and raw [customer](/docs/v1/start/glossary#customer) payloads from your own logs.

## Immediate containment
1. Identify the affected key in API keys by its display prefix, product, environment and name.
2. Revoke it immediately if exposure is suspected; do not wait for evidence of misuse.
3. If using Rotate, securely copy the new secret once and deploy it to the intended backend.
4. Confirm the old key no longer works and the replacement performs only its intended operation.
5. Remove the exposed copy from active configuration and distribution channels.
Expected result: the old credential cannot authenticate. Rotation revokes the old key immediately; there is no automatic overlap. Coordinate deployment or accept a short controlled interruption.

Do not test a leaked credential against tenants you do not own. Deleting a public message or commit does not revoke the credential and cannot guarantee nobody copied it.

## Investigation
1. Record the earliest possible exposure time and affected product/environment.
2. Review API logs for method, endpoint, HTTP status, time and request_id.
3. Correlate [request IDs](/docs/v1/start/glossary#request-id) and affected resource IDs with audit logs and your own backend logs.
4. Identify actual license creation, state changes or device resets during the window.
5. Preserve only necessary investigation records in restricted storage.
Expected result: distinguish confirmed actions from suspicions. The API log does not retain request bodies or Authorization tokens; missing payload details are not proof no incident occurred. Retention varies by plan and cleanup scheduling.

## Recover affected licenses
1. List only the licenses affected by confirmed unauthorized actions.
2. Suspend or revoke those requiring containment under your policy.
3. Review unintended device resets and ask legitimate customers to reactivate when necessary.
4. Reissue or restore access only after confirming the intended customer and product.
5. Validate the repaired state in Sandbox or an explicitly authorized real incident workflow.
6. Monitor new failures and unexpected management requests.
Expected result: recovery is targeted. Do not revoke every customer's license without evaluating impact. Revoked [activation tokens](/docs/v1/start/glossary#activation-token) do not automatically revive when a license is restored.

## Notify and improve
Inform affected parties with confirmed facts, impact, steps taken and support options. Avoid speculative accusations or disclosing other customers' data. Assess personal-data breach obligations with qualified advice; this playbook is not a legal determination.

Restrict new keys, repair the leaking pipeline, rotate other actually exposed credentials and record the incident. A management key, activation token, [webhook](/docs/v1/start/glossary#webhook) secret and signing private key are different credentials with different remediation. Suspected signing-key exposure must be escalated to [KDPika security contact](/security).

## Expected result
The leaked key is invalid, replacement scope is minimal, affected actions are identified and recovery is documented.

## Common mistakes
- Removing a public secret without revoking it.
- Assuming rotated credentials overlap safely.
- Claiming API logs contain bodies that the logger intentionally does not capture.

## Security notes
Keep the investigation private and redact credentials. Review operational access to server configuration and backups; cryptographic hashing at rest does not make an exposed usable token harmless.

## Troubleshooting
| Symptom | Cause | Action |
| --- | --- | --- |
| Backend fails after rotation | Immediate old-key revocation | Deploy the new secret securely |
| No full request body in logs | Privacy-conscious metadata-only API logging | Correlate request_id with your own restricted logs |
| Customer cannot reactivate after restore | Old token remains revoked | Use a fresh authorized [activation](/docs/v1/start/glossary#activation) |

## Next steps
Read [signed responses](/docs/v1/security/signed-responses) and [the threat model](/docs/v1/security/threat-model), then validate your own integration in Sandbox.

## Related
- [Verification examples](/docs/v1/security/verify-ed25519)
- [Offline mode](/docs/v1/security/offline-mode)
- [Security and disclosure](/security)