What should I do if an API key, access token, or integration credential may have been exposed?
API keys, access tokens, and integration credentials may authorize access to external applications or services.
If a credential is exposed, an unauthorized person may be able to perform operations permitted by that credential.
The appropriate response depends on the external provider and the scope of the affected connection.
What are common exposure scenarios?
1. An API key is accidentally published in a repository.
2. A credential is included in a screenshot.
3. An access token is shared in a message.
4. A secret is stored in an insecure document.
5. A credential is copied into an untrusted application.
6. An employee account associated with an integration is compromised.
What should I do immediately?
Step 1: Identify the affected credential and external service.
Step 2: Stop sharing or using the exposed secret.
Step 3: Follow the external provider's procedure to revoke or rotate the credential.
Step 4: Update the relevant integration configuration through the supported process.
Step 5: Review workflows that depend on the connection.
Step 6: Check the external provider's available activity information for unexpected operations.
Step 7: Notify the responsible administrator.
Step 8: Contact Polyosync Support if the exposure may have affected the platform or business data.
Should I simply delete the message containing the key?
Deleting the message may reduce further exposure, but it does not guarantee that the secret has not already been copied.
Credential rotation or revocation is generally the safer response.
What if the credential is used by an automation?
The automation may fail after the credential is revoked.
Update the authorized connection and verify the workflow before returning it to normal operation.
Should I send the exposed key to Support?
No.
Describe the affected provider, integration, and circumstances without including the secret itself.
Can I reuse the same credential after an exposure?
A credential that may have been compromised should not be treated as trustworthy merely because no misuse has been confirmed.
Follow the provider's security guidance.
Recommended practice
Protect secrets, minimize external permission scopes, rotate exposed credentials, and review integration dependencies after any credential-related incident.