Who is accountable when a malicious extension or fake AI tool steals credentials from managed endpoints?

Accountability usually spans the endpoint owner, the software approval process, and the identity team that allowed privileged data on the device. If extension installation was unrestricted or the tool could access browser sessions and secrets, then the governance failure is shared. Frameworks such as OWASP-NHI and zero trust help assign those boundaries more clearly.

Why This Matters for Security Teams

When a malicious browser extension or fake AI tool steals credentials from a managed endpoint, the failure is rarely just “endpoint security.” The real issue is that privileged data was available to software that had no business seeing it, and the organisation had not clearly separated device trust, application trust, and identity trust. That is why OWASP Non-Human Identity Top 10 and the NIST Cybersecurity Framework 2.0 matter here: both push teams toward tighter control of where secrets live and how access is granted.

NHIMG research on the Secret Sprawl Challenge shows that secret distribution is often the hidden weakness behind visible compromise. If a browser session, local vault, or synced token can be read by an extension, then the endpoint has effectively become a privileged secrets store. In practice, many security teams encounter this only after a fake productivity plugin or AI helper has already exfiltrated tokens, rather than through intentional review of extension and software trust boundaries.

How It Works in Practice

Accountability usually splits across three control planes: the endpoint owner, the software approval process, and the identity or platform team that allowed privileged secrets on the device. The endpoint team is responsible for hardening the workstation, disabling unnecessary extension access, and restricting local secret exposure. The software governance team is responsible for approving only vetted extensions, packages, and AI tools. The identity team is responsible for ensuring the device does not hold reusable credentials that can be harvested and replayed.

In practical terms, the best defensive pattern is to minimise what can be stolen and reduce how useful it is if stolen. That means using short-lived sessions, device-bound tokens where possible, and just-in-time access for privileged operations rather than static secrets stored in the browser or a local profile. NHIMG guidance on Static vs Dynamic Secrets is directly relevant because long-lived credentials dramatically increase the blast radius of endpoint compromise.

• Restrict extension installs to an allowlist and review requested permissions, especially clipboard, session, and page-read access.
• Keep privileged credentials out of browser storage, synced profiles, and unmanaged local vaults.
• Use conditional access and reauthentication for sensitive actions rather than trusting the device indefinitely.
• Separate administrative workflows from general productivity browsing and AI assistant use.

For identity and access teams, the operational standard should align with NIST Cybersecurity Framework 2.0 and NIST SP 800-63 Digital Identity Guidelines so authentication strength, session binding, and recovery flows are not treated as afterthoughts. These controls tend to break down in hybrid environments where users install extensions on managed laptops but authenticate to cloud services from multiple profiles, because the trust boundary becomes fragmented and hard to enforce consistently.

Common Variations and Edge Cases

Tighter extension control often increases support overhead, so organisations have to balance stronger containment against user friction and shadow IT pressure. That tradeoff is real, especially in environments that depend on browser-based SaaS, developer tools, or AI copilots for daily work.

There is no universal standard for every case yet, but current guidance suggests that accountability changes with where the secret was stored and who approved the tool. If the endpoint was fully managed and the tool bypassed policy controls, the endpoint and application governance owners carry most of the blame. If the identity team left reusable secrets accessible in the browser, then the identity control failure is central. If the user installed an unapproved extension on an unmanaged device, accountability shifts more heavily toward endpoint policy enforcement and software acceptance processes.

This is also where NHI Lifecycle Management Guide and Top 10 NHI Issues help teams separate lifecycle ownership from incident response. For organisations using browser extensions as part of AI workflows, the more relevant question is not only “who caused the theft?” but “who allowed a non-human workload credential to become reachable from an untrusted execution surface?” That is the control failure that needs assignment.

Related resources from NHI Mgmt Group

• Who is accountable when shadow AI is used from managed endpoints?
• Who is accountable when AI tool use happens through unmanaged browser sessions?
• Who is accountable when shadow AI uses corporate credentials to process sensitive data?
• How can security teams reduce AI data leakage from managed endpoints?