Credential revocation

Alpha release

WebDecoy can pause an attributed caller on supported Node action/MCP integrations with reportCaller and callerPause enabled. Provider credential status is not verified by WebDecoy. This guide directs you to your application’s own identity provider; WebDecoy does not perform those provider operations.

Keep the three states separate

State	Where it is established	What it means
WebDecoy caller pause	Property-scoped pause control and audit	New work is denied after a successful opted-in control check. Outages fail open; other integrations are unaffected.
Provider credentials	Your provider’s session/token/grant records and application checks	Provider-specific revocation. The WebDecoy dashboard reports this as not verified, even while a caller is paused.
Already-running work	Your application’s execution system	Pausing or revoking admission does not cancel work already admitted. Use your application’s cancellation mechanism when supported.

Resuming a WebDecoy caller does not restore provider credentials. Conversely, provider revocation does not remove a WebDecoy pause. Review both independently.

Identify the right principal

1. Open the caller timeline and confirm the selected property, action, reason and policy version. A reported denial alone does not establish malicious intent.
2. Use your private authentication/audit records to identify the matching issuer, tenant, subject and affected session or client grant. The caller pseudonym is property-scoped and secret-derived. It is not a provider user ID, session ID, token or reversible lookup. WebDecoy does not hold that mapping. If your integration has not retained a reliable mapping, establish it before taking a provider action; do not guess from an IP address or display name.
3. Sign in to your application’s provider tenant/account with the necessary administrative access. WebDecoy’s own Auth0 account is unrelated to credentials issued by your application. Keep provider administration credentials in your own backend or provider console; do not paste them into pause reasons or alerts.
4. Choose the smallest affected scope. A session, refresh-token family, application grant and entire user account have different consequences. For a shared service principal, identify which legitimate applications would also lose access.

Do not rotate the SDK subjectSecret as a substitute for containment: changing it changes caller pseudonyms, so existing caller pauses no longer match that identity.

Provider actions

The links below are official provider instructions, reviewed October 4, 2026. They are operational references, not WebDecoy provider integrations.

Provider	Action to review	Scope and verification
Auth0	Revoke a refresh token or authorized application grant in your Auth0 tenant.	Check the tenant’s grant-revocation setting: a token operation can affect the associated grant and other refresh tokens. Revocation APIs have provider-specific consistency behavior; do not infer application rejection solely from the API response.
Amazon Cognito	RevokeToken or administrator global sign-out.	Single refresh-token revocation and user-wide sign-out have different scopes. AWS explicitly notes that signature/expiry-only JWT validation can still accept a revoked token; check your application enforcement path.
Clerk	Revoke the identified session using your Clerk backend credentials.	The operation targets a session ID and signs out its associated client. Match that session to your application audit evidence; do not substitute the WebDecoy caller pseudonym.
Supabase Auth	Review session lifecycle and post-sign-out validation.	Supabase describes checking the JWT’s session_id against session state when immediate post-sign-out rejection is required. Account for token expiry and your application’s actual validation behavior.

For other providers or API keys, use the issuer’s documented credential/grant revocation operation. Client-secret rotation or a successful refresh-token revocation is not evidence that every resource server rejected previously issued access tokens. Identify any local authorization cache and how it is invalidated.

Verify before declaring containment complete

Use an owned test principal and a harmless protected operation that does not call a model or perform a business action:

1. Confirm an unaffected test caller still reaches that operation.
2. Apply the intended provider action, then try the affected credential against your application’s authentication boundary. Distinguish an authentication rejection from a WebDecoy pause denial: a paused caller alone cannot prove provider revocation worked. Inspect your server-side authentication result; do not lift a live incident pause merely to make this test easier.
3. Where applicable, verify that the affected refresh token or session cannot obtain renewed access. Separately check an already-issued access token through the API’s actual validation path, including any caches or offline JWT checks.
4. Record the scope, operator, provider audit reference, request time, observed rejection time and any residual token/cache window in your incident system. Record unknown or pending results explicitly. Never store raw credentials in that record. WebDecoy’s pause audit records only WebDecoy control changes; Alpha now lets owners/admins append a structured operator report in the caller panel. These reports are not imported provider proof and WebDecoy does not certify them.
5. Resume the WebDecoy caller only after reviewing its remaining access and the incident outcome. A legitimate caller whose credentials were revoked may need to authenticate again and receive appropriately scoped credentials.

If immediate rejection is required, enforce current authorization/session state at your application’s boundary. A WebDecoy fail-open pause is not a substitute for that requirement. See controls and outage behavior.

Record an operator observation

In AI Protection → caller timeline → Provider action records, select Record provider action. Confirm the selected property and caller pseudonym against your private identity mapping, then choose the provider, credential scope, reported result and observation time. Observation time uses your local time zone and is saved in UTC; it must be within the past year (five minutes of clock skew is allowed). Check the attestation and save.

Available results distinguish an unknown/corrected observation, a revocation request, a provider-reported revocation and an application rejection of the specific credential you tested. All four are operator-reported. An application rejection does not prove every credential is invalid or that running work stopped. The dashboard continues to label provider credentials not verified by WebDecoy.

Records include the operator and server-recorded timestamp. The latest 20 are shown, newest saved first, with observation time separately displayed. Earlier observations can be entered later; the latest saved entry is not live credential status. To correct an earlier report, append Unknown / correction, choosing the matching provider and credential scope. Previous entries remain in history. Records are retained until their property or organization is deleted.

Records are scoped to the current property/caller; only owners/admins can append them. If another operator saved first, refresh before retrying. Saving or correcting a provider report does not pause/resume a caller or contact the provider. Keep provider user IDs, credentials and detailed supporting evidence in your private incident system; this form accepts only structured observations.