Who owns the service account that can read the HR database?
Ask that about a few hundred service accounts and you'll hear a lot of names from the leavers list. We build a live inventory of non-human identities from your directories, clouds, SaaS tenants and endpoints, find a real owner for each one, and add them to the reviews your auditors already expect.
NHI inventoryowner · scopes · last usedSign-in and audit logswho calls each credential
03 · Governance
IGA platformSailPoint · Saviynt · EntraOwners and sponsorsconfirm · transfer
04 · Outcomes
Certification campaignssponsor as reviewerDisable trackdisable · watch · delete
SailPointSaviyntMicrosoft Entra IDOkta
in short·15-second read
NHI discovery and governance means knowing every non-human identity you have, who owns it, what it can reach and whether it's still needed.
Cohash builds that inventory from Active Directory, Entra ID, cloud IAM, SaaS OAuth grants and agent platforms, then assigns owners, sets lifecycle rules, and adds service accounts and AI agents to certification campaigns in SailPoint, Saviynt or Entra ID Governance.
you probably need this if
The listed owner for most service accounts is someone who left years ago.
Staff have clicked accept on OAuth apps that read their mail and files. Not one of those grants has been reviewed.
You have a feeling that some teams are running agents and MCP servers IAM doesn't know about.
From the first call to a setup your own team can run.
Here's what usually prompts a call about your NHI Discovery & Governance, 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 · nhi discovery & governance3 open
openThe listed owner for most service accounts is someone who left years ago.
recurringStaff have clicked accept on OAuth apps that read their mail and files. Not one of those grants has been reviewed.
blockedYou have a feeling that some teams are running agents and MCP servers IAM doesn't know about.
exposure
Cross-platform inventoryOwner assignmentThird-party OAuth grant reviewShadow agent discoveryCertification and sponsorshipSafe decommissioning
startrehearsehandover
Connect sources
Baseline
Clean up
Govern
we are here
ready to hand over
High-risk grants have an owner or they're gone.
Service accounts now show up in campaigns with a real reviewer.
Consolidated NHI inventory with usage and owner
Owner-confirmation and disable-track reports
chapter 01 · where it hurts
Why teams reach out
The listed owner for most service accounts is someone who left years ago.
Staff have clicked accept on OAuth apps that read their mail and files. Not one of those grants has been reviewed.
You have a feeling that some teams are running agents and MCP servers IAM doesn't know about.
chapter 02 · what we change
How we solve it
Cross-platform inventory
Owner assignment
Third-party OAuth grant review
Shadow agent discovery
Certification and sponsorship
Safe decommissioning
chapter 03 · how it runs
Our approach
Connect sources
Baseline
Clean up
Govern
chapter 04 · where you end up
What changes
High-risk grants have an owner or they're gone.
Service accounts now show up in campaigns with a real reviewer.
Consolidated NHI inventory with usage and owner
Owner-confirmation and disable-track reports
what we do
Where we spend the hours
6 areas of work, each one done by an engineer who has run it in production.
Service accounts, service principals, IAM roles, OAuth apps, API tokens and agents pulled into one list, with last-used dates taken from sign-in and audit logs.
Owners proposed from creation records, group membership and who actually calls the credential, then confirmed by the person named. Anything unclaimed goes onto a disable track.
We rank the apps users and admins have consented to in Microsoft 365, Google Workspace and Salesforce by the scopes they hold. Anything with mail or file read access is reviewed first.
Teams spin up agents and MCP servers without telling IAM. We go looking with discovery features like SailPoint Agentic Fabric's endpoint and browser sensors, or Okta for AI Agents.
Service accounts and agents added to access reviews with their sponsor as reviewer, plus transfer when a sponsor moves on, for example with Entra's sponsor lifecycle workflows for agent identities.
Unused identities disabled first, watched for failures, and deleted after a grace period, with a written restore path in case something breaks.
capability 01 / 06in production
Cross-platform inventory
Service accounts, service principals, IAM roles, OAuth apps, API tokens and agents pulled into one list, with last-used dates taken from sign-in and audit logs.
Owners proposed from creation records, group membership and who actually calls the credential, then confirmed by the person named. Anything unclaimed goes onto a disable track.
We rank the apps users and admins have consented to in Microsoft 365, Google Workspace and Salesforce by the scopes they hold. Anything with mail or file read access is reviewed first.
Teams spin up agents and MCP servers without telling IAM. We go looking with discovery features like SailPoint Agentic Fabric's endpoint and browser sensors, or Okta for AI Agents.
Service accounts and agents added to access reviews with their sponsor as reviewer, plus transfer when a sponsor moves on, for example with Entra's sponsor lifecycle workflows for agent identities.
We pieced these together from NHI Discovery & Governance situations that come up a lot. They're patterns. You won't find a specific client in them.
case file 01
Hundreds of OAuth apps with mail and file scopes in Microsoft 365
composite · not a client story
Beforethe situation
User consent in Entra is open to any app. The enterprise applications list shows hundreds of third-party apps holding delegated mail and file scopes, some with offline access to finance staff mailboxes, and no record of who approved them.
What we dothe work
We export each service principal along with its granted scopes and last sign-in, then rank them by how sensitive the scopes are and how many users they have. Dormant high-risk grants are revoked first. After that, user consent is limited to verified publishers and low-risk permissions, and everything else goes through the admin consent workflow.
Afterwhere you end up
High-risk grants have an owner or they're gone. Any new consent above the threshold goes to a reviewer, and sign-in data keeps the inventory current.
case file 02
Saviynt certifies every employee and none of the service accounts
composite · not a client story
Beforethe situation
Saviynt runs access reviews for all staff, but 1,800 AD service accounts sit outside it because there's no owner attribute to route them by. Internal audit wants a service account review plan before year end.
What we dothe work
We work out a likely owner for each account from logon events, SPNs, group membership and CMDB records, and ask them to confirm or reject it. Confirmed owners go into Saviynt. The first campaign covers privileged service accounts only.
Afterwhere you end up
Service accounts now show up in campaigns with a real reviewer. Unclaimed accounts are on a disable track. Audit gets a plan, and one completed review to back it.
How scattered non-human identities become one governed inventory
Directories, cloud IAM, SaaS tenants and endpoint sensors feed one inventory, enriched with last-used dates from sign-in logs. Claimed identities go to the IGA platform for review by their sponsor, and unclaimed ones go onto a disable track.
How scattered non-human identities become one governed inventoryDirectories, cloud IAM, SaaS tenants and endpoint sensors feed one inventory, enriched with last-used dates from sign-in logs. Claimed identities go to the IGA platform for review by their sponsor, and unclaimed ones go onto a disable track.01 · WHERE THEY LIVE02 · DISCOVERY03 · GOVERNANCE04 · OUTCOMESaggregationAPI discoveryconsent grantssensor datalast-used datesproposed ownerreviewable objectscampaignsunclaimedExDirectoriesAD · Entra serviceprincipalsCloud IAMAWS roles · access keysSfSaaS OAuth grantsMicrosoft 365 ·SalesforceEndpoints and browsersshadow agents · MCPserversNHI inventoryowner · scopes · last usedSign-in and audit logswho calls each credentialSPIGA platformSailPoint · Saviynt· EntraOwners and sponsorsconfirm · transferCertification campaignssponsor as reviewerDisable trackdisable · watch · delete
01 · Where they live
DirectoriesAD · Entra service principals → NHI inventory · aggregation
Endpoints and browsers → NHI inventory: sensor data
Sign-in and audit logs → NHI inventory: last-used dates
NHI inventory → Owners and sponsors: proposed owner
NHI inventory → IGA platform: reviewable objects
IGA platform → Certification campaigns: campaigns
NHI inventory → Disable track: unclaimed
how it runs
A typical engagement
We don't start a step until the last one has produced something you can check.
step 01
Connect sources
We get read-only access to directories, cloud accounts, SaaS admin APIs and agent platforms.
step 02
Baseline
We share the inventory with each platform team, showing usage, privilege and where owners are missing.
step 03
Clean up
Confirm owners. Disable identities nobody uses, and cut back the ones with too much privilege.
step 04
Govern
Creation standards, review schedules and monthly metrics on owned, reviewed and expired identities.
you keep
What you're left with
We write these for your NHI Discovery & Governance setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
inventory01
Consolidated NHI inventory with usage and owner
yours to keep
report02
Owner-confirmation and disable-track reports
yours to keep
report03
OAuth consent review findings
yours to keep
guide04
Lifecycle and naming standard for non-human identities
yours to keep
code05
Certification campaign templates 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
roles we staff
NHI discovery analyst
IGA engineer
Cloud IAM engineer
Service account remediation engineer
SaaS security engineer
due diligence · nhi discovery & governance
Questions to ask any partner, including us.
Put these to anyone bidding on your NHI Discovery & Governance work. The ones who've done it answer differently from the ones who've read about it.
Q1
How will you get last-used dates for identities that never sign in interactively?
Service principals, access keys and API tokens log usage in different places, and some barely log at all. Without usage data every disable decision is a guess.
Q2
What's your threshold for putting an identity on the disable track?
Too aggressive causes outages and too timid changes nothing. The rule should combine owner status, last use and privilege, with exceptions written down.
Q3
How will discovered identities flow into our IGA platform without duplicates?
One service account can turn up in AD, Entra and the CMDB under three different names. Correlation rules decide whether the reviewer sees it once or three times.
Q4
How will you find agents and MCP servers that teams set up without telling IAM?
Shadow agents often run on someone's personal API key or a browser extension. Finding them takes endpoint, SaaS and network signals as well as a directory query.
01Can our IGA platform govern non-human identities?
Increasingly, yes. SailPoint, Saviynt and Entra ID Governance can all hold service accounts or agents as reviewable objects. The gap is usually discovery and usage data rather than the review itself, so we feed the IGA platform from the inventory instead of replacing it.
02How do we find the owner of an account created a decade ago?
Look at what uses it. Sign-in logs show the hosts and applications calling it, and those map to application owners in the CMDB. When nobody claims it, we disable it in a change window and see who calls.
03How often should non-human identities be reviewed?
It depends on privilege. Review high-privilege service accounts and agents with broad data access every quarter. Low-risk, read-only integrations can wait a year. Regulators more and more expect the same rigor you apply to human privileged users.
04Won't disabling accounts cause outages?
A few, if it's done carelessly. Disabling before deleting, picking a monitored window and keeping restore steps written down turns most of those into a short planned call instead of an incident.
05What should we measure once the inventory exists?
The share of identities that are owned, reviewed and on expiring credentials, the count of high-privilege identities unused for 90 days, and the age of the oldest unrotated credential. Those move when the program works and stall when it doesn't, which makes them more useful than a raw count.
related
Often paired with
Projects on NHI Discovery & Governance usually end up touching one of these, so they're worth a look.