OrphanKeys

Runs at every employee departure and lists each API key, service account and OAuth app that person created or last touched, so the leaver ticket can't close while any of them still has no owner.

Problem

HR termination triggers account disablement for the person, but nothing equivalent fires for the tokens, service accounts and OAuth apps that person created. Once the account is disabled, the link between the person and what they left running is usually gone, so an integration built in 2024 keeps working with no owner and no one who will notice if it misbehaves. OWASP's Non-Human Identities Top 10 ranks improper offboarding first (NHI1).

Target user

An IAM engineer or IT admin at a 100-1,000 person company that already runs an IdP and a leaver checklist. They own the offboarding runbook and can see the human side clearly. They cannot answer "what did this person create?" without opening six consoles, so the question gets skipped.

MVP scope

• Read-only CLI that takes a leaver's IdP user ID (Entra ID or Okta) and queries creator or last-modifier metadata in GitHub (PATs, deploy keys, apps), Google Workspace (OAuth grants, service accounts) and AWS IAM (access keys, roles by tag).
• Outputs a "left-behind" list: each credential with creator, created date, last-used date, and scope summary.
• Flags credentials as owner-orphaned when the recorded owner is disabled or deleted in the IdP.
• Supports a reassign file: a mapping of credential ID to new owner, which the tool validates against active IdP users.
• Exit code is non-zero while any listed credential has no active owner, so the leaver ticket can gate on it.
• Ships a weekly sweep mode that finds orphans from past departures, using a 90-day lookback.

Monetization

Freemium. The CLI is free for one IdP and two providers. A paid tier at roughly $99 per month adds more providers, scheduled sweeps, and signed owner-attestation exports for auditors.

Why now

Vendor write-ups in 2026 describe the gap as a missing trigger: people have an HR event, machine identities have none (NHI Mgmt Group glossary and FAQ). The Gainsight/Salesforce OAuth incident, in which Salesforce revoked tokens on 2025-11-19, is the standard example of a long-lived token nobody was positioned to question. I found these through search snippets and could not fetch the NHI Mgmt Group article, so the specifics are second-hand. Vendor-reported statistics, such as 51% of organizations lacking a process to revoke long-lived keys, are unverified and I'm not relying on them.

Risks & open questions

• Creator metadata is uneven. AWS access keys carry no creator field and GitHub PATs are not enumerable by org admins in every plan, so coverage may be a patchwork of "unknown owner."
• Demand: IGA and NHI vendors already pitch lifecycle features, and a buyer at this size may expect their IdP to cover it. Will anyone pay for a CLI?
• Build: three provider adapters plus two IdPs is a lot of API surface for one person. A GitHub-plus-Okta slice may be the realistic start.
• Last-used timestamps are often missing or coarse, which makes "stale" calls less reliable than "no owner" calls.

Next step

Interview five IAM admins about their leaver checklist, then build the GitHub plus Okta slice as a one-day prototype.

Sources

• https://nhimg.org/faq/why-do-orphaned-service-accounts-and-tokens-create-so-much-risk-after-offboardin/ — orphaned service account risk and the missing offboarding trigger for machine identities
• https://aembit.io/blog/owasps-top-security-risks-for-non-human-identities-and-how-to-address-them/ — OWASP NHI Top 10 overview, including improper offboarding
• https://www.oasis.security/blog/gainsight-salesforce-oauth-incident — Gainsight/Salesforce OAuth token incident write-up
• https://nhimg.org/articles/gainsight-salesforce-oauth-incident-exposes-refresh-token-trust-gaps/ — refresh token trust gaps discussion (not fetched; cited from search results)