Identity programmes have spent a decade getting better at people: single sign-on, MFA, joiner-mover-leaver processes and access reviews. Meanwhile, a far larger population of identities grew up around them with almost none of those controls.
Non-human identities (NHIs) are every credential that lets software, rather than a person, authenticate:
- service accounts in directories and cloud platforms,
- API keys and personal access tokens,
- OAuth applications and their refresh tokens,
- workload identities for containers, functions and virtual machines,
- CI/CD pipeline credentials and deploy keys,
- certificates and SSH keys,
- and, increasingly, AI agents acting on behalf of users and teams.
In most organisations they outnumber employees many times over. OWASP published a dedicated Top 10 for non-human identity risks in 2025, and many of the major breaches of the last few years ran through them: leaked CI secrets, stolen OAuth tokens from third-party integrations, forged tokens after key theft.
Why NHIs are harder than human identities
No natural lifecycle. People join, change roles and leave, and HR systems tell IAM when. A service account created for a migration three years ago has no leaving date.
No MFA. A leaked API key is the whole credential. There is no second factor to stop its use.
Spread everywhere. Secrets live in code, configuration files, CI variables, wikis, chat messages and developer laptops.
Over-privileged by default. It is quicker to grant broad access than to work out the minimum, and nobody reviews it later.
Unclear ownership. When something breaks, nobody knows whether a credential is still used, so nobody dares to remove it.
Third-party sprawl. Every SaaS integration and OAuth consent creates identities that live partly outside your control.
AI agents make all of this worse. They are created quickly, often by business teams, and granted access to exactly the systems (mail, documents, tickets, code) that attackers want.
A programme that works
1. Discover and inventory
You cannot govern what you cannot see. Build an inventory from the systems that issue credentials: cloud IAM, directory services, secrets managers, CI/CD platforms, SaaS admin consoles (OAuth grants) and code repositories (secret scanning). For each identity, record:
| Field | Why it matters |
|---|---|
| Owner (a person or team) | Someone must be able to say "still needed" |
| Purpose | What system uses it, and for what |
| Permissions | What it can actually do, not what was intended |
| Credential type and age | Long-lived secrets are the priority |
| Last used | Unused identities are free to remove |
2. Remove what is not needed
Most first-pass inventories find a large share of credentials unused for 90 days or more. Disable them first, wait, then delete.
3. Replace secrets with federation
The biggest structural improvement is to stop storing long-lived secrets at all. Workload identity federation lets a workload prove who it is using a signed token from its platform, and exchange it for a short-lived credential:
# GitHub Actions deploying to AWS without any stored access key
permissions:
id-token: write
contents: read
steps:
- uses: aws-actions/configure-aws-credentials@v4
with:
role-to-assume: arn:aws:iam::123456789012:role/deploy-payments
aws-region: eu-west-1
- run: aws ecs update-service --cluster prod --service payments --force-new-deploymentThe cloud role's trust policy accepts tokens only from a specific repository and branch, and the resulting credentials expire in minutes. The same pattern works across Kubernetes service accounts, cloud workload identities and SPIFFE-based service meshes.
4. Least privilege, measured
Use access analysers to compare granted permissions with those actually used, and trim the difference. Set permission boundaries so new NHIs cannot be created with more than a defined ceiling.
5. Rotate and expire what remains
Where secrets are unavoidable, keep them in a secrets manager, rotate them automatically and give them an expiry date. A key without an expiry is a future incident.
6. Monitor behaviour
NHIs are predictable, which makes anomalies easy to spot: a CI token used from a laptop, a service account signing in interactively, an OAuth app suddenly reading every mailbox. Feed NHI activity into your SIEM with baselines per identity.
7. Govern AI agents as NHIs from day one
Register agents in the same inventory, give each its own identity rather than a borrowed user session, scope its access to its task, and record whom it acts for. Agent sprawl is NHI sprawl at a faster pace.
Metrics worth tracking
- Percentage of NHIs with a named owner
- Percentage of workloads using federated, short-lived credentials
- Number of long-lived secrets older than 90 days
- Mean time to revoke a leaked secret
- Number of third-party OAuth apps with broad scopes
The takeaway
The identity perimeter is only as strong as its least-governed credential. For most organisations, that credential is not a person's password. It is a forgotten key with admin rights in a config file. Bringing NHIs under the same discipline as human identities is one of the highest-value security programmes you can run this year.
Our information security audit and cloud security audits include a full non-human identity review, from discovery to a remediation roadmap.
