Join our Newsletter — 33% off our NHI Course

Client-Side AI

AI tools that run in the browser and use live page content or interaction data to generate responses or assistance. They can create immediate outbound data flows, so governance must cover both the inputs they observe and the destinations they transmit to.

What Client-Side AI Actually Means

Client-side AI runs where the user is interacting, typically in the browser or a similar local runtime, so the model can see live page state, selections, forms, prompts, and other interaction data before producing output.

That placement matters because the AI is no longer receiving only deliberately packaged inputs from a backend. It is observing transient content and user actions directly, which expands both the data it can access and the number of places where sensitive material can leak.

Why Client-Side AI Changes the Trust Boundary

Client-side AI shifts part of the security boundary into the user’s session. The tool may appear as a local productivity feature, but it can inspect data that was never meant to leave the page, including internal text, hidden fields, authenticated views, or copied content.

That means the important question is not only what the AI can generate, but what it can observe. If the feature processes data from the current page, the trust model must account for page context, browser permissions, embedded scripts, and any data the extension or web app can collect before a response is formed.

Outbound Data Flows and Exposure Paths

Client-side AI can create immediate outbound data flows because its outputs often depend on the page content it just observed. Those flows may include prompts, snippets, metadata, or transformed user content sent to an API, model service, telemetry endpoint, or third-party integration.

That makes destination control a core security concern. If the browser feature can transmit page-derived data to multiple endpoints, governance has to cover OAuth 2.0 access boundaries, token audience, and the specific services that are allowed to receive user content. API security controls matter because the AI’s convenience can quickly turn into unauthorized data disclosure if downstream calls are too broad or too loosely authorized.

Common Failure Modes in Client-Side AI

The most common failures are overcollection, data leakage, and excessive trust in what the browser side is allowed to see. A client-side assistant may ingest secrets, personal data, or confidential business content simply because that information is present in the DOM or in the user’s active workflow.

One practical example is exposed credentials in browser-accessible code or integrations. NHIMG’s Google API Keys Exposure, Gemini AI shows how client-side exposure can turn a visible key or embedded secret into an immediate leak risk. That is a broader pattern, not a narrow vendor issue: anything the browser can see, the AI can potentially summarize, reuse, or transmit.

Risk and Threat Considerations

Client-side AI creates risk when sensitive page data, secrets, or user actions are observed and forwarded without tight control over what is collected and where it goes. The threat is not just model misuse, it is the combination of local visibility, rapid outbound transmission, and weak destination governance.

Failure mechanism: The assistant reads live browser content or interaction state, then packages that data into prompts or API calls that leave the page context. If the browser surface includes credentials, customer records, internal text, or hidden fields, those values can be exfiltrated or persist in downstream logs.

Impact: Organisations can lose confidentiality, violate data-handling expectations, or expose secrets through otherwise ordinary user interactions. At scale, the same pattern can create broad leakage across many sessions, because the browser becomes an active data collection point rather than a passive display surface.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP API Security Top 10 addresses the attack surface, NIST SP 800-53 Rev 5 sets the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.

Framework Control / Reference Relevance
OWASP API Security Top 10 API8 — Security Misconfiguration Client-side AI often depends on API calls and destination controls.
Recommendation — Restrict AI endpoints and validate request handling to prevent unintended data exposure.
NIST SP 800-53 Rev 5 AC-6 — Least Privilege Client-side AI should only access the minimum data needed from the browser context.
AU-2 — Event Logging Client-side AI needs traceability for prompts, collection, and outbound transmission.
Recommendation — Limit browser-side AI access to the smallest feasible data set and destinations. Log AI data collection and outbound calls so sensitive flows can be investigated.
ISO/IEC 27001:2022 A.5.15 — Access control Client-side AI depends on controlling which content and services it can reach.
Recommendation — Apply access control to browser-visible content and AI transmission endpoints.

Practitioner Guidance

What to watch for: Treat client-side AI as a data egress path, not just a UI feature. Review what the assistant can observe in-page, what it can serialize, and which endpoints it can reach, then keep the data path aligned to the minimum information needed for the feature to work.

Governance implication: Ownership should cover browser inputs, prompt construction, API destinations, and telemetry separately, because each of those stages can expand exposure. If the feature can see authenticated or sensitive content, its design should reflect that sensitivity in the same way you would review any other user-facing data transmission path.