Compute
Respond to an incident and revoke access
Revoke in the family that owns the effect, rotate at the issuing system, verify each read-back, and collect safe evidence without sending a secret or a payload to support.
Before you start
Name the exposure before you act. A leaked key, a wrong destination and a runaway schedule are three different problems with three different owners.
Revocation is management work. Use a portal session or an admitted management service identity, not a work key.
Revoke in the family that owns the effect
| What is exposed | Where you revoke | What that stops |
|---|---|---|
| A personal, service or automation key | Identities and keys | Further requests made with that key |
| A source secret | Sources and credentials | Further reads of that source |
| A destination authority | Destinations and delivery | Further writes to that destination |
| An automation firing wrongly | Schedules and webhooks | The next occurrence |
| Directory-driven access | Identity sync and role mappings | New grants arriving from the directory |
| A person | Members, invitations and grants | That person's portal access |
| Spend | Spend and approval | Further admission against that ceiling |
Revoking in the wrong family looks successful and changes nothing. Pick the row that matches the effect you need stopped.
Rotate at the issuing system
For anything Lithi holds only a reference to, rotation happens where the secret was issued. Rotate there first, because that is the step that stops its use everywhere.
Then revoke or re-register the Lithi side, and test the new registration before resuming work.
Stop work already in flight
Canceling a job is not revoking access. A canceled job moves through CANCELLING to CANCELLED, and it does not close the credential that submitted it.
Do both when both apply. Revoke the credential, then cancel the jobs it started.
Verify each consequence separately
Read back every change you made. Pause, revoke, suspend and remove are four different effects, and one call never settles the others.
A configuration apply reports per resource. PARTIAL_WITH_NEXT_ACTION means at least one resource still needs you, and a REFUSED resource has not been contained.
Preserve safe evidence
Every response carries the request identifier, the operation, the contract release and a typed state. It also carries an evidence class, when it was observed, how long it stays valid, and a next action. Keep those.
Also keep the job identifier and the receipt reference. Audit and receipt projections are content-free by design, so they are safe to attach.
Never send these to support
- a key, token, password, signed URL or any other credential
- a full input file, a full result file or a raw payload dump
- bank or payment details
If support needs to see a failing item, send its item identifier and the typed error. Do not send the item.
To report a suspected vulnerability rather than an account exposure, use the security reporting route.