Should IAM teams classify browser-mediated CLI auth as human identity or NHI governance?

How browser-mediated CLI auth splits human and machine responsibility

Browser-mediated CLI login is a hybrid pattern, not a pure human workflow. The user proves presence through the browser, but the CLI still performs the device-code request, polling, token exchange, storage, and later reuse of the resulting credential material. That is why classification should follow the control surface, not just the person who typed the command.

For governance, the key distinction is between the interactive authentication event and the non-interactive credential lifecycle that follows. IAM teams usually own the human sign-in policy, assurance level, and session constraints, while the CLI side should be treated as a non-human client that can accumulate secrets, scopes, refresh tokens, and exposure paths requiring separate control.

That split matters because the browser step does not eliminate machine risk. If the CLI stores tokens on disk, passes them between processes, or reuses them across contexts, the security question is no longer only “did the user authenticate correctly?” It becomes “what identity material now exists on the endpoint, how long does it live, and who or what can replay it?”

Where IAM policy ends and NHI governance begins

The policy model starts with the user, but the operational governance model must extend to the CLI-held material. In practice, IAM should define the login experience, assurance requirements, and approved approval path, while NHI controls should cover token scope, storage, rotation, revocation, and environmental isolation for the credential artefacts the CLI can use after the browser closes.

This is the same reason teams often separate human account policy from service credential policy. A browser-mediated CLI flow still creates a machine-side trust boundary, because the CLI becomes the actor that handles bearer material on behalf of the user. The right question is not whether the workflow is “human” or “machine” overall, but which parts of the workflow need human identity assurance and which parts need machine identity governance.

That distinction becomes especially important when the CLI can operate unattended after initial approval. A short-lived browser interaction can still leave behind long-lived refresh tokens, cached sessions, or delegated access that behave like non-human identity material in day-to-day operations. For that reason, the machine side should be reviewed like any other privileged automation path, even when the originating intent was human.

How to classify the control and avoid the common mistake

The common mistake is to classify the whole flow based on the browser step alone. That underestimates the security relevance of token handling, because the browser only proves the user once, while the CLI may keep acting later with standing access until the material expires or is revoked. Classification should therefore follow where privilege persists, not where the first approval happened.

Browser-mediated CLI auth should usually be treated as shared responsibility: human identity for enrollment, assurance, and consent, plus NHI governance for the credential material and its lifecycle. If the CLI can refresh tokens, call APIs, or automate follow-on actions without another person present, that machine-side behaviour deserves explicit ownership, inventory, and lifecycle controls.

That also means policy reviews should ask whether the tool is merely authenticating a person, or whether it is becoming an autonomous access holder with reusable authority. When the latter is true, NHI-style controls are not optional decoration; they are the mechanism that keeps delegated access bounded, attributable, and recoverable.

Risk and Threat Considerations

Browser-mediated CLI auth can create false confidence because the interactive browser step looks strongly human-controlled while the durable credential lives elsewhere. The main exposure is token theft, token replay, overbroad scopes, and silent reuse of cached credentials on the endpoint or by another process that can reach the same token store.

Failure mechanism: The user completes the browser challenge, but the CLI receives bearer material that can be persisted, copied, refreshed, or replayed outside the original interactive context. If token scope, expiry, and storage protections are weak, a local compromise or process abuse can turn a legitimate login into durable non-human access.

Impact: Attackers or unauthorized tools may gain persistent API access, lateral movement through connected services, or access that outlives the user’s intent. The resulting incident often looks like normal CLI activity unless the organisation monitors token issuance, reuse, and revocation as first-class identity events.

Practitioner Guidance

What to prioritise: Treat the browser sign-in and the CLI token lifecycle as separate control problems. The former belongs in your human IAM policy, while the latter needs ownership, inventory, revocation, and scope review like any other machine-held credential.

What to verify: Confirm where tokens are stored, whether refresh is enabled, whether multiple processes can reuse the same cache, and whether the tool can continue operating after the user leaves. If the answer is yes, classify the credential path as non-human for governance purposes even when the login started with a person.

Decision rule: If the workflow leaves behind reusable credential material, govern it as NHI; if it ends with a purely ephemeral browser session and no reusable token path, the IAM emphasis can remain human-centred.

Practitioner takeaway: The cleanest operating model is dual ownership, IAM for the person at the point of authentication, and NHI controls for the token that survives the browser session.

Related resources from NHI Mgmt Group

• How should identity teams decide whether to consolidate human IAM, NHI, and agent governance in one platform?
• Why do browser-based attacks matter to IAM and identity governance teams?
• How should security teams evaluate IAM platforms for non-human identity governance?
• Why do browser events matter for NHI and human identity governance?