Two product categories nobody owns: the developer laptop as identity broker, the browser as evidence

A glossary entry and an FAQ, both published by the NHI Management Group, now describe two security surfaces precisely enough to write a specification against: the developer workstation treated as an identity broker rather than as a user device ^[7][10], and the browser treated as an evidence source for access governance rather than as a delivery channel for applications ^[24]. What makes that worth an operator's attention is the demand signal filed alongside them, in which ActiveState says it surveyed 300 security and engineering leaders across technology, financial services, healthcare, manufacturing and government to test whether governance models hold up as AI coding tools push unvetted open source into production ^[2][1].

The definition is the development, not the threat

Nothing in this material reports an incident. What it reports is scoping, and scoping is the step that turns a diffuse anxiety into something a team can buy or build. The endpoint definition is deliberately narrower than endpoint security: a device becomes an identity surface when it can authenticate, store reusable credentials, or relay trust into other systems, and the focus is identity-bearing paths rather than malware defence ^[7][9]. The enumerated paths are specific: local shells, package managers, browser profiles, AI assistants, SSH agents and token caches ^[8]. In this framing the workstation belongs to the control plane whenever it can issue, reuse or leak API keys, certificates, session tokens or cloud credentials, and should be treated as a high-value identity broker ^[10].

That is a detection problem with edges. It is also a problem that existing tooling categories are structurally poor at, by the definition's own logic: an agent looking for malicious code on a laptop is not looking for a token file that a CLI reads in order to publish code, query infrastructure or rotate secrets with no human in the loop [c12a]. The failure mode the source names is exactly the boundary error a product would exist to correct: treating the laptop as a trusted user endpoint only, and ignoring cached tokens, local secret stores and AI tool integrations ^[11].

Day five is the number with an owner

The one hard figure in the endpoint material is a revocation figure. The NHI Management Group reports that 91.6 percent of secrets remain valid five days after notification, which it uses to argue that endpoint exposure routinely outlives the detection event ^[13]. Read the complement and the implication for product design gets sharper: by that group's own number, fewer than one secret in eleven is dead within five days of someone being told about it ^[14].

This is single-sourced and comes from an organisation that also sells guidance in the space, so treat it as a claim rather than a measurement. But if it is even directionally right, it settles an architecture question. A product that only finds credentials on developer machines inherits the same five-day tail as everything else; the value has to sit in the revocation path, not the discovery path. The source says as much in its own terms, arguing that NHI governance must include device posture, secret minimisation and rapid revocation, not just vaulting policy ^[15], and its recommended first action is to inventory local secret exposure paths and remove reusable credentials from endpoints rather than to catalogue them more thoroughly ^[20].

There is a timing observation hiding in the same entry, and it is the closest thing here to a market clock. Organisations typically confront this surface only after a token leak, a plugin compromise or an endpoint takeover ^[17], and the entry points to JetBrains GitHub plugin token exposure as an illustration of developer tooling becoming the real control point for identity compromise ^[16]. Nothing in the supplied material dates a window or sizes a market. What it describes is a category that gets purchased reactively, which is a fact about sales motion as much as about security.

The browser entry is already written as a product spec

The second surface arrives further along. The FAQ on browser-derived signals does not stop at asserting importance; it specifies a pipeline. Collect session telemetry from the browser, the identity provider and downstream applications; correlate it with account ownership, device posture and privilege level; use the resulting risk picture to gate step-up authentication, session revocation or analyst review; then feed confirmed findings back into access reviews and offboarding so stale identity records get corrected ^[24]. That is three data sources joined against three enrichment attributes before any decision is made [c24d], which is a description of integration work, and integration work is where the build-or-buy question actually lives.

The claimed payoff is temporal. Session anomalies, impossible travel, unusual user agents, token reuse and shadow accounts tend to appear in the browser before they show up in directory logs or PAM records ^[22], and the browser can indicate whether a session comes from a managed device, whether cookies or tokens are being reused across contexts, whether a login flow is automated, and whether an account is touching resources outside its historical pattern ^[25]. Ignore all of that and, per the same FAQ, you lose the earliest evidence of unmanaged accounts and compromised logins, and your access reviews, incident triage and blast-radius estimates run on incomplete data ^[21]. The specific structural gap named is federated single sign-on on its own, where the browser session can stay active long after the authentication event behind it has gone stale ^[26]. Teams that do not close that gap tend to learn about risky browser activity only after a token has been replayed or an unmanaged account has already been used ^[27].

The two surfaces overlap at exactly two artefacts

These read as separate categories, but the lists collide. Browser profiles and AI assistants appear in the endpoint definition's inventory of identity-bearing paths ^[8], and browser session and token state is the substance of the browser signal set ^[22][25]. So the same two artefacts, the browser session and the AI assistant, are being claimed by both framings. An AI coding assistant indexed into a repository suggesting secrets patterns or past credentials sits on the endpoint side [c12b]; a cloud console session cookie that later grants access to privileged non-human identity workflows sits on both [c12a]. Anyone building here has to decide which side of that overlap they own, because a buyer with both products is paying twice for the same telemetry.

What actually constrains this

Both entries volunteer their own cost, which is unusual and useful. Doing the endpoint work rigorously adds friction to developer workflows, forcing a trade between fast iteration and tighter credential handling with more frequent reauthentication ^[19]. Tighter browser visibility increases operational overhead and has to be balanced against privacy constraints, endpoint diversity and analyst workload ^[28]. Privacy and labour policy may prohibit inspecting browser content at all, which pushes the guidance toward metadata, session attributes and access context ^[29], and the signals go noisy in heavily virtualised or shared-device environments where correlation with device trust, IdP logs and application events becomes mandatory rather than optional ^[30]. The value also splits by population: managed employee devices produce the most actionable signals because posture, extension inventory and session history tie back to a known endpoint, while for contractors, third parties and automation accounts the browser may be the only place hidden usage shows up ^[31]. The FAQ's own limit is that browser data should feed risk scoring and not be treated as a source of truth ^[32].

The sharpest constraint is that nobody has fixed the threshold. The FAQ states plainly that best practice is evolving and there is no universal standard for how much browser telemetry is enough ^[28], and the endpoint entry concedes that guidance varies across vendors even where the pattern is consistent ^[10]. Both entries reach instead for external scaffolding, mapping the attack and risk surface to the OWASP Non-Human Identity Top 10 and the governance and control requirements to NIST CSF 2.0 and NIST SP 800-207 ^[18]. That is the procurement language a category uses before it has its own benchmarks.

Two caveats a buyer should hold. Both surface definitions come from the same publisher ^[33], and their supporting citations point back to that group's own research, so this is one organisation's framing rather than independent corroboration. And the AI coding driver, the thing that makes both surfaces busier, is the least evidenced item in the set: ActiveState says its research quantifies the acceleration of remediation backlogs and maps it to liability and business outcomes ^[3], and the material is promotion for a session with the company's Rebecca Banks and Moris Chen ^[4], but the only number supplied is the sample of 300 and the striking multiplier appears in a headline as a question ^[5][6].

The most honest thing in that promotion is its framing of the remedy: distinguishing approaches that mitigate remediation burden from those that merely redistribute it ^[4]. That test applies directly to both unclaimed categories. Endpoint credential hygiene redistributes burden onto developers through reauthentication ^[19]; browser telemetry redistributes it onto analysts through volume ^[28]. A product that only moves the load will be measured, eventually, against the five-day figure ^[13].

What to watch: whether the 300-leader survey publishes backlog numbers that can be checked rather than summarised ^[2][3]; whether any sufficiency standard for browser telemetry emerges, given the current admission that none exists ^[28]; and whether vendors selling into the endpoint surface report on revocation latency rather than on discovery counts, which is the only claim that answers the day-five number ^[13][14].