What happens when an employee leaves but their AI agent or third-party integration still has active access?

When an employee leaves, the IdP account may be disabled while the underlying app-issued tokens keep working. The integration can continue reading mail, posting data, or authorizing actions because its refresh tokens and delegated permissions were never governed by the IdP. That creates a persistent access path that offboarding missed and attackers can later abuse.

Why access survives an employee exit when the integration was never tied to the IdP

The real issue is not that the person is still employed, it is that an app or agent can retain its own authorization path after the human account is removed. In practice, the integration may keep using refresh tokens, delegated consent, service credentials, or platform-issued tokens that live outside the IdP lifecycle, so the business process continues even though the user is gone.

That separation is common in SaaS integrations and AI-assisted workflows: the human identity is easy to disable, but the app-level grant is what keeps the connection alive. If ownership, expiry, and revocation are not governed at the same layer as the token or permission, offboarding only removes one control point.

The access can remain valid for mail, files, CRM actions, data sync, ticketing, or posting functions until the token expires or is explicitly revoked.
If the integration was consented once and then forgotten, it can become a durable back door rather than a temporary convenience.

What persistent access looks like in real environments

This pattern usually appears where the application, not the employee, is the effective actor. A third-party integration may authenticate with OAuth refresh tokens, API keys, signed certificates, or a managed app registration, while the employee merely approved or installed it during onboarding or during a project.

When the employee leaves, administrators often disable the directory account and assume the access path is closed. But if the app has cached authorization or delegated scope, it can still read messages, modify records, or trigger downstream actions until someone reviews the connected app, rotates secrets, or removes consent. That is why these cases often survive routine offboarding.

For AI agents, the failure mode is similar but can be more consequential because the agent may continue to act through connectors long after the original owner departs. If the agent can still reach tools or data sources, the loss of the human user does not stop the autonomous workflow.

What should be governed at offboarding, not after a later incident

Offboarding needs to include the non-human access path, not just the employee account. The relevant question is whether the integration can still authenticate, refresh, or delegate without the departed person’s active oversight.

That means teams should review which applications were authorized by that user, which of them hold long-lived or refreshable credentials, and whether the access is personal, shared, or service-owned. Where the integration is business-critical, the safest pattern is to transfer ownership before the employee exits, then revoke the old grant and verify that the replacement credential is the only active path.

Inventory connected apps, bots, and third-party integrations tied to the user.
Revoke delegated consent and rotate any app secrets or refresh tokens.
Reassign ownership, not just login access, for critical automations.

Risk and Threat Considerations

Persistent app access turns a routine departure into a standing exposure window. If the token or delegated grant is not revoked, a former employee, a compromised integration, or an attacker who later steals the token can continue to act with the original permissions even though the human account has been disabled.

Failure mechanism: The organization removes the user directory account but leaves behind app-issued tokens, delegated permissions, or third-party credentials that are independently valid and not tied to the IdP offboarding event.

Impact: Unauthorized reading, posting, data export, workflow execution, and privilege persistence can continue after departure, creating a delayed compromise path that is harder to detect and often blamed on an already-closed account.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 addresses the attack surface, NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
OWASP Non-Human Identity Top 10	NHI-01 — Improper Offboarding	Directly covers orphaned non-human access after employee exit.
	NHI-07 — Long-Lived Secrets	Refresh tokens and delegated credentials can persist beyond offboarding.
	NHI-05 — Overprivileged NHI	Leftover app access may continue with permissions beyond the user's need.
Recommendation — Revoke app grants and transfer ownership before disabling the user. Rotate or expire long-lived tokens that outlast the employee lifecycle. Reduce remaining app permissions to the minimum required scope.
NIST SP 800-53 Rev 5	IA-5 — Authenticator Management	Token, secret, and credential lifecycle management is central to the issue.
	AC-2 — Account Management	The problem is incomplete removal of access paths during offboarding.
	AC-6 — Least Privilege	Residual grants often leave integrations with more access than needed.
Recommendation — Manage, rotate, and revoke authenticators when ownership changes. Remove or reassign accounts and linked access when personnel depart. Limit delegated and app permissions to the minimum necessary scope.
CIS Controls v8	CIS-5 — Account Management	Offboarding must include connected app and service access removal.
	CIS-6 — Access Control Management	Delegated permissions and app grants need explicit revocation.
Recommendation — Remove or disable all accounts and connected access tied to departing staff. Revoke application access paths that survive human account disablement.
NIST CSF 2.0	PR.AA-05 — Managed Access Control for Assets and Services	Persistent app permissions are an access-control lifecycle problem.
Recommendation — Enforce revocation of stale access paths tied to departed users.
ISO/IEC 27001:2022	A.5.15 — Access control	The issue is unmanaged persistence of access after role change or exit.
Recommendation — Require explicit revocation of access when ownership changes.

Practitioner Guidance

What to verify: Confirm whether the integration authenticates with user-bound consent, app-level credentials, or both. If the app can still act after the human account is disabled, treat the offboarding as incomplete until the app path is revoked or reassigned.

Decision rule: If the integration can reach production data or perform write actions, prioritize token revocation and ownership transfer before you worry about whether the departed employee ever misused it.

What good looks like: Every departure produces a clean separation between human access removal and application access removal, with a recorded owner for each remaining automation and a test that proves no orphaned token is still active.

Practitioner takeaway: The important control is not “disable the user,” it is “remove every remaining authority path that user enabled,” because the leftover token, grant, or integration is what attackers will use.