Client-Side Least Privilege

Expanded Definition

Client-side least privilege extends least-privilege thinking into the browser and other user-facing execution environments. Instead of assuming the browser is a passive display layer, it treats scripts, embedded widgets, extensions, and autonomous agents as active actors that should receive only the data objects, permissions, and API methods required for a specific user task. That distinction matters in modern web applications, where front-end code often handles live tokens, account data, payment flows, and delegated actions.

In security terms, the model overlaps with NIST SP 800-207 Zero Trust Architecture because trust is not implied by location or session state. It also aligns with the control intent in NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where access restriction, session governance, and data minimisation intersect. For NHI and agentic AI use cases, the principle becomes sharper: browser-resident agents should not inherit broad, standing access simply because a human opened the page.

Definitions vary across vendors when client-side least privilege is mixed with browser sandboxing, content security policy, or front-end authorisation patterns, so the term should be read as an access-control principle rather than a single product feature. The most common misapplication is equating hidden UI elements with restricted access, which occurs when sensitive APIs remain callable from the client even though the interface does not expose them.

Examples and Use Cases

Implementing client-side least privilege rigorously often introduces extra policy design and token choreography, requiring organisations to weigh reduced exposure against greater front-end complexity.

• A banking portal exposes account summaries to the browser but withholds raw payment-initiation APIs unless the session is reauthorised for that action.
• A customer support console loads only the case fields needed for the current queue, rather than prefetching full profiles, notes, and attachments into the DOM.
• A browser-based AI assistant is allowed to read a ticket draft but cannot access secret stores or invoke high-risk APIs without explicit user confirmation and scoped delegation. The OWASP Non-Human Identity Top 10 helps teams think about this as a credential and authority problem, not just a UI design issue.
• An embedded third-party widget receives a narrow data contract and cannot call internal APIs directly, reducing the chance that supply-chain compromise becomes full-session compromise.
• A SaaS application enforces step-up checks before privileged actions such as exporting records, changing roles, or downloading sensitive files, even though the user remains logged in.

These examples show the term in practice: the browser may participate in access decisions, but it should never become a blanket trust zone. In a Zero Trust Architecture, the client is continually constrained by context, purpose, and scope rather than treated as inherently safe.

Why It Matters for Security Teams

Security teams care about client-side least privilege because the browser is now a control surface, not merely an endpoint. When scripts or agents overreach, the damage is immediate: exposed secrets, overbroad session tokens, unintended API calls, and lateral movement through trusted front-end workflows. That creates direct risk for IAM, PAM, and NHI governance, especially where machine identities or agentic workflows operate inside the browser and inherit the same session as the human user.

The governance challenge is that front-end privilege often becomes invisible during design reviews. Teams may harden the backend while leaving the client able to enumerate resources, trigger actions, or persist credentials in ways that defeat the intended access model. Controls from NIST SP 800-53 Rev 5 Security and Privacy Controls are relevant here because they reinforce access enforcement, information flow restriction, and session management as operational requirements, not UI preferences.

Organisations typically encounter the full impact only after a malicious script, abused browser extension, or over-scoped AI agent exfiltrates data or performs an action that the business assumed the interface would prevent, at which point client-side least privilege becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• What is the difference between strong client authentication and least privilege?
• Why do application-side authorization paths undermine least privilege?
• What is the principle of least privilege and how does it apply to NHIs?
• What is MCP Step-Up Authorisation and how does it implement least privilege for agents?