MCP Credentials and Employee Offboarding: How to Prevent Orphaned Agent Access

An employee leaves. IT disables their account, revokes SSO and VPN access, and collects the laptop. The checklist looks complete. But an AI agent they configured may still hold a static token for a database, ticketing system, or internal knowledge base. If that credential was issued outside the corporate identity lifecycle, it can continue working after the employee is gone.

This is not an inevitable weakness in the Model Context Protocol. It is an identity and credential lifecycle problem that becomes easier to create when employees can connect agents to tools without a centrally governed authorization path.

First, there is no standard “MCP key”

MCP standardizes how AI applications discover and call tools, resources, and prompts. It does not define a special credential named an MCP key. For HTTP transports, the current MCP authorization specification defines an OAuth-based authorization flow. Authorization remains optional at the protocol level, and stdio transports are expected to obtain credentials from their environment rather than use that HTTP flow. In practice, an MCP connection can involve several different credentials:

1. The employee or agent authenticating to the MCP server. A remote HTTP server may use OAuth access tokens tied to a corporate identity, while an older or custom deployment may accept a static API key.
2. The MCP server authenticating to a downstream system. The server may use a separate OAuth grant, workload identity, service account, or database credential to reach the tool behind it.
3. A local MCP server reading credentials at runtime. A server launched over stdio often receives secrets from the local environment or client configuration. Those secrets can be copied if they are stored as plaintext on an employee device.

The dangerous case is not “MCP” by itself. It is a long-lived bearer credential that is stored on an endpoint, grants meaningful access, and has no dependable link to the owner's identity or employment status.

What the current MCP authorization spec changes

A conforming HTTP deployment has stronger building blocks than an ad-hoc API-key integration. The July 2026 specification requires OAuth authorization metadata discovery, PKCE, resource indicators, and validation that a token was issued for the specific MCP server. It also forbids an MCP server from simply passing the client's token through to an upstream API. That upstream access needs its own authorization boundary and token.

Those controls reduce token replay and confused-deputy risks, but they do not automatically solve employee lifecycle management. The organization still has to connect grants to a managed identity, issue short-lived tokens, revoke refresh tokens and downstream grants, track ownership, and ensure every server enforces current authorization.

Why ordinary offboarding can miss agent credentials

Standard offboarding works best when access flows through the organization's identity provider. Disable the account in Entra ID, Okta, or another IdP, and applications that continuously trust that identity can deny new access.

A static token issued directly by a tool breaks that chain. The IdP may not know that the token exists, which device stores it, which agent uses it, or what data it can reach. Disabling the employee's login therefore does not necessarily disable the credential. Even an OAuth deployment needs correct token expiration, refresh-token revocation, and authorization checks; SSO alone is not a complete offboarding control.

The underlying failure pattern is already familiar

This credential-lifecycle problem predates MCP. Two 2023 incidents illustrate the broader risk; neither was an MCP incident.

• Geisinger / Nuance. A former Nuance employee accessed Geisinger patient records after termination because access had not been removed promptly. Geisinger said information associated with more than one million patients may have been accessed and taken, and that the former employee was arrested and faced federal charges. The lesson is not about a particular protocol: access that outlives its owner becomes an incident path. Read Geisinger's incident notice.
• Cloudflare. A threat actor used a service token and service-account credentials that had not been rotated after an earlier Okta compromise to access Cloudflare's internal Atlassian environment. Cloudflare reported that no customer data or systems were affected, but the entry point demonstrated the risk of valid credentials that remain outside an effective revocation process. Read Cloudflare's analysis.

What the risk looks like in an MCP-connected environment

• A developer places a personal database token in a coding assistant's MCP configuration.
• A support engineer connects an agent to a ticket queue with a long-lived API key.
• An analyst runs a local MCP server with a wiki token supplied through an environment variable.
• An automation uses a shared service account, so its activity cannot be attributed to one owner.

When one of those employees leaves, their interactive login can stop immediately while the agent credential remains valid. A copied token may be usable from another device, and an unattended automation may continue calling tools without a responsible owner.

Standing access after departure

Bearer credentials authenticate whoever possesses them. If a token is not expired, revoked, bound to a managed workload, or checked against current identity state, the downstream system may see a valid request rather than a former employee.

Weak attribution and incomplete audit evidence

Shared credentials make it difficult to determine which employee, agent, or device performed an action. During an investigation, the organization may be unable to show when a credential was issued, which tools it called, what data was returned, or whether it remained active after the owner left.

Permissions that exceed the agent's purpose

A credential copied from an employee workflow often inherits broad human permissions. The agent may need to read a small set of records but receive write access to an entire system. That expands the impact of credential theft, prompt injection, or an incorrect tool call.

An architecture that survives employee offboarding

The goal is not merely to store secrets more carefully. It is to ensure that access can be discovered, scoped, attributed, and revoked from a central control plane.

1. Authenticate employees through the corporate IdP. Prefer OAuth-based access tied to the workforce identity, with conditional access and group or role claims evaluated centrally.
2. Issue short-lived, audience-restricted tokens. A token intended for one MCP server should not work at another server or be passed unchanged to a downstream API. This is also the model required by the current MCP HTTP authorization specification.
3. Keep downstream secrets behind the server or gateway. Database passwords and service credentials should live in a managed secrets system or use workload identity—not in the prompt, model context, repository, or employee-owned configuration file. Our guide to MCP credential management covers where those secrets sit today and how to move them.
4. Authorize every tool call. Enforce the current user, agent, tool, action, and resource policy on the server side. Client-side controls alone are not a security boundary.
5. Give agents their own identities. Link each agent to an owner, purpose, trust level, and approved tools. Avoid shared credentials that erase attribution.
6. Centralize audit and detection. Record authentication decisions and tool calls, redact secrets from telemetry, and flag activity from an agent whose owner is disabled or missing.

MCP offboarding checklist

• Disable the employee's workforce identity and terminate active sessions.
• Revoke refresh tokens, personal access tokens, OAuth grants, and device sessions.
• Remove group memberships, application roles, and delegated tool permissions.
• Disable or transfer ownership of every agent, automation, and service identity they owned.
• Inventory local MCP configuration files without copying secrets into tickets or logs.
• Rotate any shared credential the employee could access; revocation alone is insufficient.
• Review MCP and downstream audit logs for activity after the termination timestamp.
• Verify that high-risk tools fail closed when identity or policy services are unavailable.
• Test revocation end to end: attempt a new MCP call, refresh, and downstream tool action after the employee is disabled rather than assuming the identity-provider event propagated everywhere.

Where ContextGuard fits

ContextGuard provides a governed layer for AI and MCP traffic: a place to associate agents with identities, inspect tool calls, apply centralized policy, and retain an audit trail. Placed in front of approved MCP servers, that layer helps security teams answer the questions that scattered local configurations cannot: which agents exist, who owns them, which tools they can call, and whether activity continues after an owner is disabled.

ContextGuard complements the IdP and downstream access controls; it does not replace them. The strongest design combines identity lifecycle management, short-lived authorization, least-privilege tool access, secure downstream credentials, and policy enforcement on every call. See the ContextGuard platform architecture for the full control-plane model.

FAQ

Is an MCP key a standard type of credential?

No. MCP does not define a credential called an MCP key. Depending on the deployment, a client may use OAuth access tokens, an API key, or credentials supplied to a local MCP server. The offboarding risk comes from long-lived credentials that are not tied to the employee's managed identity.

Does disabling an employee's SSO account revoke MCP access?

Only when the authorization path is tied to the organization's IdP and the server re-evaluates that authorization. Disabling SSO does not automatically revoke a static token stored in a local configuration file or issued independently by a downstream tool.

Should employees receive database credentials for their AI agents?

Generally, no. Keep database and service credentials behind the MCP server or gateway. Give the employee and agent narrowly scoped, short-lived authorization, and use separate downstream credentials with the minimum permissions required.

What should an MCP offboarding process revoke?

Disable the workforce identity, revoke sessions and refresh tokens, remove group and role assignments, revoke downstream grants, disable linked agent identities, rotate shared secrets, and review post-termination activity in centralized audit logs.