Subscribe to the Non-Human & AI Identity Journal

How should security teams find identities they cannot currently see?

Start with continuous discovery across authentication logs, browser telemetry, DNS, egress, and directory data, then compare discovered identities with approved federation and lifecycle records. The goal is to surface accounts that exist in practice but not in governance. That is the only reliable way to reduce blind spots across human users, NHIs, and AI-adjacent accounts.

Why This Matters for Security Teams

Hidden identities are not just an inventory problem. They are the gap between what security teams believe exists and what is actually authenticating, calling APIs, moving data, or chaining into other systems. That gap is where service accounts, forgotten OAuth apps, machine users, and AI-adjacent accounts accumulate outside governance. Current guidance from the NIST Cybersecurity Framework 2.0 still depends on knowing what must be protected before it can be managed, which is why discovery is a prerequisite, not a one-time project.

NHI Management Group’s research shows how severe the visibility problem already is: only 5.7% of organisations have full visibility into their service accounts, and 80% of identity breaches involved compromised non-human identities such as service accounts and API keys. That same pattern appears in real incidents such as the JetBrains GitHub plugin token exposure, where credentials existed and were abused before they were governed properly.

Security teams miss hidden identities when they rely on directory data alone, because directories only show what was enrolled, not what is active in browsers, SaaS, CI/CD, or east-west traffic. In practice, many security teams encounter identity sprawl only after an exposed token or unexpected login has already produced a breach.

How It Works in Practice

Effective discovery starts by treating identity as an observed behaviour, not a static record. Teams correlate authentication logs, browser telemetry, DNS requests, egress logs, cloud audit trails, and directory exports to identify accounts that are authenticating or invoking services without a matching owner, lifecycle record, or approved federation entry. That approach aligns with NHI Management Group guidance on non-human identity visibility, which emphasises lifecycle control, rotation, and offboarding as part of the same discipline.

A practical workflow usually has four steps:

  • Build a baseline from approved identity sources such as IdP, PAM, cloud IAM, and CMDB records.
  • Continuously ingest telemetry from authentication, browser, DNS, and egress layers to detect identities that are active but undocumented.
  • Cluster findings by account type, ownership, privilege, and workload so service accounts, OAuth apps, bots, and AI tools are separated correctly.
  • Reconcile each discovered identity against federation, lifecycle, and authorization records, then route orphaned or high-risk items to containment and review.

For NHIs and AI-adjacent accounts, discovery should also capture token usage patterns, short-lived credential issuance, and unusual API call chains. That is important because an account may look benign in a directory but still be executing high-risk actions through delegated access. A discovery program that stops at login events will miss identities that only appear through service-to-service calls or automated workflow execution. The Astrix Security & CSA research on the state of non-human identity security shows why this matters: 85% of organisations lack full visibility into third-party vendors connected via OAuth apps.

These controls tend to break down in environments with heavy federation sprawl, unmanaged SaaS procurement, or CI/CD pipelines that mint credentials outside central identity governance.

Common Variations and Edge Cases

Tighter discovery often increases operational overhead, requiring organisations to balance visibility against log volume, privacy constraints, and response time. That tradeoff is real, especially where browser telemetry is limited or cloud estates span multiple tenants. Best practice is evolving, but current guidance suggests prioritising high-risk surfaces first rather than trying to normalise every signal at once.

Some identities will be difficult to classify immediately. Shared service accounts, break-glass accounts, vendor-managed integrations, and AI agents can all appear as “unknown” until context is added from ownership records or workload metadata. Where no universal standard exists yet, teams should use policy-based triage: known and approved, known but stale, or active but ungoverned.

Discovery also needs a containment path. If a hidden identity is found with excessive privilege or no clear owner, the response should not wait for a quarterly review. The operational goal is to shorten the time between first observation and administrative control, as seen in incidents like the Schneider Electric credentials breach, where exposed access became a governance problem as soon as it was exploited. The edge case that most often defeats discovery is a shadow integration created for one project and left running after the original owner has moved on.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
OWASP Non-Human Identity Top 10 NHI-01 Discovery is the first step in finding unmanaged non-human identities.
CSA MAESTRO IAM-01 MAESTRO addresses discovery and governance of machine and agent identities.
NIST CSF 2.0 ID.AM-01 Asset and identity inventory is essential to detect identities not currently visible.

Continuously inventory NHIs from logs and telemetry, then reconcile them to approved ownership and lifecycle records.