Small-business offboarding
AI agent offboarding checklist for small businesses.
Offboard a departing person or retired agent by disabling its identity, ending sessions, revoking every repository, app, token, key, and connector, transferring owned work, rotating shared secrets, and testing that the retired path no longer works.
Removing one account is not a complete offboarding check. Identity providers, source-control platforms, AI tools, installed apps, and local copies can each have a separate access path.
CapitalGuard Security Research · Version 1.0.0 · Sources checked July 29, 2026
5
Ordered steps
21
Register fields
8
Primary sources
The direct workflow
Close the identity, then every path around it.
Use one coordinator and one effective time. Complete the sequence for a departing employee, contractor, autonomous agent, bot, or service account.
- 1
Map
List every identity and access path
Record the departing person or retired agent, every AI tool and service account it used, repositories, identity groups, installed apps, connectors, devices, tokens, keys, and shared secrets. Assign an owner and cutoff time to each path.
- 2
Block
Disable sign-in and end active sessions
Disable the primary identity first, revoke identity-provider sessions and refresh tokens, and suspend managed devices where appropriate. Then close sessions inside third-party applications because an identity provider may not control tokens issued by the application itself.
- 3
Revoke
Remove repository and tool access
Remove organization, team, repository, AI workspace, MCP server, connector, GitHub App, OAuth app, personal access token, SSH key, deploy key, and API access that belongs to the subject. Check indirect access through other teams, groups, forks, and organizations.
- 4
Transfer
Transfer ownership and rotate shared credentials
Move owned automations, scheduled jobs, repositories, files, calendars, and recovery duties to a named owner before deletion. Rotate any credential the subject knew or shared when it cannot be individually revoked, then test the replacement automation.
- 5
Verify
Test closure and record exceptions
Attempt a controlled sign-in, repository fetch, agent run, and connector call using the retired path. Review available audit events, record the evidence, and assign an owner and deadline to any local copy, offline device, unsupported integration, or other residual access.
Access-path check
One departure can cross five systems.
Work through each surface even when the primary identity is centrally managed. An application session, local clone, installed integration, or shared credential can follow a different revocation rule.
| Surface | Review before closure |
|---|---|
| Identity | Primary account, IdP groups, roles, recovery methods, browser sessions, and managed devices |
| Source control | Organizations, teams, repositories, forks, invitations, personal tokens, SSH keys, and deploy keys |
| AI surfaces | Editors, coding agents, cloud agents, workspaces, memory, MCP servers, and browser connectors |
| Automations | Bots, scheduled jobs, CI/CD, installed apps, OAuth apps, webhooks, and service accounts |
| Shared access | API keys, vault entries, shared passwords, environment secrets, and offline or local copies |
Blank offboarding register
Record closure without publishing identities.
Use a private internal reference for the subject. Completed registers can reveal security architecture, access paths, credentials, and personnel information, so keep them in an authorized private system.
| Field | Machine key | Why it matters |
|---|---|---|
| Offboarding ID | offboarding_id | A non-sensitive reference for the complete offboarding event. |
| Subject type | subject_type | Person, contractor, agent, bot, or service account being removed. |
| Subject reference | subject_reference | A private internal identifier instead of personal details in exported evidence. |
| Effective time | effective_at | The approved time at which access should stop. |
| Coordinator | coordinator | The person accountable for completing and verifying the workflow. |
| AI tools and agents | ai_tools_and_agents | Editors, coding agents, assistants, bots, and managed AI workspaces in scope. |
| Identity accounts | identity_accounts | Identity-provider, email, source-control, cloud, and local accounts to disable. |
| Repositories and organizations | repositories_and_orgs | Source-control organizations, repositories, forks, and outside-collaborator access. |
| Teams and groups | teams_and_groups | Direct and inherited access granted through teams, groups, roles, or SCIM. |
| Apps and connectors | apps_and_connectors | GitHub Apps, OAuth apps, MCP servers, browser integrations, and SaaS connectors. |
| Sessions and devices | sessions_and_devices | Identity-provider sessions, application sessions, browsers, and managed devices. |
| Tokens and keys | tokens_and_keys | Personal access tokens, API keys, SSH keys, deploy keys, and app passwords. |
| Shared secrets to rotate | shared_secrets_to_rotate | Credentials known to the subject that cannot be individually revoked. |
| Owned assets to transfer | owned_assets_to_transfer | Automations, scheduled jobs, repositories, files, calendars, and recovery duties. |
| New owner | new_owner | The accountable owner accepting transferred assets and automations. |
| Local or offline copies | local_or_offline_copies | Clones, downloads, caches, exports, and offline devices requiring separate handling. |
| Revocation evidence | revocation_evidence | Privacy-reduced references to completed administrative actions and audit events. |
| Verification test | verification_test | The controlled negative-access and replacement-automation checks performed. |
| Residual access or exception | residual_access_or_exception | Any unresolved path, its risk owner, and the deadline for closure. |
| Completed time | completed_at | When the coordinator completed the workflow. |
| Approver | approver | The person who reviewed the evidence and accepted any documented exception. |
Primary-source boundaries
Revocation controls do not all end the same access.
Check the exact provider, plan, identity model, and application in use. These sources document available controls; they do not independently prove that a specific offboarding event was complete.
| Source | Control | Documented boundary | Checked |
|---|---|---|---|
| NIST | SP 800-53 account management and personnel termination | AC-2 and PS-4 establish account-lifecycle and personnel-termination controls, including defined notification and access-termination timing. CapitalGuard applies those control ideas to human and agent-linked identities; NIST does not certify this checklist. | 2026-07-29 |
| GitHub | Remove an organization member | Removing a member ends organization access, but GitHub warns that local copies can remain, indirect enterprise access may persist, and forks controlled by other organizations can retain separate access. | 2026-07-29 |
| GitHub | Review and revoke organization token access | Organization owners can review and revoke fine-grained personal access tokens that reach organization resources. GitHub notes that this interface does not revoke classic personal access tokens and that SSH keys created by a revoked token continue to work. | 2026-07-29 |
| GitHub | Revoke SAML sessions and authorized credentials | Enterprise owners can revoke linked identities, active SAML sessions, and SSO authorization for tokens or SSH keys. GitHub states that revoking SSO authorization does not delete the underlying token or SSH key. | 2026-07-29 |
| GitHub | Review and revoke GitHub App authorization | A user can revoke a GitHub App authorization granted through their account. GitHub says organization owners cannot revoke a member's personal authorization, but can uninstall the app from the organization to stop its access to organization resources. | 2026-07-29 |
| Microsoft | Revoke Microsoft Entra user access | Microsoft documents disabling the user, revoking refresh tokens, and disabling registered devices. It also warns that applications can issue their own session tokens, which must be revoked under each application's authorization policy. | 2026-07-29 |
| Google Workspace | Delete or remove a managed user | Google documents transferring important business data before deleting a managed user. Deletion blocks access to organizational Workspace services, while data that is not transferred can be deleted and cannot later be recovered. | 2026-07-29 |
| Google Workspace | Suspend access and revoke active credentials | Google documents suspension, password reset, sign-in-cookie reset, OAuth-token revocation, and app-password removal as distinct controls. Suspending a user resets sign-in cookies and OAuth tokens. | 2026-07-29 |
When a repository baseline is useful
The register records actions. A scoped scan can help map repository exposure.
CapitalGuard can assess an authorized repository boundary before or after an access change. It does not revoke provider accounts, prove deletion of local copies, guarantee prevention, or replace the provider's administrator controls.
If the access change follows suspicious agent activity, preserve the evidence with the AI-agent incident response checklist before cleanup.
Method: direct NIST, GitHub, Microsoft, and Google documentation checked on July 29, 2026. Limitations: this checklist is not legal, HR, compliance, or forensic advice. A completed register does not prove that data was never copied, every third-party session ended, an offline device was wiped, or future misconfiguration cannot restore access.