Most organizations can tell you how many employees they have, to the person.
Ask how many non-human identities they have and the room gets quiet.
Non-human identities (NHIs) are the API tokens, service accounts, OAuth clients, keys and, now, AI agents that authenticate without a person attached. There are a lot of them. Palo Alto Networks' 2026 Identity Security Landscape report (published under Idira, formerly CyberArk), based on a survey of more than 2,900 security decision-makers, puts machine identities, AI agents included, at 109 for every human.
They also stick around. GitGuardian's State of Secrets Sprawl 2026, based on GitGuardian's detection data on leaked secrets, found that 64% of valid secrets from 2022 were still valid in January 2026.
The problem isn't that NHIs exist. It's that nobody owns them and nobody offboards them. People get a termination workflow. A service account gets whatever someone remembers.
The pattern goes like this. A sync job runs quietly for years. The admin who built it leaves on a Friday, IT deactivates the account on schedule, and by Monday nothing has synced since Friday. Nobody knew the job was tied to a person.
This is a general security problem. Every cloud account, CI/CD pipeline and SaaS app has its own version. I'll use Okta as the lens, because it's where I spend my days and because the identity provider is the one place you'd expect NHIs to be under control. (Last month's post on phishing-resistant MFA? None of it helps a token.)
What counts as a non-human identity
Generally: anything that logs in without a human. In an Okta tenant, that looks like this:
- SSWS API tokens, under Security > API > Tokens. The classic.
- OAuth 2.0 service apps (API Services), each with its own
okta.*scopes and, frequently forgotten, an assigned admin role. - OIDC apps that authenticate with client secrets.
- Agent tokens for your AD and LDAP agents.
- Service-account users in Universal Directory. The
svc-accounts that look like people in every report. - OIN API service integrations from vendors you connected years ago.
- AI agents, which you can now register through Agent SSO or Okta for AI Agents.
For a neutral framework, the OWASP Non-Human Identities Top 10 (2025) works. Three entries map almost one-to-one onto Okta: NHI1 Improper Offboarding, NHI7 Long-Lived Secrets and NHI10 Human Use of NHI. Okta's own ISPM maps its detections to the same list.
What actually goes wrong when nobody tracks them
My position: in Okta, an SSWS token isn't really a non-human identity. It's a human admin's permissions copied into a script.
Okta's developer docs say tokens "inherit the privilege level of the admin account that is used to create them… if the admin's privileges are modified, the privilege level of the API token changes to match." The ApiToken schema in Okta's Management OpenAPI spec is blunter: the token is "NOT scoped any further and can be used for any API the user has permissions to call."
So the token's power is whatever its creator's role is today. Promote the admin, and the script gets promoted too.
Then the admin leaves.
The same developer docs: "If a user account is deactivated in Okta, any API token created by that user account is deprovisioned at the same time." The help center agrees: "Tokens issued by deactivated users are rejected." Every time the creating admin is deactivated, their tokens go with them.
That's correct offboarding behavior. It's also how integrations die.
Teams learn this the hard way and do what Okta's help center suggests: "To avoid service interruptions, generate API tokens using a service account that won't be deactivated and that has super admin permissions that won't change."
So you end up with a shared super-admin service account and a stack of tokens that can do anything in the tenant. Meanwhile, Okta's own ISPM ships a detection called "Super Admin with API token." Same vendor, two answers. The help-center advice fixes the outage. It just swaps it for a bigger blast radius.
Expiry won't save you. Tokens are "valid for 30 days from creation or last use," per the developer docs, so a script that calls the API daily keeps its token alive indefinitely. That's NHI7 in one sentence. And once humans start logging in as the shared account to "just fix something," you've got NHI10 as well.
If this sounds theoretical, look at Okta itself. Okta's published root-cause analysis of the October 2023 unauthorized access to its support case management system traced it to a service account whose credentials had been saved in an employee's personal Google profile. Not an SSWS token. Still a service account with a credential living somewhere nobody was watching, at an identity vendor.
The 30-minute NHI inventory you can do today
You don't need a tool for a first number. You need admin access and half an hour.
1. Security > API > Tokens (10 minutes). For each token, note the name, creator, role, last-used date and whether a network zone is set. Okta color-codes recently used, unused, near-expiry and suspicious agent tokens. Flag anything created by a named human, anything whose creator is a super admin, and anything with no network restriction.
2. Your API Services apps (10 minutes). Go to Applications and look at the API Services (service) apps. For each: granted okta.* scopes, assigned admin role, and client secret vs. private_key_jwt. A service app holding SUPER_ADMIN is a finding.
3. The "Public client app admins" setting (2 minutes). According to Okta's service app guide, when it's on, service apps get SUPER_ADMIN automatically once scopes are granted. Okta says to disable it. Check it.
4. System Log (5 minutes). Filter on eventType eq "system.api_token.create" to see who has been minting tokens. To see what one specific token has done, filter on transaction.detail.rootApiTokenId eq "<token id>".
5. Start an owner register (3 minutes, then forever). A spreadsheet is fine: the NHI, what it does, a human owner, a review date. Okta doesn't store owner or purpose for a token.
If you'd rather script it, GET /api/v1/api-tokens (scope okta.apiTokens.read), GET /api/v1/apps/{appId}/grants and GET /oauth2/v1/clients/{clientId}/roles cover most of it. One catch: the token API has no last-used field. The Admin Console does.
Fix the foundation with what you already pay for
None of this needs a new license.
Move automation off SSWS and onto OAuth 2.0 service apps. Okta's own docs "strongly recommend" OAuth over SSWS. A service app uses client credentials with private_key_jwt (the only supported method for Okta-scoped tokens), only the okta.* scopes the job needs, one-hour access tokens and an assigned admin role. Nothing is borrowed from a person, so nothing breaks when a person leaves.
Lock the tokens you can't kill yet to network zones. IP zones only. Requests from outside the range show up as system.api_token.request_outside_allowed_range.
Alert on token creation. system.api_token.create is event-hook eligible, or a Workflow can post to Slack. In a tenant that has moved to OAuth, a new SSWS token should be a surprise.
Turn off "Public client app admins." See above.
Tokens that have to stay go on a dedicated service account with a named owner. And review who holds admin roles, because in Okta that's also a review of what your tokens can do.
Native vs. build vs. buy
Once you know your number, someone has to keep watching it.
Native. Okta's NHI product is Identity Security Posture Management (ISPM), from the Spera acquisition. It inventories service accounts, keys and tokens (Okta API tokens, AWS access keys, GitHub PATs, Snowflake key pairs, SSH keys) and flags NHI issues, including that "Super Admin with API token" detection. Per Okta's pricing page, it's included in the Professional (2 integrations) and Enterprise (50 integrations) suites and is an add-on for Essentials. Core ISPM is GA; the workload identities inventory is still Early Access. It's posture, not vaulting; Okta Privileged Access handles vaulting and service-account password rotation (where a supported connector exists). Check your contract before you buy anything. You may already own this.
Build. A read-only inventory script running on its own OAuth service app (read scopes, Read-Only Admin role). With AI-assisted coding, our estimate (not a benchmark) is two to five working days for someone who knows Okta's API. What it can't see: anything outside Okta, like cloud IAM keys, CI/CD secrets, or secrets pasted into code or Slack. And the script is itself a privileged NHI. When its author leaves, it becomes the next orphan.
Buy. A third-party platform earns its money when most of your NHIs live outside Okta and you need leak detection and behavior-based detection across clouds and pipelines. The market consolidated hard in 2026: Astrix went to Cisco, Entro to SailPoint, Veza to ServiceNow, and CyberArk to Palo Alto Networks (now being rebranded Idira). Whoever you pick, make them connect to Okta through an OAuth API service integration, not an SSWS token.
| Native (ISPM + Okta stack) | Build (scripted inventory) | Buy (third-party) | |
|---|---|---|---|
| Where your NHIs live | Mostly Okta, plus a few connected sources | Mostly Okta | Mostly cloud, CI/CD, code |
| What you own | Professional or Enterprise suite | No ISPM, no budget yet | Budget for a platform |
| Team capacity | Low to moderate | Someone fluent in Okta's API | A team to run another tool |
| Main limit | Posture only; coverage follows your integrations | Okta-only, and it's another NHI | Cost, and another vendor in your tenant |
Then add agents
Agents will inherit whatever NHI hygiene you already have. They'll be handed the same service accounts and the same secrets.
The entry point is cheap. Agent SSO went GA on August 24, 2026, and it's included in core Okta SSO at no extra cost. For agents that support Cross App Access, it registers the agent in Universal Directory and replaces stored credentials with short-lived, identity-governed tokens.
Okta for AI Agents is GA too, as a separate subscription: an agent registry with named human owners, scoped resource connections, certifications and a kill switch. Agent Gateway is not GA. Okta's release notes still listed its APIs as Beta on September 16, 2026. Don't plan a rollout around a date.
Either way: every agent gets registered and gets a named human owner. Ideally one who isn't about to leave.
FAQ
Do Okta API tokens expire?
Yes, 30 days after creation or last use. A token that's used regularly never hits that limit.
What happens to a token when the admin who created it is deactivated?
Okta deprovisions it at the same time. Plan for that by moving the integration to an OAuth service app, not by parking tokens on a super-admin account.
Is ISPM included in my Okta license?
It's included in the Professional and Enterprise suites and is an add-on for Essentials. Check your order form.
Is this only an Okta problem?
No. Okta is just where it's easiest to start counting.
If you run the inventory and the number surprises you, send me a DM on LinkedIn. Follow Blacklock Identity on LinkedIn for the rest of this month's NHI series, or look at our NHI assessment and SSWS-to-OAuth migration work if you'd rather not do it alone.
Or just say hello.