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

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.

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.

Related resources from NHI Mgmt Group

• What happens when a breached third party still has active access to internal systems?
• Who should own revocation when an employee leaves and AI tools still have access?
• What happens when a third-party credential-flow integration gains persistent IdP access?
• What happens when attackers target third-party systems that still hold sensitive employee or operational data?