# AI agent offboarding checklist for controlled exits An employee exit is one of the few times when access control gets tested against a clock. The ordinary account-disable runbook is not enough for AI agents, because the useful work often happens through local processes, unattended jobs, shared API credentials, SSH material, and copied configuration outside the departing employee's identity. Treat offboarding as a controlled transfer of authority, not as an IT cleanup task. You need to stop new actions, identify work already in flight, replace shared authority, and preserve records before anyone deletes the evidence that explains what happened. ## A disabled identity does not revoke every route to production Disabling a directory account stops only the access paths that actually consult that directory at the time of use. It does not revoke an API token in a local configuration file, an SSH private key loaded in an agent workspace, a cloud access token issued earlier, or a shared service credential injected by a CI job. This distinction gets blurred because a person, an agent process, and a credential often appear under one employee name in a dashboard. They are different things, and they need different actions: - A human identity answers who authenticated. - A local agent process answers what can act on the employee's machine right now. - A credential answers what a remote service will accept. - A session or job answers what may already be doing work. - An audit record answers what you can later prove. Getting the distinction wrong creates a familiar failure. HR marks the employee as departed at 09:00. IT disables single sign-on at 09:05. At 09:20, a scheduled agent task runs on a laptop that has not yet been collected. It uses a shared deployment token stored in its environment and changes a production setting. Every team involved can truthfully say it removed the employee's account. None of them removed the authority that the agent used. Start the exit ticket with a fixed question: "Which actions could still succeed if the employee's normal login stopped working?" Do not accept "their account is disabled" as an answer. NIST SP 800-53 puts related controls in separate families for a reason. AC-2 covers account management, IA-5 covers authenticator management, and AU-9 covers audit information protection. Teams that collapse all three into one checkbox usually discover the missing work after an incident. ## Freeze action paths before collecting the laptop Stop remote authority first, because physical collection can take hours and a powered laptop can keep running. The person running the exit should notify the security owner and the service owners, then put a short hold on automated actions attributable to the departing employee or their workstation. The first pass should cover these paths: 1. Revoke active remote sessions where the identity provider, cloud, source control host, or privileged-access system supports it. 2. Disable or isolate registered build runners, scheduled agent jobs, and remote development sessions owned by the employee. 3. Remove the device from trusted-device, VPN, and management access where your operations process allows it. 4. Pause unattended tasks that can deploy, alter infrastructure, send messages, or write to customer systems. 5. Collect the workstation or place it under managed network restrictions before the employee loses supervision of it. Do not begin by deleting local files. If the departure is disputed, unusual, or tied to a security concern, preserve the device state under your incident procedure. A rushed wipe destroys shell history, agent transcripts, local configuration, job queues, and timestamps that may answer whether an action was authorized. For an ordinary planned departure, the security owner can decide that normal device return and reimaging rules apply. That decision should appear in the ticket. It should not live in someone's memory. A useful control point is the agent's process boundary. Record the executable path, parent process, process identifier, start time, working directory, and code-signing authority before terminating a locally running agent. On macOS, an operator can collect a basic process snapshot like this: ```sh ps -axo pid,ppid,user,lstart,command | grep -i '[a]gent' # Output shape: # 8421 611 alice Tue Mar 12 09:14:22 2025 /usr/local/bin/agent-run --task release ``` The command is not proof by itself. It gives an investigator a time-bound lead and prevents the vague claim that "an agent was running" from becoming the entire record. ## Build an authority inventory, not a software inventory A list of installed AI tools does not tell you who can alter a service. Inventory every authority path, including tools you may not call AI. The employee may have used an agent through a terminal, an editor extension, a CI runner, a local script, or a remote environment. The route matters more than the label. Use one row per credential or identity relationship. If one token can reach three services, list its three consequences in the scope field rather than burying them in notes. | Authority path | Where it lives | What it can do | Owner after exit | Action | Evidence | | --- | --- | --- | --- | --- | --- | | Personal source control identity | identity provider | read and write repositories | engineering manager | revoke sessions and disable account | ticket ID and timestamp | | Shared deploy token | CI secret store | deploy selected environments | release owner | replace and revoke old token | rotation event | | SSH private key | workstation and target hosts | shell access to listed hosts | infrastructure owner | remove public key and issue replacement | host change record | | Agent job registration | build service | start scheduled work | platform owner | disable registration and inspect queue | job export | | Local agent configuration | workstation profile | points to endpoints and secret names | security owner | preserve or remove under hold decision | collection receipt | The hard part is finding shared authority. Ask service owners direct questions: Does this employee know a token that outlives their account? Did they administer a bot account? Can their device connect with an SSH key? Did any job run under a generic identity? Who receives alerts from that job after today? Do not make the departing employee the sole source for this inventory. They can help, but repositories, secret stores, authorized-key files, CI configuration, service ownership records, and audit logs must corroborate the answer. People forget a token created during an outage. People also forget a test runner that became production infrastructure two years later. ## Rotate shared credentials in dependency order Rotate any shared credential that the departing person could have read, copied, exported, or used outside a reliable identity-bound revocation path. This includes API keys, basic-auth passwords, webhook secrets, deploy tokens, database passwords, SSH keys, cloud access keys, and recovery codes. The popular but wrong recommendation is to rotate everything simultaneously. It feels decisive, and it produces an impressive list of changed secrets. It also breaks unknown dependencies, makes troubleshooting chaotic, and tempts teams to restore the old secret under pressure. Rotate in a sequence that leaves an accountable replacement path open. For each credential, use this order: 1. Name the service owner and the exact callers that use the credential. 2. Create a replacement credential with the narrowest scope the service supports. 3. Update known callers and prove they work with the replacement. 4. Revoke the old credential, then test that it fails. 5. Record the replacement's custodian, its creation time, its scope, and the revocation result. A failure test matters. "Rotation completed" often means someone created a new token and updated one application. It does not mean the old token stopped working. Run a harmless authenticated request that the old credential formerly allowed. Record the service's expected denial response, such as HTTP 401 or 403, rather than pasting secrets into the ticket. For SSH access, remove the departing person's public key from every target authorized-keys source and from any central access system. Then find automation that uses the same private key. If an agent used a shared SSH identity, issue a new keypair, replace the public half on targets, update the approved caller, and retire the old public key. Removing a key from only the workstation does nothing to a copied key. Never send the replacement through chat or email as part of the handover. Give the new owner permission to obtain or use it through the approved secret mechanism. The point of rotation is to shrink the number of copies you cannot account for. ## Shared accounts require a named human owner A service account can be legitimate, but a shared account with no named operator is a way to hide an ownership problem. The handover must name a person who accepts responsibility for the account's purpose, scope, billing, recovery route, and future credential rotation. Separate operational ownership from the credential itself. A release bot may need to keep deploying after an employee leaves. That does not mean the replacement employee should inherit the former employee's personal token or use their local configuration. Give the bot its own identity where the service permits it, attach only the permissions it needs, and make the new owner accountable for it. Write a short handover record that answers five points: - What service or workflow does the account support? - Which environments and actions can it reach? - Which systems call it today? - Who can change its credentials or recover it? - When will someone review whether it still needs this access? This is also where teams find agent assumptions disguised as convenience. A local configuration may tell an agent to use a generic deployment identity because the original developer lacked time to set up a dedicated one. Do not preserve that shortcut in the name of continuity. Replace it with an owned access route before restarting work. ## Preserve records before retention jobs erase them Keep records that let you reconstruct authority and actions without relying on a departing employee's explanation. Capture the exit ticket, access inventory, identity-disable event, session revocations, rotation events, CI job history, agent run records, endpoint collection decision, and service audit exports. Record the time zone and the clock source if systems differ. Preservation differs from copying a few screenshots. A screenshot drops fields, hides filters, and can rarely be verified. Export original records in their native form where possible, preserve hashes for collected files, restrict access to the case group, and document who handled each copy. The following collection note is compact enough to use and specific enough to audit: ```text Case: OFF-2025-041 Collected by: security-operator Collected at: 2025-03-12T09:37:16Z Source: build-service job history export Range: 2025-03-01T00:00:00Z to 2025-03-12T09:37:16Z File: build-jobs.json SHA-256: Storage: restricted evidence repository Reason: employee exit and agent authority review ``` Keep the original export unchanged. If an investigator filters it or annotates it, save that as a separate working copy. This simple separation has prevented more arguments than elaborate forensic tooling: people can inspect the analysis without quietly changing the source record. NIST SP 800-92 describes log management as a process of generation, transmission, storage, analysis, and disposal. The weak point in offboarding is usually disposal. A short default retention period may purge the one run record needed to establish whether an agent acted before or after the access change. Put a retention hold on records that your policy permits you to retain, then release the hold through the normal process. ## Make agent authorization revocable per process A developer's approval for one agent process should not become blanket permission for every process that can appear on their machine. A process can be replaced, relaunched from a different working directory, or invoked by an editor extension after the person leaves. The authorization record needs an identity for the process and an immediate revoke path. This is where a gateway can help, but only if it refuses to hand credentials to the agent. Sallyport keeps API and SSH credentials in an encrypted local vault, authorizes new agent processes per session by default, and records sessions and individual actions separately. For offboarding, export or preserve the relevant session and activity records, revoke live sessions, and lock the vault before device transfer. That order gives you a meaningful boundary: the agent cannot make a new external call while the record of its prior calls remains available for review. Do not confuse per-session approval with approval for every consequential action. An agent might legitimately need a session to read a repository while every production-changing credential needs confirmation on each use. Put the stricter control on credentials whose misuse would force an incident response, not on harmless read-only calls that will create approval fatigue. Approval fatigue is a design failure. If people receive a prompt for every routine request, they stop reading prompts. If they receive one prompt that silently covers access to unrelated production systems, the prompt is too broad. Good authorization creates a clear boundary that an operator can explain after the fact. ## Inspect running work and delayed triggers Account revocation does not reliably stop work already accepted by a remote service. Check queued builds, remote shells, automation schedules, repository workflow dispatches, package publication jobs, infrastructure plans, and message queues that can start work later. For each running or queued item, decide whether to cancel, let it finish under observation, or transfer it to a new owner. The decision should depend on the action, the blast radius, and whether the task can be reproduced. A deployment with a known change record may be allowed to finish. A task that can alter access controls or move data should normally stop until its owner confirms the intent. Capture identifiers before cancellation. A job URL alone is poor evidence if the service deletes job detail after a retention period. Store the job ID, triggering identity, commit or task reference, start and finish times, permissions used, and outcome. If the task failed during the exit, note whether the failure came from your revocation. Otherwise a future investigator may misread an access-control success as an operational fault. Also inspect delayed execution. Cron entries, launch agents, CI schedules, cloud event rules, and repository workflows can resume activity after the team believes the exit is over. A recurring task should move to a managed owner or be disabled. Leaving it enabled under an abandoned account makes the next failure both predictable and hard to diagnose. ## Close only when an independent person can verify the result The person making changes should not be the only person who declares the exit complete. Ask a security peer, service owner, or manager to verify the items that matter most: the former identity cannot sign in, old shared credentials fail, no scheduled agent work remains under the former owner, and the evidence collection is readable and protected. Use a closure statement that names tested facts rather than vague completion: ```text Former identity: disabled and active sessions revoked Shared credentials: 6 inventoried, 6 replacement paths tested, 6 prior credentials revoked Agent work: 2 scheduled jobs transferred, 1 queued job canceled Evidence: exports and collection hashes stored under case OFF-2025-041 Exceptions: none Verified by: service owner and security reviewer ``` If a credential cannot be rotated immediately, keep the ticket open and record the compensating restriction, responsible owner, and deadline. "We will do it later" is not a control. A firewall restriction, disabled workflow, or temporary service suspension can be a control if somebody verifies it and knows when it expires. The first useful change is simple: add an authority inventory and an evidence hold decision to the existing HR exit ticket. Those two fields force the right conversation before a laptop disappears, a token survives, or a log retention job removes the only record of an agent action.