> ## Documentation Index
>
> Fetch the complete documentation index at: https://lithi.ai/llms.txt
>
> Use this file to discover all available pages before exploring further.

---
title: Respond to an incident and revoke access
description: >-
  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.
route: /docs/compute/security/incident-and-revocation
page_id: docs-compute-security-incident-and-revocation
page_type: howTo
content_layer: guided documentation
surface_profile: guided_docs
audience: Administrators and security responders containing a suspected exposure
voice: D
reader_question: Something may be exposed. What do I revoke, in what order, and what can I safely send support?
primary_action: Collect safe support evidence
source_locale: en-US
source_status: APPROVED
source_version: docs-compute-security-incident-and-revocation-en-us-2026-09-05-v1
last_updated: '2026-09-05'
robots: index
claim_registry_pinned: true
claim_registry_resync: "npm run governed:tsx -- scripts/build-compute-public-claim-registry.ts --write"
---

## 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](/trust/report-a-security-issue).

[Collect safe support evidence](/help/compute/support-evidence)