The CTO’s Guide to Non-Human Identities
Non-human identities, explained
What NHIs are, and how Activate Identity Operations fits into governing them.
Pretty much every organisation has two workforces now. One shows up to a Teams call. The other doesn't sleep, doesn't take leave, and never once reads the acceptable use policy. That second workforce - comprising service accounts, app registrations, API keys, and increasingly AI agents, is what the industry has settled on calling non-human identities, or NHIs.
Nobody's loves the name. But it's the one that stuck, so it's the term I’m using.
What is a non-human identity?
A non-human identity is any account or process that acts on your systems without a person typing a password each time it does. In practice, that tends to break down into three categories:
Service accounts — the static accounts your Active Directory, Exchange, or SharePoint connectors use to read and write to target systems.
Application and API identities — Entra ID app registrations, managed identities, and integration credentials that already behave more like scoped, purpose-built identities than a general-purpose service account does.
AI agents — the newest and fastest-growing category. Anything that can initiate or complete a task on your behalf: drafting a ticket, checking a connector, recommending — or making — an access change.
Three different-looking things, one underlying problem: they all need an owner, a defined scope, and a way to prove what they did and why. Most organisations have solved this reasonably well for humans over the last decade. Almost nobody's solved it for the other workforce yet.
Why this is suddenly everyone's problem
Non-human identities aren't new — service accounts have quietly outnumbered people in most environments for years. What's changed is the ratio, and the stakes. Industry research from the Cloud Security Alliance puts the average enterprise at roughly 45 non-human identities for every human one, climbing well past 100:1 in cloud-native environments. A meaningful share of organisations don't even track when a new AI-related identity gets created in the first place.
That's the quiet risk. The loud one is what happens when one of those identities is over-privileged. A handful of non-human identities tend to hold access to a disproportionate share of an organisation's cloud resources — which means the accounts nobody's thinking about are often the ones that matter most.
Add AI agents into that mix, think things that can read email, query a database, or trigger a workflow with no human watching each step, and "we'll get to it next quarter" stops being a viable plan.
The mistake we see most often
It's rarely malicious. It's convenience. One shared AD service account gets reused across half a dozen integrations because setting up a new one is friction nobody has time for. It works, right up until it doesn't — a lockout, a misconfiguration, or a compromise on that one account now has a blast radius across every service it touches.
We’re talking to enterprises and government agencies across Australia and New Zealand that are working through exactly this issue. Their core AD service account is doing double duty across HR, ITSM, and directory integrations — operationally fine for years, but a single point of failure sitting quietly under everything. The fix isn’t going to be a platform rebuild. It’s a shift to one scoped, named identity per integration, each with only the permissions that integration actually needs, audited and reviewable on its own. Same pattern, just applied properly.
That's really the whole playbook for NHI governance: stop sharing credentials, start naming and scoping them individually, and keep production and non-production cleanly separated. Unglamorous, but extremely effective.
Activate's approach: broker, not owner
Activate doesn't decide who — or what — should have access. That's the job of your identity governance platform, your security team, and your policies. Activate's job is making sure that whatever gets decided actually happens, consistently, every time, with a trail behind it.
That principle applies exactly the same way to non-human identities as it does to a new starter's laptop:
What it means in practice
Principle
Least Privilege
Each identity gets only the access its specific function needs, nothing broader "just in case."
One integration, one identity
No more shared service accounts doing five jobs at once.
Environment segregation
Production and non-production stay on separate credentials, app registrations and certificates.
Just-in-time access
Elevated access is requested, approved, time-bound, and removed automatically when it's no longer needed.
Activate already runs this model in production for human joiner-mover-leaver processes and privileged service accounts. Extending it to agents isn't a new product — it's the same broker pattern, pointed at a newer kind of requester.
Extending the model to AI agents
Here's the part worth saying plainly, from Activate's own senior Automation Architect, Roy Robinson:
"The connector is the easy part. The challenge is modelling AI agents as identities with ownership, governance, lifecycle, and privileged access. Activate already has most of the orchestration capabilities needed — the opportunity is extending the identity model to include non-human identities, rather than building a separate 'AI connector' platform."
That's the difference between bolting AI support onto a platform and actually being ready for it. A dedicated "AI connector" solves today's integration. A proper identity model solves the next ten agents you haven't deployed yet. In practice, before any agent gets production access, it should have:
Its own identity — never shared, never borrowed from a person or a generic service account.
Scoped permissions matching exactly the task it performs, no more.
Time-boxed sessions that expire and require re-authorisation, rather than persisting indefinitely.
A human approval gate for anything with material impact — creating an account, changing a permission, removing access.
A full audit trail correlating every agent action back to the request that triggered it.
A kill switch — the ability to cut one agent's access instantly, without touching anything else.
None of that requires reinventing how Activate works. An agent submits a request, it gets checked against approval rules, and only then gets actioned — the same broker model already governing every human request today. The agent is just a new kind of submitter.
Where to start
If you're managing AI adoption, shared service accounts, or both, the starting point is the same: find out what you've already got before you decide what's next.
Inventory every current service account, app registration and connector — and be honest about which ones are shared.
Design and test scoped replacements in a non-production environment first.
Cut over with a defined rollback point, not a leap of faith.
Apply the same model forward to any AI agent work before it reaches production — not after.
Organisations with mature identity operations aren't the ones with the flashiest AI strategy. They're the ones who can adopt AI without quietly expanding their attack surface while nobody's looking.
- Robbie
Want to see how this looks against your own environment? Book a demo or explore Activate Identity Operations.
FAQs
What is a non-human identity (NHI)? A non-human identity is any account or automated process — a service account, an application or API identity, or an AI agent — that accesses systems without a person entering credentials each time.
Is an AI agent a non-human identity? Yes. AI agents are the newest and fastest-growing category of non-human identity, alongside service accounts and application/API identities.
Is Activate an NHI security or discovery platform? No. Activate is an identity orchestration and automation platform. It doesn't decide who or what should have access — that's the role of identity governance platforms and security policy. Activate executes those decisions: approvals, provisioning, fulfilment and lifecycle actions, applied consistently across connected systems including for non-human identities.
How does Activate govern non-human identities? Through the same broker model it uses for human identities: every request is submitted, checked against approval rules, actioned, and audited. For non-human identities, this extends to named and scoped service accounts, time-bound privileged access, and — for AI agents — human approval gates and kill switches for anything with material impact.
Do we need a separate platform for AI agent access? Not necessarily. If your identity orchestration platform already models ownership, scope, approval and audit for human identities, the more effective path is usually extending that same model to agents — rather than standing up a separate AI-specific connector platform.
Follow me Robert Burke and Activate on LinkedIn for more practical insights on governed automation, enterprise AI and identity-driven workflows.
