> ## 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: Audit access and offboard a member
description: >-
  List content-free access events, revoke a leaver's keys and sessions, then transfer
  service ownership deliberately and read back each consequence on its own.
route: /docs/compute/access/audit-and-offboarding
page_id: docs-compute-access-audit-and-offboarding
page_type: howTo
content_layer: guided documentation
surface_profile: guided_docs
audience: Organization administrators removing a member or reviewing past access
voice: D
reader_question: How do I review what someone had access to, then remove them without breaking the work they set up?
primary_action: Review service identities
source_locale: en-US
source_status: APPROVED
source_version: docs-compute-access-audit-and-offboarding-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

Offboarding is management work, not work submission. A work key cannot list audit events, revoke a key or change a membership. Management scopes are never mintable on a work key.

Use a portal session or an admitted management service identity. Have the person's member record and their keys in front of you before you change anything.

## List what the person actually touched

Start with the audit and receipt list. It returns content-free projections with stable cursors, so you page forward with the cursor rather than guessing dates.

Content-free means each entry names the actor, the operation and the time. It never carries your input, your prompt or your result.

Five resource families publish their own event streams. Read all of them beside the audit list:

- member, invitation and grant events
- identity sync and role-mapping events
- destination and delivery events
- schedule and webhook events
- configuration apply events

Read before you revoke. A key you revoke first can hide the schedule that was using it.

## Revoke the personal credentials

1. Revoke each [personal key](/docs/compute/access/api-keys) the member holds, then read the key back.
2. Suspend the membership to end portal access, then read the member record back.
3. Remove the membership once nothing else depends on it.

Key plaintext is shown once, at creation. There is nothing to retrieve later, so revocation is the only control that matters here.

## Transfer service ownership explicitly

A service or automation identity is not the person. Suspending a member does not stop the automation they set up, and removing a member does not reassign it.

Name every service identity, schedule, webhook, source and destination the person administered. For each one, reassign the owner or pause it deliberately, then read it back.

## Verify each consequence separately

Suspend, remove, revoke and pause are four different effects. Confirm each with its own read-back rather than assuming one call settled the rest.

A configuration apply reports per resource. `VERIFIED` on one resource says nothing about the next, and `PARTIAL_WITH_NEXT_ACTION` means at least one resource still needs you.

## What offboarding cannot undo

Revocation stops future use. It does not reach backwards.

An invitation already accepted, a result already written to your warehouse, and an invoice already settled are forward-repair problems. Withdraw the membership, write a corrected result, or raise an adjustment.

[Review service identities](/docs/compute/access/service-identities)
