Rotate and revoke private integration credentials

When to rotate

• On the organization credential schedule.
• When a person with secret access changes role or leaves.
• After a deployment, log, screenshot, ticket, repository, or conversation may have exposed the value.
• When the client host, secret manager, or integration owner changes.
• Before extending a long-lived integration into a new environment.
• When troubleshooting suggests the stored token is truncated or corrupted.

Rotation workflow

Rotation issues a new one-time credential and marks the previous key state as rotated. The replacement remains tied to the same managed integration context, but the administrator must store and deploy the new secret. Do not rotate until the integration owner is ready to update the trusted runtime.

1. Confirm the selected sub-account, integration name, owner, scopes, expiration, and rate limit.
2. Select Rotate and save the new token directly to the approved secret manager.
3. Update one controlled deployment or MCP client connection.
4. Call status and compare location and scopes.
5. Search operations and perform one expected read.
6. Roll the secret to remaining approved instances.
7. Remove the old value from deployment history, local environment files, and emergency stores.
8. Record rotation completion without recording the token.

Revocation workflow

Revocation permanently disables the credential. Use it when the integration is retired, ownership cannot be established, the business purpose ends, access is no longer lawful, or compromise is suspected. Revocation cannot be undone; create a new least-privilege integration if access is later required.

After revocation, stop the client, remove the secret, disable scheduled jobs, review recent last-used and audit information, confirm downstream copies follow retention and deletion requirements, and check whether any returned data or proposed actions require incident handling.

Exposure response

1. Revoke the affected credential immediately when active misuse is possible.
2. Preserve redacted timestamps, public key ID, owner, scopes, and last-use evidence.
3. Identify where the token appeared and remove accessible copies.
4. Review affected tenant data, operation history, exports, and downstream systems.
5. Follow the Lead360 security and breach-response process when personal data may be involved.
6. Create a replacement with reduced scopes and a new owner only after the cause is corrected.

Validate every deployment after rotation

A successful status call from one machine does not prove that every production worker, queue, scheduled job, MCP client, and disaster-recovery environment has the replacement. Use a deployment inventory and verify each approved instance without printing the credential. Watch authentication errors and old-key traffic until the migration window closes.

Confirm that scope discovery, one expected read, rate headers, alerts, and secret redaction still work after the update. Remove temporary overlap as quickly as the deployment permits. Search configuration history, build artifacts, local environment files, and support records for obsolete secret copies, then record who completed the cleanup and when.