If a workspace key appears in a browser bundle, public repository, or downloadable app, treat it as exposed. Removing the visible copy does not make copies held elsewhere disappear.
Use your provider's documented revocation and key-management process. A confirmed exposure may require a faster response than routine planned rotation.
Contain the credential first
Identify the key by a safe reference, revoke or disable it as supported, and replace affected server configuration. Avoid pasting the plaintext value into an incident chat or issue while asking for help.
Check which services depended on it so the replacement reaches the necessary callers. Verify a small permitted request after deployment and confirm that the retired key no longer works through an authorized controlled check.
Review available usage evidence for unusual activity. Describe what the records show and what remains unknown. The absence of an obvious spike is not proof that no one copied the key.
Find the path into the build
A variable intended for the server may have used a public build-time prefix. A debugging helper may have printed a complete request. A sample file may have been committed with a real value instead of a placeholder.
Search the affected artifact and source history using controlled local tools. Remove the current exposure and update the build boundary so future secrets do not follow the same path. Add a focused check that detects the type of mistake you found.
Keep the incident record limited to identities, times, actions, and outcomes. A useful follow-up explains how the key entered the public surface and which verification now prevents a repeat. It should not preserve the secret as part of the explanation.