Give each service account, API key and AI agent a named owner and a credential that expires.
The account that runs nightly billing. The token in a CI variable. The agent a team set up last month. None of them attend training or leave through HR. We find them, give each one an owner, and replace long-lived secrets with credentials that rotate or expire on their own.
Non-human identities are the accounts and credentials software uses, including service accounts, cloud roles, API keys, certificates, workload identities and AI agents.
Cohash discovers them across directories, clouds, CI/CD and SaaS, assigns owners, moves workloads to federated short-lived credentials, automates secret and certificate rotation, and brings service accounts and agents into the same governance your people already go through.
you probably need this if
Nobody can say who owns the service account that runs nightly billing.
Cloud access keys sit in CI variables and have never been rotated.
Teams are setting up AI agents on their own API keys.
terms on this pageAgent identitydefinitionOne account per agent, separate from staff and service accounts. Policies and logs then point at the agent itself, so nobody has to guess who did what.explained in a field note →RotationdefinitionChanging privileged passwords automatically, on a timer or after each checkout. If one leaks, it soon stops working.explained in a field note →workload identitydefinitionAn identity for software rather than a person. The Entra provisioning service uses one to prove who it is with a short-lived token, so nobody has to store a password for it.explained in a field note →
From the first call to a setup your own team can run.
Here's what usually prompts a call about your Non-Human Identities, what we do about it and in which order, and where you end up.
01 · where it hurts02 · what we change03 · how it runs04 · where you end up
incident board · non-human identities3 open
openNobody can say who owns the service account that runs nightly billing.
recurringCloud access keys sit in CI variables and have never been rotated.
blockedTeams are setting up AI agents on their own API keys.
exposure
Machine and workload identitySecrets and certificate lifecycleAI agent identityDiscovery and governanceOwnership model
startrehearsehandover
Inventory
Triage
Fix the worst first
Stop the regrowth
we are here
ready to hand over
The scripts run as workload identities now, so the MFA enforcement doesn't apply to them.
This one is contained.
NHI inventory with owner, privilege and last-used data
Risk-ranked remediation backlog
chapter 01 · where it hurts
Why teams reach out
Nobody can say who owns the service account that runs nightly billing.
Cloud access keys sit in CI variables and have never been rotated.
Teams are setting up AI agents on their own API keys.
chapter 02 · what we change
How we solve it
Machine and workload identity
Secrets and certificate lifecycle
AI agent identity
Discovery and governance
Ownership model
chapter 03 · how it runs
Our approach
Inventory
Triage
Fix the worst first
Stop the regrowth
chapter 04 · where you end up
What changes
The scripts run as workload identities now, so the MFA enforcement doesn't apply to them.
This one is contained.
NHI inventory with owner, privilege and last-used data
Risk-ranked remediation backlog
what we do
Where we spend the hours
5 areas of work, each one done by an engineer who has run it in production.
CI pipelines, Kubernetes pods and cloud workloads sign in with federated tokens, so there's no stored key to leak. We use OIDC federation, or SPIFFE where workloads span several clouds.
We move secrets into a vault and rotate them. Certificate renewal is automated too, before public TLS lifetimes shrink to the point where renewing by hand is a monthly chore.
Agents registered as identities with sponsors, scoped tokens and a way to switch them off, in Okta, Microsoft Entra Agent ID or your IGA platform.
We build one inventory across Active Directory, cloud IAM, SaaS OAuth grants and code repositories. It records owners and last-used dates, and we put it on a review cycle.
We set one rule: each non-human identity has a person and a team accountable for it. If that person moves on, ownership transfers as part of their exit.
capability 01 / 05in production
Machine and workload identity
CI pipelines, Kubernetes pods and cloud workloads sign in with federated tokens, so there's no stored key to leak. We use OIDC federation, or SPIFFE where workloads span several clouds.
We move secrets into a vault and rotate them. Certificate renewal is automated too, before public TLS lifetimes shrink to the point where renewing by hand is a monthly chore.
We build one inventory across Active Directory, cloud IAM, SaaS OAuth grants and code repositories. It records owners and last-used dates, and we put it on a review cycle.
We set one rule: each non-human identity has a person and a team accountable for it. If that person moves on, ownership transfers as part of their exit.
We pieced these together from Non-Human Identities situations that come up a lot. They're patterns. You won't find a specific client in them.
case file 01
Azure automation running as a user account when mandatory MFA arrives
composite · not a client story
Beforethe situation
Deployment scripts and a nightly clean-up job sign in to Azure PowerShell as a licensed user with a password stored in a scheduled task. Once Microsoft's phase 2 MFA enforcement reached the tenant, every write call from those scripts started to fail.
What we dothe work
Sign-in logs show which user accounts reach Azure Resource Manager without anyone using them interactively. Move each of those scripts to a managed identity or a service principal with a federated credential. Scope the role to the resources the script changes, then remove the user account.
Afterwhere you end up
The scripts run as workload identities now, so the MFA enforcement doesn't apply to them. Each one has a named owner and a narrower role than the user account held.
case file 02
A leaked GitHub token, and no inventory to show what else it reached
composite · not a client story
Beforethe situation
Secret scanning flagged a personal access token in a public fork. It belonged to an engineer who left last year and had admin on a dozen repositories, including one holding cloud deployment credentials.
What we dothe work
Revoke the token and rotate everything it could read, starting with the cloud credentials. Then build the inventory that would have answered this in minutes: tokens, deploy keys, GitHub Apps and CI secrets, each tied to an owner and a last-used date.
Afterwhere you end up
This one is contained. The next time a credential leaks, the inventory shows the owner and the blast radius, instead of a week of searching.
Where non-human identities live and how they get governed
Service accounts, workloads, OAuth apps and agents are each given a credential pattern, such as federated tokens, vaulted secrets or certificates. Those systems report usage and metadata into one inventory. From there, owners and reviews flow into your IGA platform.
how it runs
A typical engagement
We don't start a step until the last one has produced something you can check.
step 01
Inventory
Automated discovery from directories, cloud accounts, vaults, CI systems and SaaS admin APIs.
step 02
Triage
Identities sorted by privilege, exposure and whether anyone owns them.
step 03
Fix the worst first
Exposed secrets rotated, and unused high-privilege identities disabled after a monitored grace period.
step 04
Stop the regrowth
Creation routed through templates and approvals that require an owner and an expiry date.
you keep
What you're left with
We write these for your Non-Human Identities setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
inventory01
NHI inventory with owner, privilege and last-used data
yours to keep
plan02
Risk-ranked remediation backlog
yours to keep
guide03
Ownership and lifecycle standard for non-human identities
yours to keep
guide04
Credential pattern guide per workload type
yours to keep
document05
Governance integration for service accounts and agents
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Onsite
Engineers at your sites in the US
Nearshore
Overlapping hours with US teams
Offshore
Overnight progress on your backlog
All time zones
Coverage handed over across time zones
24-hour coverage · US Central time
OnsiteUS business hours
Nearshoreoverlapping US hours
Offshoreovernight progress
Combinedhandover, not hand-off
00:0006:0012:0018:0000:00
certifications our engineers hold
Vault Associate (003)HashiCorp
Sentry - Secrets ManagerCyberArk
roles we staff
NHI security architect
Secrets management engineer
Workload identity engineer
IGA engineer for service accounts
PAM engineer
due diligence · non-human identities
Questions to ask any partner, including us.
Put these to anyone bidding on your Non-Human Identities work. The ones who've done it answer differently from the ones who've read about it.
Q1
Which sources will your discovery read, and with what permissions?
An NHI inventory is only as complete as its sources. Ask for the list, from AD and Entra to cloud IAM, CI, SaaS admin APIs and vaults, and confirm each connection is read-only.
Q2
How will you decide who owns an identity when its creator has left?
Without an owner, nothing else works. Ask how they'll assign owners from usage data and application ownership, and what happens to the identities nobody claims.
Q3
What will you disable first, and how will you know nothing broke?
Unused high-privilege identities are cheap to remove, but a quarterly job can make one look idle. Disable before delete, with a watch period long enough to catch it.
Q4
How do you stop new long-lived credentials appearing after the clean-up?
Clean up long-lived keys without a guardrail and they'll be back within a quarter. Ask for a preventive policy that blocks or flags new access keys and client secrets, and for a tracked list of exceptions.
Q5
Who reviews service accounts and agents in our access certifications?
Reviews sent to a generic IT queue get rubber-stamped. Each identity needs a named sponsor who knows what it does.
01What counts as a non-human identity?
Anything that authenticates without a person typing a password at that moment. That includes service accounts, Entra service principals and managed identities, and AWS IAM roles and access keys. OAuth apps, API tokens, SSH keys, TLS certificates and AI agents count too.
02Where should we start?
With exposed and unowned credentials. Secrets sitting in source code or CI logs, and high-privilege service accounts nobody claims, carry the most risk and are often the cheapest to fix. Ownership comes next, because every later control needs someone accountable.
03Do we need a dedicated NHI security tool?
Sometimes. Your IdP, cloud providers, vault and IGA platform already hold most of the data. A dedicated tool earns its cost when you run many SaaS platforms and clouds and need correlation across them. We start with what you own and recommend a tool only when the gaps justify one.
04Does this belong to the IAM team or to platform engineering?
Both, which is why it so often falls between them. We usually set it up so platform engineering owns the credential patterns and IAM owns the inventory, ownership and reviews.
05Does Microsoft's mandatory Azure MFA affect our service accounts?
Only the ones that are really user accounts. Microsoft's enforcement for Azure CLI, PowerShell, infrastructure-as-code tools and REST calls applies to user identities making create, update or delete calls. Managed identities and service principals aren't affected. If your scripts run as users, that's a good nudge to move them to workload identities.
related
Often paired with
Projects on Non-Human Identities usually end up touching one of these, so they're worth a look.
