A user-approved browser action that creates access or data movement beyond the original session. This can include OAuth consent, extension permissions, or app connections that continue to operate after the immediate interaction ends. It is a governance problem because the access outlives the moment of approval.
Expanded Definition
Browser-granted identity spillover describes a governance condition where a user’s browser approval creates a durable access path that persists beyond the original interaction. In NHI terms, the browser becomes the delivery point for delegated access, whether through OAuth consent, third-party extensions, or connected applications that retain permissions after the session ends. The key issue is not the initial click, but the continuing authority that the click enables.
Definitions vary across vendors on where this boundary begins and ends. Some teams treat only OAuth consent as spillover, while others include extension permissions, app-to-app grants, and browser-managed session tokens. NHI Management Group treats the term as a practical control problem: any browser-originated approval that creates standing access, persistent data movement, or ongoing tool invocation should be governed as identity expansion. That framing aligns with broader NIST Cybersecurity Framework 2.0 principles around access control and continuous governance.
The most common misapplication is assuming a one-time consent screen equals one-time risk, which occurs when persistent permissions are not reviewed after the browser interaction ends.
Examples and Use Cases
Implementing browser-granted identity spillover rigorously often introduces user friction and admin overhead, requiring organisations to weigh convenience against the cost of persistent access review.
- An employee authorises a productivity app in the browser, and the app continues reading mail or files long after the user closes the tab.
- A browser extension receives broad permissions to inspect pages or inject content, then retains access across internal applications until manually removed.
- An OAuth grant connects a SaaS tool to a corporate account, creating a background data sync that persists outside the original login session.
- A developer approves a browser-based integration during troubleshooting, then forgets to revoke the connected token after the issue is resolved.
These patterns are visible in breach and governance analyses such as 52 NHI Breaches Analysis and the broader Ultimate Guide to NHIs, where lingering permissions and weak offboarding repeatedly increase blast radius. Industry guidance also intersects with browser and app authorization models described in the OAuth 2.0 framework, though browser-granted spillover is an operational term rather than a formal protocol category.
Why It Matters in NHI Security
Browser-granted identity spillover matters because it turns ordinary user approval into a non-human access problem. Once a browser or browser-connected app holds delegated authority, the resulting identity can act independently of the user’s immediate intent, session state, or attention. That creates governance gaps around revocation, logging, and least privilege, especially when access is granted through extensions, OAuth scopes, or connected apps that are never reviewed again.
This is where NHI risk becomes visible at scale. NHI Management Group reports that 97% of NHIs carry excessive privileges, and 71% are not rotated within recommended time frames, conditions that magnify the impact of browser-originated permissions when they are left standing. The same lifecycle weakness appears in the Top 10 NHI Issues and the Ultimate Guide to NHIs, where uncontrolled delegation and poor visibility consistently drive exposure.
Organisations typically encounter the consequence only after a leaked token, exfiltrated mailbox, or overbroad extension permission is discovered, at which point browser-granted identity spillover becomes operationally unavoidable to address.
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.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers secret and token exposure from delegated browser approvals. |
| NIST CSF 2.0 | PR.AC-4 | Maps to managing permissions and limiting access after initial consent. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires continuous verification after browser-mediated authorization. |
Review browser-consented tokens and extensions for overbroad access, then revoke unnecessary standing permissions.
