What is non-human identity governance, and why does it matter now?
Non-human identity (NHI) governance is the practice of discovering, scoping, rotating, and retiring every machine credential (service accounts, API keys, OAuth tokens, certificates, and workload identities) with the same rigor you apply to human accounts. It matters now because NHIs vastly outnumber employees and are rarely offboarded.
In most environments, public reporting commonly cites tens of non-human identities for every human one, and the ratio keeps climbing as teams adopt microservices, SaaS integrations, and AI agents. Each carries a credential, and most:
- ▸Never expire, a static API key or OAuth refresh token lives until someone remembers it.
- ▸Are over-scoped, granted broad roles to unblock a deploy, then never trimmed.
- ▸Have no owner, the engineer who created it left 18 months ago.
The OWASP Non-Human Identities Top 10 (2025) codified these failure modes, and NHI is now a distinct control domain, not a footnote under IAM.
What did the Salesloft Drift OAuth breach reveal about NHI risk?
The 2025 Salesloft Drift campaign showed that a single compromised third-party OAuth token can unlock hundreds of downstream tenants. Per public reporting from Google's Threat Intelligence Group (tracking the activity as UNC6395), attackers abused stolen OAuth tokens tied to the Drift integration to pull data from connected Salesforce instances at scale.
Key lessons for NHI governance:
- ▸The integration was the identity. Drift's OAuth token was a non-human identity with standing, broadly scoped access to customer data, no password, no MFA prompt, no user in the loop.
- ▸Attackers hunted secrets inside the loot. Public reporting indicates they searched exfiltrated data for embedded credentials (AWS keys starting AKIA, Snowflake tokens, passwords), one NHI leading to the next.
- ▸Revocation was the fix. Salesforce and Salesloft revoked the affected tokens; there was no password to reset because there was no password.
Third-party SaaS integrations are NHIs you do not fully control. You still have to inventory them, scope them, and be ready to revoke.
How do you discover every service account and token you actually have?
Start with authoritative sources, not spreadsheets. Enumerate identities directly from each identity provider and cloud control plane, then correlate. You cannot govern what you cannot see, and shadow credentials are the norm, not the exception.
A practical discovery sweep:
- ▸Cloud IAM: pull all AWS IAM users, roles, and access keys; GCP service accounts and keys; Azure service principals and managed identities. Use AWS IAM Access Analyzer (unused access) and equivalents to flag dormant credentials.
- ▸SaaS OAuth grants: review connected apps in Google Workspace, Microsoft Entra ID, Salesforce, GitHub, and Slack. List every third-party integration and its scopes.
- ▸Secrets sprawl: scan repos and CI with secret scanners (GitGuardian, TruffleHog, GitHub secret scanning) for hardcoded keys and tokens.
- ▸Certificates and CI tokens: inventory X.509 certificates, Kubernetes service-account tokens, and pipeline credentials.
Assign an owner and a purpose to each finding. Anything with neither is a candidate for immediate disablement.
How do you right-size an over-privileged service account?
Right-size from evidence, not intent. Measure what the account has actually used over a representative window (typically 30-90 days), then rewrite its policy to grant only that and deny the rest. Guessing at what it probably needs is how over-provisioning happens in the first place.
The workflow:
- ▸Baseline real usage. Use access logs and tooling like AWS IAM Access Analyzer policy generation, CloudTrail, or a CIEM platform to see which actions and resources the identity touched.
- ▸Draft a least-privilege policy scoped to those actions, specific resource ARNs, and conditions (source IP, VPC, time).
- ▸Test in staging, then deploy with alerting on access-denied events so you catch anything you trimmed too aggressively.
- ▸Remove wildcard grants (Action star, Resource star) and detach unused managed policies.
For a deeper treatment of scoping tokens and containing damage, see Least Privilege for AI Agents: Scoping Tools, Tokens, and Blast Radius, AI agents are just NHIs with a language model attached.
How often should machine credentials be rotated, and how?
Rotate short-lived credentials automatically and continuously; rotate any remaining static secret on a fixed schedule (typically 30-90 days) and immediately on any suspicion. The real goal is not frequent rotation, it is eliminating long-lived secrets so rotation becomes a non-event.
- ▸Prefer ephemeral over static. Short-lived tokens (minutes to hours) shrink the window a stolen credential is useful.
- ▸Automate with a broker. Use a secrets manager (HashiCorp Vault, AWS Secrets Manager) with dynamic secrets and automatic rotation instead of manual key swaps.
- ▸Make revocation instant. You should be able to kill a single NHI's access in seconds without a deploy, the Drift response worked because tokens were revocable.
- ▸Rotate on personnel change. When an owner leaves, rotate or retire everything they created.
Static keys that cannot be rotated without downtime are the ones attackers count on. This is why the industry is moving to workload identity, covered next and in The End of the Long-Lived API Key: Workload Identity and Secretless Architecture in 2026.
What is workload identity, and how does it kill long-lived secrets?
Workload identity gives a running service a short-lived, cryptographically verifiable identity issued at runtime, no static API key to steal. The workload proves what it is (via a platform attestation or signed token), receives a credential that expires in minutes, and renews automatically.
The building blocks:
- ▸SPIFFE/SPIRE issues X.509 or JWT SVIDs to workloads and enables mTLS between services with automatic rotation.
- ▸Cloud-native federation: AWS IAM Roles Anywhere and STS, GCP Workload Identity Federation, and Azure Workload Identity let workloads assume roles without stored keys.
- ▸OIDC for CI/CD: GitHub Actions and GitLab can mint short-lived cloud credentials via OIDC federation, retiring the long-lived deploy key.
- ▸mTLS everywhere: service-to-service auth via certificates instead of shared secrets.
The payoff: there is no durable secret sitting in an env var, a wiki, or an exfiltrated database for an attacker to reuse. Adoption fits naturally into an identity-first model, see Zero-Trust Architecture in 2026: Identity-First Security and a Pragmatic Rollout for Growing Companies.
How do you keep NHI governance from rotting after the first cleanup?
Make NHI governance continuous and paved into your platform, or it decays within a quarter. Every new credential should be born scoped, owned, expiring, and observable, enforced by golden paths and policy-as-code, not by review meetings.
- ▸Provision through a golden path that mints least-privilege, short-lived identities by default. See Golden Paths as a Security Control: Internal Developer Platforms Done Right.
- ▸Require ownership metadata on creation; block orphan identities in CI with policy-as-code (OPA/Conftest).
- ▸Alert on drift: new wildcard grants, dormant-then-active keys, or scope escalations.
- ▸Recertify quarterly: re-attest that each NHI still needs its access, and auto-disable the unused.
Treat every service account as something that must justify its existence on a schedule.
How TuniCyberLabs helps
We inventory your non-human identities across cloud, SaaS, and CI, cut over-privileged accounts to least privilege from real usage data, and migrate you toward workload identity so long-lived secrets stop being a liability. Talk to our security engineers to scope an NHI discovery and hardening engagement.