When an Employee Leaves, Who Revokes Their AI Agent's Access?

Most IT teams have a solid offboarding checklist. Disable the Okta account. Revoke VPN. Remove from Slack and Microsoft 365. Transfer document ownership. Collect the laptop. Deactivate the badge.

For most organisations, this runs cleanly. A single Okta disable cascades through SSO-connected applications, and access is gone within hours. The process was built over years of experience with a specific threat model: a departing employee, with their credentials, trying to access company systems after their last day.

That model has a gap now. And it's not a theoretical one.

The Connections That Don't Live in Okta

When an employee uses an AI tool — Claude Code, GitHub Copilot, Cursor, whatever they run — and connects it to internal systems via MCP, they're creating connections that typically live entirely outside your centralised identity infrastructure.

Here's what that usually looks like in practice.

A developer opens their Claude Code settings file and adds a list of MCP servers: the company's GitHub MCP server, the Jira MCP server, the internal documentation system. For each connection, they authenticate — sometimes via OAuth (which does touch your identity infrastructure), sometimes via API keys they generate directly from each service.

Those API keys are stored locally. On the laptop. In a configuration file. And they're service-specific credentials, not SSO credentials.

Here's the critical part: when you disable the employee's Okta account, those API keys don't get revoked. They're still valid. They're still stored on the machine that's sitting in someone's bag on the way to the exit interview.

Before the laptop is collected and wiped, there's a window. And that window matters more than it used to, because the friction between "has credentials" and "can do something consequential" is essentially zero when an AI agent is involved. A human with leftover credentials has to deliberately decide to use them. An agent configured to run on a schedule doesn't need to decide anything.

Walking Through a Real Offboarding Scenario

Here's what a problematic offboarding can look like with distributed MCP configuration:

Day 0: Senior engineer resigns. Departure date is in two weeks.

Day 14 (last day): IT disables Okta account. Email and Slack access gone. Application access revoked via SCIM. Laptop collected and sent for wiping.

- The engineer had configured Claude Code with six MCP servers: GitHub, Jira, the internal data warehouse, Confluence, Slack (API key, not OAuth), and a custom internal API for the deployment system.
- GitHub: connected via a personal access token the engineer generated 8 months ago. Not linked to SSO. Not in any registry.

- Slack: connected via a bot token the engineer generated from a personal Slack app they created.

- Internal data warehouse: connected via API key from the data platform team's shared credential pool. The engineer had their own copy.

- The deployment system: connected via an API key with write access.

Day 15: The engineer's GitHub token, Slack token, and API keys still work. If an automated agent workflow was configured to run on a schedule, it's still running. The credentials are on a laptop that hasn't been wiped yet — and depending on your MDM setup, the wipe may not happen for days.

This is the scenario that's hard to account for with distributed MCP configuration. The credentials that matter were never centralised. You can't revoke what you don't have visibility into.

The Contractor Version Is Worse

The departing employee case is at least manageable — there's a defined offboarding event, a checklist, a laptop return (usually).

The harder version is contractors.

A contractor works with the engineering team for three months. During that time they set up their AI tooling with MCP connections to relevant systems. They generate API keys from each service they need. They do their work and leave.

There's often no laptop return. There's often no formal IT offboarding process — just an Okta account disable. The service-specific credentials the contractor created may not be revoked. And unlike an employee, there's no "2-week notice period" where IT could catch this. Contracts end, sometimes with a day's notice, sometimes with no notice at all.

If those credentials authenticated their agent's access to internal systems, they persist until someone explicitly revokes them — or until they expire if they were time-bounded (they often aren't). Meanwhile, the contractor is gone and the connections are invisible. Nobody knows they exist. Nobody's watching them.

This is particularly acute for:

• Engineering contractors who typically have the broadest system access and the most MCP connections

• Security contractors who may have had access to sensitive systems specifically for their engagement

• Data analysts who may have connected to internal data warehouses with read-heavy credentials

• IT consultants who may have had admin-level access to systems they were configuring

What Good Offboarding Looks Like in an MCP Environment

The principle is the same one that made centralised SSO the standard for application access: credentials that live in one place can be revoked in one place.

For AI agent access, that means the credentials that authenticate agent connections to internal systems should live in the gateway — not on individual laptops.

Here's how the architecture changes the offboarding picture:

With a gateway: The employee's AI tool (Claude Code, Copilot, Cursor) is configured to point to one URL — the company gateway. The gateway authenticates to downstream systems using credentials that IT manages and controls. The employee's local configuration doesn't contain API keys for GitHub, Jira, or the data warehouse. It contains the gateway URL and their own SSO credentials.

When the employee leaves:
1. IT disables their Okta account (same as today)
2. SCIM propagates that event to the gateway
3. Gateway access is revoked
4. Every downstream MCP connection that flowed through the gateway stops

No orphaned API keys to track down. No service-by-service revocations. One action with complete effect.

This also makes the contractor case tractable. If all agent access flows through the gateway, offboarding a contractor is the same operation as offboarding an employee — regardless of whether they return equipment.

The Offboarding Audit Question

Revocation is one half of the offboarding challenge. The other half: what did the agent do before you revoked its access?

This is a question that comes up in two contexts:

Security review: If there was any reason to suspect the employee might have used AI agent access inappropriately during their notice period, IT needs to be able to reconstruct what happened.

Compliance and data governance: For regulated industries, departure of employees with access to sensitive systems may require demonstrating that their access was appropriately terminated and that no unauthorised data movement occurred in the period leading up to departure.

With distributed credential management, answering these questions requires pulling logs from GitHub, Jira, Salesforce, the data warehouse, Confluence, and every other system the employee's agent might have connected to — in different formats, with different retention periods, with no way to distinguish agent-initiated actions from human-initiated ones in most cases.

With a gateway: the audit trail is in one place. Every tool call is logged — what tool, what parameters, what response, when, on whose behalf. The question "what did this employee's agent do in their last 30 days of employment?" has a fast answer.

Updating the Offboarding Checklist

The checklist that most IT teams run today is essentially correct. Disable Okta, revoke VPN, remove application access, collect the device. What's missing is the MCP layer — specifically, the question of whether agent-to-system connections are centralised enough that a single revocation covers everything.

The updated checklist looks like this:

• Disable Okta/Entra account ✓ (existing)

• Revoke VPN ✓ (existing)

• Remove SaaS application access via SCIM ✓ (existing)

• Collect and wipe device ✓ (existing)

• Revoke gateway access → covered automatically by the Okta SCIM event if the gateway is properly integrated

• Audit agent activity for the offboarding period → available from gateway audit log if all agent traffic flowed through it

The last two items are only checkable if the gateway architecture is already in place. If employees have been configuring MCP connections directly, neither item is quickly addressed.

Most enterprises are somewhere in the middle — some employees in the centralised model, some in the distributed model, no clear policy about where credentials should live. Getting ahead of that, before the first uncomfortable offboarding incident, is the governance question on IT's desk right now.

FAQs

What if an employee uses OAuth for their MCP connections instead of API keys? Doesn't that make revocation cleaner?

OAuth-based connections are better — revoking the user's application access in your IDP does revoke their OAuth token for OAuth-based MCP servers. The problem is that many MCP servers don't use OAuth, or employees use API keys for convenience alongside OAuth connections. A gateway eliminates this inconsistency: the employee's connection to the gateway uses SSO (clean revocation), and the gateway manages downstream credentials regardless of whether those systems use OAuth, API keys, or token pass-through.

How do we handle this for employees who leave on bad terms?

The gateway architecture matters most in this scenario. With distributed credentials, a disgruntled departing employee has a window between Okta disable and laptop wipe where locally-stored API keys remain valid. With a gateway where credentials are centralised, Okta disable = gateway access revoked = agent access revoked, with no window. This is one of the few IT security scenarios where the centralised architecture is clearly better on day one of deployment, before it's fully rolled out.

Is there a good way to audit existing API keys that employees may have created before the gateway was deployed?

Yes, though it requires system-by-system audit work. Most systems (GitHub, Salesforce, Slack, etc.) maintain a list of personal access tokens and API keys per user in their admin console. An offboarding sweep for employees who had MCP access pre-gateway should include manually reviewing and revoking these. It's tedious, which is exactly why the gateway architecture matters — it makes future offboardings clean while you close the historical gap manually.

Should we require employees to use the gateway before we have it fully deployed?

The practical approach: establish the gateway as the required path for new MCP connections starting from deployment day. Employees already have direct connections; those get migrated in waves, prioritised by risk level. Existing connections for employees who are clearly not leaving don't need to be the first priority. The priority is ensuring that any new connections from that point forward go through the gateway, and that the highest-risk employees (those with the most system access and most likely to use AI tools extensively) are migrated first.

What does credential management look like for team-shared MCP servers (not user-specific)?

Some MCP servers are configured at the team or department level rather than per-user — a shared data analytics MCP server, for example. These credentials should live in the gateway with the gateway acting as the authenticating principal, not tied to any individual user's identity. Team-shared credentials in the gateway are managed by IT, rotated on a schedule, and not affected by individual employee offboarding events. The gateway still enforces user-level policy (which employees can call which tools) even when the underlying credential is shared.