Secret handling

Before handling exposed secrets

Use this page when a token, private key, webhook secret, session cookie, provider credential or secret-like source snippet appears in evidence, a report, a ticket export, a repository remediation flow or an integration diagnostic. The safe path is to redact first, identify the credential indirectly, then revoke or rotate through the owning system.

• Rotate exposed secrets
• Replace secret payloads with `credential_fingerprint`, `provider_subject`, `revoke_reason` and `secret_redaction_status`.
• Keep provider access scoped to `approved_scope` and the minimum permissions needed for the selected workflow.
• Stop sharing when `SECRET_REDACTION_REQUIRED`, `SECRET_EXPOSURE_BLOCKED`, `CONNECTED_ACCESS_REVOKED` or `CREDENTIAL_ROTATION_REQUIRED` applies.

Redact revoke and rotate safely

Follow the path `Evidence or access warning → Redaction status → Credential fingerprint → Revoke or rotate → Regenerate safe output`.

1. Open the report, ticket export, integration target, repository connection or remediation task where the secret-like value appeared. Result: the source artifact and affected workflow are identified before anyone copies the value.
2. Do not copy the raw token, key, webhook secret, cookie, password-like value or private source snippet into a note, ticket, prompt or screenshot. Result: the secret does not spread beyond the original artifact.
3. Set or confirm `secret_redaction_status`. Result: customer-visible evidence, report copy, tickets, diagnostics and generated remediation output replace the secret with safe wording.
4. Confirm `credential_fingerprint` and `provider_subject` instead of the raw value. Result: audit history can identify the credential boundary without storing or displaying the credential.
5. If connected provider access is involved, open Revoke and no-secret boundaries and compare `approved_scope` with the current task. Result: repository, CMS, GTM, CMP or ticket provider access is not broader than the workflow needs.
6. Choose revoke when the work is complete, unsafe, no longer approved or no longer needed. Result: `revoked_at` and `revoke_reason` are recorded, and connected actions stop with `CONNECTED_ACCESS_REVOKED`.
7. Rotate the credential in the source system such as the provider, repository host, webhook receiver, CMS, GTM, CMP or environment store. Result: `CREDENTIAL_ROTATION_REQUIRED` clears only after the source system has a new credential.
8. Reconnect only through the product flow with narrower scope when automation still needs access. Result: fresh access is tied to the account, project, provider subject and approved workflow.
9. Regenerate or re-export affected reports, tickets, artifacts and patch drafts after redaction. Result: shared output no longer contains the old secret-like value.
10. If the secret cannot be removed or rotation cannot be confirmed, keep `SECRET_EXPOSURE_BLOCKED` visible and stop sharing. Result: unsafe evidence does not move to customers, providers or repositories.

Secret values WebRiskOps must block

Secret-like values should not become ordinary documentation, report, log, ticket, webhook, prompt or remediation content.

• Repository tokens, API tokens, OAuth tokens, private keys, webhook secrets and signing secrets.
• Bearer tokens, session cookies, password-like form values and one-time authentication values.
• Payment provider secrets, billing authorization values and private account identifiers that are not needed for evidence.
• Customer source snippets that expose credentials, private implementation details or internal endpoints.
• Provider export payloads that include credentials instead of provider IDs or safe status fields.

Safe credential references

Use indirect references when the workflow must show why a credential was changed.

• `credential_fingerprint` can identify the credential boundary without showing the value.
• `provider_subject` can identify the provider account, app installation, shop, workspace or repository subject.
• `approved_scope` can show what the customer allowed without exposing a credential.
• `revoked_at` and `revoke_reason` can explain when and why access ended.
• `secret_redaction_status` can show whether the affected artifact was redacted, regenerated or still blocked.

Ready and blocked secret states

Use these states before sharing evidence or allowing connected automation to continue.

• Redaction ready means `secret_redaction_status` confirms secret-like values were removed or replaced in evidence, tickets, reports and remediation output.
• Fingerprint ready means `credential_fingerprint` and `provider_subject` identify the affected credential without exposing it.
• Revoked access means `CONNECTED_ACCESS_REVOKED`, `revoked_at` and `revoke_reason` show that provider access no longer authorizes connected actions.
• Rotation required means `CREDENTIAL_ROTATION_REQUIRED` remains until the owning source system has a new credential and the old value no longer works.
• Exposure blocked means `SECRET_EXPOSURE_BLOCKED` stops publication, export, patch generation or provider delivery until redaction and rotation are complete.

Continue after secret handling

After redaction and rotation are complete, continue to Artifact retention to check whether old artifacts need replacement, Data collected and excluded to verify the evidence boundary, Revoke and no-secret boundaries for repository access, Access modes and required scopes for platform access, or Provider connection errors when revoked or rotated credentials affect integrations.