How to Offboard a Contractor Who Had Agent Access

An offboarding checklist that depends on a manager remembering to open a ticket will fail on the day a contract ends early. Attach the checklist to events instead. Any of these should open the same ticket automatically, with the same owner and the same sign-off requirement:

Two design notes matter. First, the trigger must create the ticket, not just a reminder, because the work needs an audit trail. SecureSlate's guidance on access reviews is blunt about this: an unapproved review is not evidence, and auditors expect a named approver with a date (SecureSlate access review template). Second, if your reviews keep finding departed contractors with live accounts, the review is working and your offboarding is broken, so fix the offboarding rather than reviewing more often (SecureSlate).

CISA's Cyber Essentials frames the same idea for access generally: the authority you grant into your digital environment needs limits, and setting approved access privileges requires knowing who operates on your systems and with what level of authorization and accountability (CISA Cyber Essentials Starter Kit). Agent credentials belong in that inventory too.

Work from the identity outward. The order matters because each step tells you what to look for next.

1. Disable the identity provider account. This cascades to SSO-connected apps, but treat it as step one of six, not the job. Blocking new sign-ins is not evidence that every application session or token has stopped working (Elba offboarding checklist).
2. Kill active sessions and refresh tokens. A disabled account with a live session is still a live account. Review the provider's documented procedure for credentials, sessions and authorized apps before deletion (Elba).
3. Revoke personal access tokens the contractor generated. This is the step most teams miss. The token was made eight months ago, is not linked to SSO, and appears in no registry (Scalekit).
4. Revoke or reassign non-human credentials tied to the agent. Bot tokens from personal Slack apps, deployment API keys with write access, and read keys into the data warehouse all fall here (Scalekit).
5. Remove the agent's MCP server configuration and OAuth grants. Review direct sign-ins, guests, privileged roles and OAuth grants separately, and keep unknown coverage explicit rather than assuming full visibility (Elba).
6. Do not delete shared or service accounts solely because the contractor used them. Preserve business continuity: identify files, mailboxes, billing ownership and automations that depend on the account and assign future owners first (Elba).

A useful mental model comes from WorkOS's agent permissions checklist: give every agent its own identity separate from the user it serves, and never pass the user's session or access token to the agent, exchanging it instead for a new, narrower token (WorkOS AI agent permissions checklist). If you built it that way, revoking the agent identity is clean and fast. If you did not, you are hunting tokens today, which is why the next step is non-negotiable.

Rotate on the assume-compromise principle: rotation after exposure is the only safe default, and you cannot revoke what you cannot see. An audit should record a secret's type, location and permission, never its value, so the audit does not become the next leak (MavenHandle).

The rotation set is wider than "secrets the contractor personally created." It is every secret the agent's configuration could read or use. Use this checklist to scope it:

Two practical cautions. Rotation is easier said than done at scale: manual processes and fear of downtime are the main reasons teams skip it, so automate where you can and stage the cutover (Doppler on secrets rotation). And rotation closes the credential, not the historical exposure: if the agent read data during the engagement, the fix is a determination about that data, covered in the next section.

A worked figure helps set scope. If your secrets inventory for one contractor engagement lists 14 distinct credentials across GitHub, Jira, a data warehouse, a deployment system, Slack and a database, the rotation is 14 changes plus verification, not a single password reset. Budget the ticket accordingly and write the count into the evidence record.

Pull logs from the first day of the engagement to the revocation timestamp, not just the last week. The question the logs answer is specific: what did the agent do on the contractor's behalf? WorkOS reduces this to five questions every agent request should be able to answer: who is the agent, who is it acting for, what it is allowed to do in general, is this action allowed right now, and can you prove what happened and undo access (WorkOS).

If your logging records both identities plus the decision for every action, you can reconstruct the tenure. If it does not, that gap is a finding in itself. WorkOS lists "log both identities (agent and user) plus the decision for every action" as one of eight minimum controls (WorkOS).

Look for four patterns:

• Volume and breadth of data reads. A agent reading a table it never needed is a signal, especially if the read happened late in the engagement.
• External calls. Any outbound request to a domain you do not own deserves an explanation. The risk with agents is that the gap between "has credentials" and "can do something consequential" is essentially zero, and a schedule-configured agent does not need to decide anything (Scalekit).
• Configuration changes. Deploy keys, CI settings, repository ownership, webhook targets.
• Untrusted input handlers. An agent reads content, and content can contain instructions, so any action that followed text from an external source needs human review (UiChemy WordPress agent checklist).

A small filter helps you triage. Export the log and pull the exceptions rather than reading everything:

Filter agent action log where:
  actor = contractor's agent identity
  timestamp between engagement_start and revocation_time
  AND ( destination_host not in allowlist
     OR data_class in (restricted, regulated)
     OR action_type in (deploy, config_change, credential_create, external_write)
     OR called_after_contract_end = true )

The last clause is the one that catches the real problem: agent workflows configured to run on a schedule keep running after the last day unless someone kills them (Scalekit).

Logs do not close incidents. Someone has to classify each hit and record a decision. A three-way classification keeps this fast:

CISA's guidance for small organizations is relevant to how you handle the third row: review and approve the incident response plan before you need it, and invoke it even when you suspect a false alarm, because near misses drive improvement (CISA Cyber Guidance for Small Businesses). An agent that called an unknown host after the contract ended is exactly the kind of near miss worth invoking the plan for, even if the data turns out to be benign.

This is also where the sign-off requirement earns its keep. SecureSlate's access review guidance is that the departure of a person is an access question, and the evidence is a named approver with a date, with removals logged by username, system, role removed, date, reason and ticket link (SecureSlate). Elba makes the same point for SaaS offboarding: track one account per application, keep a requested change separate from a source-verified result, and assign each source change and record who checked the result, when, and where the evidence is retained (Elba).

The sign-off is not a formality. It converts a set of actions into a record you can defend in an audit or a client review, and it forces a second pair of eyes onto the rotation list.

A sign-off record that survives scrutiny contains six fields per line item: asset, change made, who made it, who verified it, verification method, and evidence location. Leave unresolved items open rather than marking them done, and store evidence references rather than passwords, tokens or copied personal data (Elba). A verification re-scan that confirms each item is actually closed is the difference between a shut door you can point to and a findings list you are left to act on alone (MavenHandle).

The 24-hour target is a design constraint, not a deadline. It works because each step is bounded: revocation is a fixed list of identities, rotation is a counted set of secrets, and log review is a filtered query, not a reading exercise. If your log retention cannot answer the query within 24 hours, that is your investment priority, not a reason to extend the deadline.

WorkOS's eighth minimum control is the one teams skip: make revocation instant and cascading, and test it before you need it (WorkOS). A quarterly drill takes about an hour and pays for itself the first time a contract ends at 4 p.m. on a Friday.

Run it like this: pick a low-risk internal agent identity, revoke it at the identity provider, and time how long until its tool calls fail. Then check whether its API keys still work, whether its scheduled jobs still fire, and whether its logs answered the four patterns above. Record the elapsed times. If revocation depends on someone remembering a local config file on a laptop, you have found the same gap Scalekit describes (Scalekit).

For teams that want the identity layer to do the cascading for them rather than tracking tokens by hand, putting every model behind one credentialed API is a structural fix: agent traffic gets a single key you can revoke, and model calls appear in one log. Quanta Inference covers text, image, video, audio and embedding models through one API key and is OpenAI-compatible with prepaid pricing in US dollars (https://quantaintelligence.ai/inference). If your team manages several agents and contractors at once, a shared credit pool with an API key per person and admin controls makes the revocation list short and observable (https://quantaintelligence.ai/for-teams).