TLDR: A non-human identity is any account, credential, or workload that acts in your systems without a person behind it: service accounts, API keys, cloud workloads, bots, AI agents, and third-party services authorized to send email as your domain. They outnumber human identities, hold non-reviewed standing privileges, and most organizations don’t even have a complete list of all of them.
Every identity program starts with people. It looks at onboarding, MFA, access reviews, privileges, and offboarding. This isn’t new—organizations have been running this (usually quite well) for years.
However, it’s not just people logging into your systems and using your programs. There are non-human identities (NHI) with access, too. Those don’t go through typical onboarding (maybe some procurement), never get regular reviews, and don’t expire unless you do something about it.
Think about all the services that have permission to act on behalf of your business:
- A random service account created for a migration years ago
- An API key in a forgotten config file
- Dozens of SaaS platforms
Not one of those has a badge, manager, or last day.
These services outnumber your employees, and they’re becoming the go-to vectors for opportunistic attackers.
What is a non-human identity?
A non-human identity (NHI) is a digital service that authenticates and acts in your environment without an accountable person. If something can authenticate to a system, hold a permission, or take an action on your organization’s behalf, it’s a non-human identity—whether it lives in your IAM platform or not.
Plenty of NHIs never touch identity infrastructure at all. They come in all types and permissions, living everywhere from your directory and IAM to your code and config files.
Here are a few of the most common types of non-human identities in your organization:
| Type | What it is | Where it lives |
| Service accounts | Accounts that run applications and scheduled jobs | Directory, cloud IAM |
| API keys and tokens | Credentials letting systems call each other | Code, config files, secret stores |
| Cloud workloads | Containers, functions, and VMs with assigned roles | Cloud provider IAM |
| Bots and RPA | Automation that performs tasks a person used to | RPA platform, directory |
| OAuth app grants | Third-party apps a user authorized against a mailbox or drive | SaaS platform, often nowhere else |
| AI agents | Systems that take autonomous action across tools and data | Increasingly, no central registry |
| Sending identities | Services authorized to send email as your domain | DNS |
Non-human identities are harder to lock down than people
Human identity security has a few assumptions we can trust. Those often breakdown for machines:
- No MFA. You can’t push a notification to a container. Machine authentication relies on secrets, certificates, or tokens—that means the credential is the identity. Anyone holding it becomes that identity.
- No offboarding. People leave and HR triggers deprovisioning. Do you have the same procedures for a service account created for a project that ended two years ago? Probably not. It’s still there, technically valid, with whatever permissions it was granted.
- No owner. Ask who owns a given API key. You’ll likely find it belongs to a reorganized team or a beloved engineer who’s since left the company. And you can bet that unowned credentials never get rotated, reviewed, or revoked.
- Over-permissions. Machine credentials get provisioned broadly to avoid breaking things, then never scoped back down once tested and deployed.
- Long-lived by default. Human passwords expire. API keys and service account credentials often don’t. Some have been valid since the day they were issued.
- Invisible to traditional tools. Identity governance platforms were designed around joiners, movers, and leavers. Machines don’t do any of those things, so they fall outside the review cycle entirely.
Ultimately, NHIs have far more identities, broader permissions, weaker authentication, and less oversight than your human personnel.
Attackers noticed this, too.
Sender identities: The category that’s almost always forgotten
When your marketing team connects a new email platform, they authorize it to send messages as your domain. That’s a standing permission granted to a third party, exercised without human review on every send, and it lives in a DNS record.
Nope, not your identity program—it’s in a DNS record.
Based on our definition above, that’s a non-human identity. It authenticates, acts on your behalf, and holds a privilege you granted.
And if that’s the case, it’s time to count how many your organization has:
- Marketing automation
- CRM
- Support desk
- Billing system
- HR platform
- E-signature
- Survey tool
- Calendar scheduler
- Recruiting system
- Transactional email service
The real list is almost always longer than IT’s. That’s because anyone with a corporate card can add one.
NHI programs audit API keys and service accounts thoroughly, but then never ask which external services can send email as the company. Those senders don’t appear in your cloud IAM or a secret scan—nothing in your standard identity review finds them.
However, they do show up consistently in one place: DMARC reports.
If your NHI inventory doesn’t include your sending identities, it has some major holes to fill. Start there, since it’s one of the few categories you can inventory and remediate in an afternoon.
And it’s also one of the most exploited.
Four questions to make your NHI program work
Identity, authentication, policy, reporting. These four questions apply to every service, API, or integration.
- Who is it? Can you name the identity and the system or organization behind it? An IP address doesn’t cut it. Who’s the actual sender? What’s their name?.
- Can you prove it? Is there a credential (certificate, token, cryptographic key) that ties this identity to something you control? For email senders, that’s SPF and DKIM aligned under DMARC.
- What’s it allowed to do? Scoped permissions, defined before access is granted. Most NHIs have far more privileges than their job requires.
- How do you know it’s working? Reporting that shows what was authorized, what was blocked, and what tried. No metrics or measurements means you don’t know if it’s working—and if you don’t know it’s working, it’s best to assume it’s not.
This is the same structure that made DMARC deployable, and it’s the structure emerging for AI agent identity as that category matures.
How to get your non-human identities under control
Here’s the step-by-step process to get your non-human identity program kickstarted:
- Inventory what exists. Service accounts, API keys, OAuth grants, workload roles, and sending identities. The real number will likely exceed the documented one.
- Assign an owner to each. Every identity gets a named human accountable for it.
- Scope permissions down. Grant what the identity needs today. That’s it.
- Rotate credentials on a schedule. Keys and certificates need lifecycle management the same way passwords do.
- Monitor for drift. New OAuth grants, sending services, and workload roles. Environments change constantly, and the additions rarely come through a review process.
- Build an off-ramp. Most NHI sprawl is accumulated credentials nobody retired.
The first step is almost always the hardest, but it’s also the most important. Because you can’t protect what you don’t know exists, and any half-attempted inventory will leave security gaps. And now those security gaps will be hidden behind false pretense.
Start with the identities you can see today
Every service sending email as your domain appears in your DMARC reports, and that’s whether or not anyone told IT about it.
Valimail Monitor is free and identifies each one by name rather than IP address, which turns a pile of XML into real, serviceable inventory. Check your domain to see where your authentication stands right now.
Frequently asked questions
What is a non-human identity?
A non-human identity is any digital identity that authenticates and acts without a person driving it, including service accounts, API keys and tokens, cloud workloads, bots, OAuth application grants, AI agents, and third-party services authorized to send email as your domain. Machine identity refers to the same concept and the terms are often used interchangeably.
What are some examples of non-human identities?
Common examples include a service account running a nightly database job, an API key letting your CRM talk to your billing system, a Kubernetes workload with an assigned cloud role, an RPA bot processing invoices, an OAuth grant giving a third-party app access to a mailbox, and a marketing platform authorized to send email using your domain.
Why is non-human identity security difficult?
Machines can’t use MFA, so the credential itself becomes the identity. They have no offboarding event, so credentials outlive their purpose. They’re frequently over-permissioned and long-lived, they often lack a named owner, and identity governance tools built around human joiner-mover-leaver cycles don’t track them well.
