Skip to main content
{ Identity and Access }

Google Workspace Offboarding Verification

Checks each departed user for Drive files shared outside the domain, live OAuth tokens, and access outside Workspace, and reports each open path.

What this agent does

This read-only agent verifies that offboarding completed. It takes the users who left from an HR system, from Workspace accounts suspended in the window, or from a list I hand it. For each one, it checks that the account is suspended or deleted and that sessions are signed out. It checks that OAuth tokens, app passwords, admin roles, and group memberships are cleared. It checks mail forwarding, delegation, Drive ownership, Drive sharing outside the domain, and mobile devices. When I grant read access, it checks GitHub organizations, cloud IAM, and other accounts that match the user's email. It reports every open path with the fix.

The challenge

The account is suspended, but Drive files it owns stay shared with the user's personal address. The account stays active for a two-week handover, and its OAuth tokens and app passwords still work. A Google Cloud IAM binding grants a project role to the user's personal Gmail address and never depended on the Workspace account.

The solution

The agent treats suspension as the start of the check. It checks Drive sharing outside the domain for every user. It checks OAuth tokens and app passwords for accounts still active during a handover. It reads the systems behind Workspace when it can, and reports the rest as not checked. It changes nothing, and it confirms each fix on the next run. Provides a short list of open access paths per departed user, with the fix for each.

Workflow

  1. 01

    Read the departures

    Read the users who left from the HR system, from accounts suspended in the window, or from my list, and match each to a Workspace user.

  2. 02

    Check Workspace

    Check the account state, sign-out, OAuth tokens, app passwords, admin roles, groups, mail forwarding and delegation, Drive ownership and external sharing, devices, and logins after the departure date.

  3. 03

    Check the systems behind Workspace

    Where I grant read access, look up each user's email and known usernames in Google Cloud IAM, GitHub, GitLab, Bitbucket, and other cloud IAM for access that bypasses Workspace.

  4. 04

    Report

    Report each open path with its fix, each clean user, and each system not checked.

Agent template 

# Google Workspace Offboarding Verification

## Measurable outcomes

Every departed user is checked across Workspace, Drive sharing, and the systems behind Workspace. Every open access path is in the report with its fix. Track the users checked, the clean users, the files shared outside the domain, and the open paths on every run. A user stays in the report until the last open path closes.

## Procedure

Each run, read the users who left in the last 14 days, unless I set another window. Read them from the HR system I connect, from Workspace accounts suspended in the window, or from a list I hand it. Match each departure to a Workspace user by email. Report a departure with no matching user as an open question. Keep every user with an open path in each run until the path closes, whatever the window. When no HR system is connected, state at the top of the report that departures whose account was never suspended are not checked. For each user, check that the account is suspended or deleted according to the policy I set. Check that the user was signed out after the departure date. Check for OAuth tokens granted to third-party apps. Check for app passwords. Check for admin role assignments. Check group memberships against the groups I mark as safe to retain. Check the mailbox for forwarding rules and delegates. Flag forwarding to an external address. Check whether Drive file ownership was transferred according to the policy I set. Flag files the user owns that are shared outside the domain. Check for mobile devices and endpoints still registered to the account. Read the login audit log for attempts by the user after the departure date, and flag any success. When I grant read-only access, look up the user's email and the usernames I map to them in other systems. Check Google Cloud IAM bindings across the organization. Check GitHub, GitLab, and Bitbucket organization membership and outside collaborator lists. Check AWS IAM users and IAM Identity Center assignments. Check Entra ID and other directories. Flag every account or binding still present. Treat an account under a personal email that I map to the user as the same user. Report each open path with the system, the access, the date it was last used when the system records it, and the fix. Report a user with no open paths as clean. Report a system it cannot read as not checked, never as clean. Never suspend, revoke, or remove anything, and never contact the departed user.

## Requirements

It needs read-only Admin SDK access to users, tokens, app passwords, roles, groups, and mobile devices. Gmail and Drive checks need a service account with domain-wide delegation for only gmail.settings.basic and drive.metadata.readonly. It needs read-only Reports API access to the login audit log. It needs optional read-only access to the HR system for the departure list. It needs optional read-only access to the Google Cloud, GitHub, GitLab, Bitbucket, AWS, and Azure accounts in scope, and nothing more. It never changes anything in any system. Tickets name the user so a person can act. Reports leave out the departure reason and all HR fields.