By NHI Mgmt Group Editorial TeamPublished 2025-08-12Domain: Best PracticesSource: Clutch Security

TL;DR: User activity is creating persistent machine identities through OAuth apps, browser-stored credentials, SaaS tokens, and shadow IT, and Clutch Security says many enterprises underestimate the resulting attack surface. The governance problem is not just visibility, but controlling user-generated NHI sprawl without breaking productivity.


At a glance

What this is: This analysis argues that everyday user productivity is generating a hidden population of non-human identities that expands enterprise attack surface and persistence risk.

Why it matters: IAM teams have to govern user-created machine identities with the same discipline they apply to service accounts, because delegated access, token persistence, and shadow IT all widen blast radius.

👉 Read Clutch Security's analysis of the user domain and hidden NHI risk


Context

The user domain is the part of the enterprise where people install apps, approve OAuth access, save credentials, and work across SaaS tools. That daily convenience creates non-human identities that often outlive the business need that created them, which is why user productivity has become an identity governance problem, not just an endpoint problem.

The core weakness is that these identities are created inside normal work patterns, outside the review and lifecycle controls that IAM teams rely on for managed accounts. In practical terms, the issue is not whether users need flexibility. The issue is whether the organisation can see, approve, and retire the machine identities that user behaviour creates.


Key questions

Q: How should security teams govern user-created OAuth applications?

A: Start by classifying OAuth applications as delegated identities rather than lightweight conveniences. Then require approval for broad scopes, map each grant to an owner, and revoke access when the business use ends. The key control is not just consent. It is lifecycle governance for persistent delegated access, including review, ownership, and removal.

Q: Why do user-generated NHIs increase enterprise risk?

A: They extend access beyond the user’s immediate session and often keep working after the original business need has ended. That persistence increases the chance of data access, lateral movement, and compliance exposure. The risk rises when organisations cannot see where those tokens live or who is responsible for revoking them.

Q: What breaks when browser-stored credentials are not controlled?

A: Browsers become an unmanaged credential vault, which means tokens and API keys can be stolen from many endpoints instead of from one central store. Once extracted, those secrets can be reused without raising human authentication alerts. The failure is governance blind spot, not just endpoint compromise.

Q: What should organisations do when a user leaves but their app integrations remain active?

A: Revoke the integrations as part of offboarding, not as a separate cleanup task that happens later. User exit should trigger review of every OAuth grant, token, and personal automation the person created. If those machine identities stay alive, accountability has already broken.


Technical breakdown

OAuth consent creates persistent delegated access

OAuth consent gives a third-party application a token that can keep working after the user forgets about it. The user authenticates once, then the application can continue acting within the granted scope until the token is revoked or expires. That persistence makes consent risk different from password theft. It is authenticated access with a legitimate trail, which is harder to spot than direct compromise. In the user domain, broad consent scopes and weak app approval discipline create long-lived access paths that can span email, file storage, and collaboration systems.

Practical implication: Track and restrict broad consent scopes before they become standing delegated access.

Browser-stored credentials turn endpoints into distributed vaults

Modern browsers store session tokens, API keys, and saved credentials across large numbers of user devices. That creates a distributed credential store with little central governance. Malware or local compromise can extract these secrets and reuse them outside the browser context, which bypasses controls aimed only at managed enterprise stores. The security challenge is structural: a secret saved for convenience in one user session can become a reusable identity artifact across many services and many endpoints.

Practical implication: Treat browser-stored secrets as governed credentials, not as harmless convenience features.

Shadow IT creates machine identities outside IT lifecycle control

When users install unsanctioned tools or personal automations, those tools often generate their own tokens, API keys, and service integrations. Those identities are usually created without lifecycle registration, approval workflow, or recertification. The result is not just sprawl. It is governance blind spot, because the organisation cannot confidently answer who owns the identity, what it can reach, or when it should be removed. In the user domain, unmanaged applications become unmanaged identity issuers.

Practical implication: Inventory user-driven applications as identity sources, then bring them into approval and offboarding workflows.


Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

User-generated machine identities are a governance class, not an edge case. The user domain is not merely where people consume SaaS. It is where authorised users continually create delegated credentials, tokens, and application access that behave like standalone non-human identities. That means IAM programmes that only track human accounts are missing a large part of the effective identity estate. The practitioner conclusion is simple: the user domain must be governed as an NHI-producing environment, not just an access surface.

Token persistence is the failure mode that most directly changes the attack model. Once a user authorises an app, that app can keep acting long after the original user action is over. That creates a gap between business intent and access duration, and it is why access review cadences often miss the real risk. The practitioner conclusion is to treat persistent delegated access as its own lifecycle object, not as a one-time permission event.

Identity blast radius is often smaller per identity, but much larger in aggregate. Clutch Security is pointing to a pattern where each user-generated identity may look limited, yet the combined estate spans email, storage, collaboration, and automation tools. That aggregation matters because compromise of one user-created token can become a multi-system foothold without privileged-account techniques. The practitioner conclusion is to measure cumulative delegated reach, not just individual permission sets.

Visibility without friction is the named concept this domain needs. The user domain fails when organisations either cannot see user-created NHIs or try to suppress them so heavily that people route around controls. The field problem is not just discovery. It is maintaining enough governance to reduce risk while preserving the productivity behaviours that create these identities in the first place. The practitioner conclusion is to design controls around high-risk scopes and high-value data, not around every routine collaboration app.

The user domain exposes a lifecycle gap between human ownership and machine persistence. Human users change roles, leave teams, or stop using an app, but the delegated credentials they created can remain active. That means the accountability chain breaks at offboarding and recertification, where the identity subject and the machine identity do not move in lockstep. The practitioner conclusion is to align access review with the lifecycle of the delegated credential, not just the user account.

From our research:

  • 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
  • Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, which shows how far governance still trails identity sprawl.
  • For a broader breach lens, 52 NHI Breaches Analysis shows how unmanaged access patterns become repeatable attack paths.

What this signals

The user domain is becoming a machine-identity factory, and that changes the security model for every identity team that assumed access creation was centrally controlled. Visibility without friction: the organisations that manage this well will be the ones that can discover delegated access quickly, constrain the risky scopes, and still preserve the productivity users expect.

The practical signal is that lifecycle governance now has to reach beyond the user record. When an employee installs an app, authorises an integration, or stores a token in a browser, the resulting identity object needs ownership, review, and offboarding just like any other governed access path. For teams building that operating model, the Ultimate Guide to NHIs is a useful reference point.


For practitioners

  • Inventory user-generated NHIs at scale Scan endpoints, SaaS logs, and connected app registries for OAuth grants, browser-stored secrets, and shadow IT integrations. Build a single inventory that maps each credential to an owner, scope, and last-used signal.
  • Tighten consent on high-risk scopes Require approval for applications that request mail, file, or directory access, and separate low-risk productivity apps from broad delegated access. Focus policy on the permissions that can reach regulated or business-critical data.
  • Treat browser secrets as governed credentials Block storage of sensitive API keys and tokens in unmanaged browsers where possible, and monitor for credential extraction signals on user endpoints. Include browser-stored secrets in the same response process as other exposed credentials.
  • Attach offboarding to delegated access revocation When a user changes role or exits, revoke the OAuth applications and personal tokens they created, not just their human account access. Tie revocation to recertification so lingering tokens do not outlive the business need.
  • Separate productivity from privileged delegation Allow routine collaboration tools to operate with narrow scopes, but move any app that touches sensitive data into a higher-friction approval path. That keeps the governance focus on the access paths that can actually extend blast radius.

Key takeaways

  • The user domain is producing hidden non-human identities every day, and that expands the real attack surface beyond managed human accounts.
  • Persistent OAuth grants, browser-stored secrets, and shadow IT create access paths that often survive the business need that created them.
  • The control gap is lifecycle governance for delegated access, which means discovery, approval, review, and revocation must extend into user productivity tooling.

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 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-03Persistent OAuth grants and token sprawl map directly to NHI credential lifecycle risk.
NIST CSF 2.0PR.AC-4User-created NHIs need access governance and least-privilege enforcement.
NIST Zero Trust (SP 800-207)AC-4The user domain is a distributed access environment that needs continuous verification.

Review delegated credentials on a fixed lifecycle and revoke grants when the business need ends.


Key terms

  • User-Generated NHI: A user-generated NHI is a non-human identity created through normal employee activity, such as approving OAuth access, saving a token, or installing an application. It is often born outside central IAM workflows, which makes ownership, scope, and retirement harder to govern.
  • Delegated Access: Delegated access is permission granted to an application or service to act on a user’s behalf. In identity governance, it matters because the access can persist after the user stops needing it, turning a convenience feature into a standing identity path that requires lifecycle control.
  • Token Persistence: Token persistence is the condition where an authentication token, API key, or OAuth grant remains usable long after the initiating action is complete. It is a governance problem because the access may still be active even when the user, team, or business purpose has changed.
  • Identity Blast Radius: Identity blast radius is the amount of systems, data, or services that can be reached if one identity is abused. For user-generated NHIs, the blast radius may be limited per token but large in aggregate because many small delegated access paths can exist at once.

Deepen your knowledge

User-generated NHIs and delegated access are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your programme starts with user productivity and ends with identity sprawl, it is worth exploring.

This post draws on content published by Clutch Security: The user domain where human productivity meets machine identity risk. Read the original.

NHIMG Editorial Note
Published by the NHIMG editorial team on 2025-08-12.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org