non-human identities · discovery & governance

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.

platforms
cybersecurity / discovery-governance 5 platforms
01 · WHERE THEY LIVE 02 · DISCOVERY 03 · GOVERNANCE 04 · OUTCOMES Directories: AD · Entra service principals Directories AD · Entraserviceprincipals Cloud IAM: AWS roles · access keys Cloud IAM AWS roles ·access keys SaaS OAuth grants: Microsoft 365 · Salesforce SaaS OAuthgrants Microsoft 365 ·Salesforce Endpoints and browsers: shadow agents · MCP servers Endpoints andbrowsers shadow agents ·MCP servers NHI inventory: owner · scopes · last used NHI inventory owner · scopes · lastused Sign-in and audit logs: who calls each credential Sign-in and auditlogs who calls eachcredential IGA platform: SailPoint · Saviynt · Entra IGA platform SailPoint · Saviynt ·Entra Owners and sponsors: confirm · transfer Owners and sponsors confirm · transfer Certification campaigns: sponsor as reviewer Certificationcampaigns sponsor as reviewer Disable track: disable · watch · delete Disable track disable · 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.
Ask an engineer facts checked 2026-10-20 · 3 sources
how it runs
  1. 01Connect sources
  2. 02Baseline
  3. 03Clean up
  4. 04Govern
you keep
  • Consolidated NHI inventory with usage and owner
  • Owner-confirmation and disable-track reports
  • OAuth consent review findings
+ 3 more documents
who does it
NHI discovery analystIGA engineerCloud IAM engineer
platforms
the story · nhi discovery & governance

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.

  1. 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.
  2. 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
  3. chapter 03 · how it runs

    Our approach

    • Connect sources
    • Baseline
    • Clean up
    • Govern
  4. 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.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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.

capability 02 / 06in production

Owner assignment

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.

capability 03 / 06in production

Third-party OAuth grant review

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.

capability 04 / 06in production

Shadow agent discovery

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.

capability 05 / 06in production

Certification and sponsorship

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.

capability 06 / 06in production

Safe decommissioning

Unused identities disabled first, watched for failures, and deleted after a grace period, with a written restore path in case something breaks.

typical situations

Situations we walk into

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
  1. 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.

  2. 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.

  3. 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
  1. 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.

  2. 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.

  3. 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.

case studies

NHI Discovery & Governance case studies

All case studies
migration Identity and access

IBM ISIM, Oracle OIM or homegrown provisioning to SailPoint or Saviynt

Getting off IBM ISIM, Oracle OIM or homegrown provisioning scripts and onto SailPoint or Saviynt, with provisioning, certifications and audit history intact.

read the case study
modernization Security operations

Service account, API key and non-human identity cleanup

Tracking down every service account, app registration, API key and AI agent, putting an owner on each and moving them to short-lived, federated credentials.

read the case study
migration Identity and access

On-premises Active Directory to cloud-first Microsoft Entra ID

We shrink on-premises Active Directory one application at a time, moving groups, users and app authentication to Microsoft Entra ID as each app is ready.

read the case study
migration Identity and access

AD FS federation to Entra ID authentication

Converting federated domains from AD FS to Entra ID cloud authentication, moving relying parties app by app and retiring the AD FS farm.

read the case study
upgrade Identity and access

Auth0 Rules and Hooks to Actions before end of life

Rewriting Auth0 Rules and Hooks as Actions before their 18 November 2026 end of life, with token claims compared before and after each change.

read the case study
modernization Privileged access

Centrify and Delinea Server Suite zones to modern server identity

Untangling Centrify and Delinea Server Suite zones, UID maps and dzdo roles, and moving Linux and Windows servers to a server identity model you can run.

read the case study
architecture

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 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. 01 · WHERE THEY LIVE 02 · DISCOVERY 03 · GOVERNANCE 04 · OUTCOMES aggregation API discovery consent grants sensor data last-used dates proposed owner reviewable objects campaigns unclaimed Ex Directories AD · Entra serviceprincipals Cloud IAM AWS roles · access keys Sf SaaS OAuth grants Microsoft 365 ·Salesforce Endpoints and browsers shadow agents · MCPservers NHI inventory owner · scopes · last used Sign-in and audit logs who calls each credential SP IGA platform SailPoint · Saviynt· Entra Owners and sponsors confirm · transfer Certification campaigns sponsor as reviewer Disable track disable · watch · delete
Read the diagram as text
  1. Directories → NHI inventory: aggregation
  2. Cloud IAM → NHI inventory: API discovery
  3. SaaS OAuth grants → NHI inventory: consent grants
  4. Endpoints and browsers → NHI inventory: sensor data
  5. Sign-in and audit logs → NHI inventory: last-used dates
  6. NHI inventory → Owners and sponsors: proposed owner
  7. NHI inventory → IGA platform: reviewable objects
  8. IGA platform → Certification campaigns: campaigns
  9. 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.

  1. step 01

    Connect sources

    We get read-only access to directories, cloud accounts, SaaS admin APIs and agent platforms.

  2. step 02

    Baseline

    We share the inventory with each platform team, showing usage, privilege and where owners are missing.

  3. step 03

    Clean up

    Confirm owners. Disable identities nobody uses, and cut back the ones with too much privilege.

  4. 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

    yours to keep
  • document06

    Monthly NHI governance metrics

    yours to keep
talent and delivery · nhi discovery & governance

Certified engineers, wherever you need them.

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
roles we staff
  • NHI discovery analyst
  • IGA engineer
  • Cloud IAM engineer
  • Service account remediation engineer
  • SaaS security engineer
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.

sources 3 sources linked last checked 2026-10-20 content fingerprint d293f1a1
  1. 01IT Brief: SailPoint Agentic Fabric discovery sensors (4 Aug 2026, secondary source)itbrief.co.uk ↗
  2. 02Okta: Okta for AI Agents and shadow-agent discovery (24 Aug 2026)okta.com ↗
  3. 03Microsoft Learn: Sponsor lifecycle workflows for agent identitieslearn.microsoft.com ↗
Reviewed by the Cohash team Product names are trademarks of their owners. how we handle facts and data →
next step

Tell us what you're running. We'll tell you what we'd do first.

A 30-minute working session with a senior engineer. No slides.

useful to bring
  • The platform and the version you're on
  • Where you need to get to, and by when
  • What's custom: rules, plugins, integrations
  • Any audit finding or deadline driving it