Most of your identities are not people.
Service accounts, API keys, OAuth tokens, pipeline secrets and now AI agents. They authenticate, they hold permissions, they take actions, and every control you rely on for human identity fails on them by construction.
A non-human identity is any credential that authenticates something other than a person: a service account, an API key, an OAuth or refresh token, a certificate, a CI/CD secret, an RPA login, an AI agent. In most environments they outnumber the human accounts.
They need separate treatment because the controls that carry the weight in human identity security do not apply. You cannot enforce MFA on a service account. There is no joiner-mover-leaver process for an API key. Access reviews are organized around people, so an identity with no person attached appears in none of them. Permissions are added when something breaks and are never removed once it works.
What replaces those controls is behavioral: establish what each identity normally does, from where, against what and at what hour, then detect the deviation. Vijilan delivers that as part of the same managed SOC and the same investigation queue as human identity, rather than as a separate console.
Agentic AI is what made this urgent rather than merely known. Every agent that can call an API, sign in to a SaaS application or read a mailbox is a new non-human identity with real reach, created faster than any governance process was built to track.
Six failures, none of them accidental.
Each one follows from the same fact: the identity has no person attached, and almost every identity control assumes one.
You cannot put MFA on a service account
The control that carries most of the weight in human identity security does not apply. A machine credential is a single factor by design, so the compensating control has to be behavioral: what this identity normally does, from where, against what, and at what hour.
There is no leaver process
A person leaves and HR triggers deprovisioning. An integration is decommissioned and its token stays valid indefinitely, because nobody owns it and revoking it risks breaking something in production that nobody wants to be responsible for.
Nobody can name the owner
The engineer who created the key has moved teams or left. The credential still works, still holds the permissions it was granted for a project that ended two years ago, and appears in no access review because access reviews are built around people.
Permissions only ever grow
Scopes get added when something fails and are never removed once it works. The result is an identity with far more authority than its job needs, and no human attached to it who would notice the difference.
Every AI agent is a new one
An agent that can call an API, sign in to a SaaS app, write code or read a mailbox is a non-human identity with real reach, created faster than any governance process was designed to keep up with. This is the part that turned a known problem into an urgent one.
The credential is in more places than you think
Source control, CI pipelines, container images, infrastructure-as-code, a runbook in a wiki, a message thread. Rotation is treated as a project rather than a routine precisely because nobody is confident they know every copy.
Six things, and the last one matters most.
- 01Discovery and inventory
Find the machine identities that exist across cloud, SaaS, identity providers and CI, including the ones that appear in no asset register, and attach an owner to each.
- 02Behavioral baselining
Establish what normal looks like per identity: the calls it makes, the sources it makes them from, the volume and the hours. This is the control that replaces MFA, because it is the one that still works without a person.
- 03Anomaly detection on use
A token used from a new region, a service account touching a data store it has never read, an integration suddenly enumerating a directory. Investigated in the same queue as everything else, not a separate console nobody opens.
- 04Privilege and scope drift
Track what each identity was granted against what it actually uses, so the review conversation starts from evidence rather than from a spreadsheet nobody trusts.
- 05Exposure and secret sprawl
Where credentials have leaked into repositories, images, pipelines and documents, so rotation can be scoped honestly rather than deferred indefinitely.
- 06A revocation runbook that is safe to run
Agreed in advance: which identities can be cut immediately, which need a named human first because production depends on them, and who that person is at 3am.
Detection without an agreed revocation path is a notification. The runbook is written before anything fires, because the alternative is an argument at 3am about who is allowed to break the billing integration. That conversation goes better in daylight.
Including how this differs from PAM.
What is a non-human identity?
Any credential that authenticates something other than a person: service accounts, API keys, OAuth tokens and refresh tokens, certificates, CI/CD secrets, machine-to-machine credentials, robotic process automation logins and, increasingly, AI agents. They authenticate, hold permissions and take actions exactly as a user does, and in most environments they outnumber the human accounts.
Why is non-human identity treated separately from identity security generally?
Because the controls that carry the load for human identity fail here by construction. You cannot enforce MFA on a service account, there is no joiner-mover-leaver process for an API key, and access reviews are organized around people. An identity product built on human assumptions goes quiet on precisely the identities nobody is watching, which is why this needs to be named and handled on its own terms.
How is this different from PAM?
Privileged access management vaults and brokers credentials, which is valuable and is the right place to start for the identities it covers. It does not tell you that a token it never held was used from a new country at 4am, and it has nothing to say about a credential sitting in a container image. Detection and response over machine identity use is the layer on top, and the two are complementary rather than alternatives.
What does agentic AI change about this?
It changes the rate. Every AI agent that can call an API, authenticate to a SaaS application, execute code or read a mailbox is a non-human identity with genuine reach, and agents are created far faster than any governance process was designed for. An organization that had a manageable machine-identity problem eighteen months ago can have an unmanageable one now without any decision having been taken to make it so.
Can you detect a compromised token without breaking the integration?
That is the entire design problem, and it is why the revocation runbook is agreed before anything is detected rather than during an incident. Identities are classified in advance into those that can be cut immediately and those where a named person has to make the call because production depends on them. Detection is worth little if the response to it is an argument at 3am about who is allowed to break the billing integration.
Where does this sit against your other identity coverage?
ThreatRespond™ and our managed ITDR cover human identity: sign-in anomalies, mailbox rules, OAuth grants and account takeover. This is the machine half of the same estate, in the same investigation queue and under the same response mandate, rather than a separate product with a separate console.
Is this available white-label through our practice?
Yes. It is delivered the same way as everything else we run, under your brand, with your name on the reporting and your service desk in front of it. We never compete with our partners for their clients.
This is one of the specialty services we run for partners. See the rest, or read how the same reasoning applies to delegating work to AI agents in the first place. ThreatRespond™ carries the human half.
Start with the inventory
nobody currently has.
Most environments cannot produce a list of their machine identities, let alone an owner for each. That list is the first deliverable, and it is usually the part that changes the conversation.