Non-human identity security is the practice of protecting the accounts, keys and credentials that software uses instead of people. It covers service accounts, API keys, tokens, certificates, workloads and AI agents. The aim is to control what each one can access and to catch misuse quickly.
What is a non-human identity, and how is it different from a human one?
A non-human identity is any identity that is not a person. These identities log in, call services and move data without anyone typing a password. Because they run all day and can't respond to an MFA prompt, they often rely on static secrets that stay valid for months or years.
| Area | Human identities | Non-human identities |
|---|---|---|
| Sign-in method | Passwords and MFA | Keys, tokens and certificates |
| Lifespan | Tied to employment | Often no end date |
| Ownership | A clear manager | Often unclear or missing |
| Activity | Working hours | Constant and automated |
| Typical risk | Phishing and stolen passwords | Leaked keys and excess permissions |
That's why a normal login policy isn't enough. Machine identities need their own controls.
Why NHI security matters
Cloud platforms, CI/CD pipelines, SaaS integrations and AI tools all create new machine identities. Teams add them quickly and rarely remove them, and a single leaked key can open a database, a cloud account or a build pipeline. Attackers like these identities because their activity rarely triggers alerts.
The most common non-human identity risks
OWASP now publishes a separate Top 10 for non-human identities. In practice, most incidents come down to a few patterns:
- Hardcoded secrets. A developer pastes a key into code, and it ends up in a public repository. Automated scanners find exposed keys very quickly.
- Orphaned service accounts. The project ends, the team moves on, and the account stays active with nobody reviewing it.
- Over-permissive access. A bot gets admin rights "to make it work" and keeps them.
- Long-lived secrets. A key that never expires works for an attacker as well as for your app.
- Unscoped API keys. Keys with no limits on scope or environment reach far more than they should.
- AI agents with broad tool access. An agent can read files, call APIs and send data out. Without logs, nobody sees it happen.
In October 2026, CERT-In reported that leaked secrets and over-permissive cloud roles were among the main ways AI agents reached Indian organisations' systems. Our CERT-In AI agent advisory checklist covers the steps.
How to secure service accounts, API keys and AI agents
Give each identity an owner, limit its access, and watch what it does.
Service accounts
- Apply least privilege to every account.
- Assign a named owner.
- Review permissions on a fixed schedule.
- Disable accounts nobody uses.
API keys and secrets
- Store secrets in a secrets manager, never in code.
- Scan repositories, including commit history, for exposed keys.
- Rotate keys regularly and revoke any that leak.
- Limit each key by scope and environment.
AI agent identities
- Give each agent its own identity, never a shared admin account.
- Limit its access to the tools and data its task needs.
- Require human approval for high-impact actions.
- Log everything the agent does.
Start with the identities that hold the most access, fix those, then work down the list. For more on agents, see our guide to AI agent security.
What is NHI management?
NHI management is the ongoing process of finding, owning, controlling and monitoring every machine identity in your organisation. It has five parts:
- Discovery: build a full inventory of service accounts, keys, tokens, certificates and agents.
- Ownership and classification: record who is responsible for each identity and how sensitive its access is.
- Access governance: set and review what each identity may do.
- Credential lifecycle: manage creation, rotation and removal.
- Monitoring: flag unusual behaviour so it can be fixed quickly.
Many teams start with a spreadsheet and move to a dedicated tool as the numbers grow.
Practices that make the biggest difference
- Use short-lived credentials wherever the platform supports them.
- Prefer workload identity federation over static secrets.
- Automate provisioning, rotation and revocation, because manual rotation falls behind as identities multiply.
- Alert on unusual access patterns, such as a key used from a new location or at an odd volume.
How NHI security maps to SOC 2 and ISO 27001
Auditors already expect machine identities to be controlled. If you are preparing for an audit, this is where NHIs show up:
| Framework | Where non-human identities appear |
|---|---|
| SOC 2 | CC6.1 (logical access), CC6.2 and CC6.3 (provisioning, changes and removal of access), CC7.2 (monitoring) |
| ISO 27001:2022 | A.5.16 (identity management), A.5.17 (authentication information), A.5.18 (access rights), A.8.2 (privileged access rights), A.8.15 and A.8.16 (logging and monitoring) |
| DPDP Act | Reasonable security safeguards for systems that process personal data |
A common audit finding is a user access review that covers employees but leaves out service accounts and API keys. Include them, and record an owner for each. See our SOC 2 consulting and ISO 27001 consulting pages for how we help teams prepare.