The governance question most organizations ask about AI is the right one. Whether it concerns data quality, model explainability, output moderation, or API access controls, most enterprise AI governance programs focus on the model: what it was trained on, what it produces, and who can use it. However, the model is not where the problem starts.
Before a prompt reaches a model, something assembles it. User inputs are collected, contextual signals are appended, session data is pulled, and behavioral identifiers are attached: all inside a browser, in real time, during a live customer session. The scripts and agents doing that assembly have broad access to everything on the page: visible form fields, hidden DOM elements, session tokens, browser storage, and live network traffic. They operate before the user has explicitly initiated any AI interaction. In many organizations, they operate entirely outside the scope of AI governance programs never designed to look that far upstream.
This article is about the AI scripts and widgets you embed in your own site, such as chatbots, personalization engines, and AI analytics SDKs. AI browsers and browser extensions raise related questions, but they’re a separate problem.
Where AI Governance Stops
Enterprise AI governance frameworks are built around a reasonable mental model: the AI system is the risk surface, so governance applies to it. That means managing training data integrity, validating model outputs, controlling API access, monitoring for bias or toxicity, and maintaining audit trails of model behavior.
These controls are necessary. They are also incomplete in a way that has become structurally significant.
According to Deloitte’s State of AI in the Enterprise, security and data privacy are the top AI concerns among enterprise leaders, each cited by 73% of respondents, well ahead of governance oversight and model reliability (50%). The survey of 3,235 leaders, from director to board level, also found that while nearly three-quarters of organizations plan to deploy AI agents within two years, only 21% have a mature governance model for agentic AI. The governance that does exist tends to focus on what happens after data reaches the model, not how it was assembled beforehand.
The gap is not a failure of intent. It is a failure of scope. AI governance programs were designed when the primary risk was model behavior, and the primary risk has expanded upstream.
What’s Happening Before the Prompt
When an AI-powered script operates in a browser session, it doesn’t wait for the user to type a prompt before it starts working. From the moment it loads, it can read the page it’s deployed into, with access to far more than most organizations realize.
The mechanisms are worth understanding specifically, because the risks they create are specific.
DOM scraping is the most direct form of pre-prompt data collection. An AI agent operating on a page can read any element in the Document Object Model, including form fields, hidden inputs, dynamically generated content, and data attributes that were never intended to be part of an AI interaction. A user filling out a healthcare intake form, a payment checkout, or an identity verification page may have an AI script read that information before they submit it, before any server-side control has seen it, and in some cases before they finish typing it. This is documented behavior for third-party scripts in general. The Leaky Forms study (USENIX Security 2022) found scripts collecting email addresses before form submission, without consent, on 1,844 websites in the EU and 2,950 in the US. The Markup found the Meta Pixel sending appointment details, including doctors’ names and conditions, from the websites of 33 of the top 100 US hospitals. AI-driven collection follows the same pattern: a UCL-led study of ten AI browser assistants found several sent full webpage content to their servers, and one captured form inputs such as online banking and health data.
Session token and browser storage access extends the collection beyond what is visible. Cookies, local storage, and session storage contain authentication tokens, user identifiers, behavioral histories, and preference data. Any script running on the page can read local storage, session storage, and every cookie not marked HttpOnly. Session tokens kept in local storage, a common pattern in single-page apps, are fully exposed. The user has not prompted anything. The model has not been invoked yet. But the context being assembled for that eventual invocation may already include data the user would not knowingly include.
Network traffic interception lets AI agents hook into fetch calls and network requests on the page, read live API responses, intercept submitted data, and append contextual information from real-time interactions. This happens inside the page’s JavaScript runtime, by wrapping (monkey-patching) functions like fetch and XMLHttpRequest, out of view of server-side, network, and most privacy controls.
Hidden field and application state access means that data the application has available, but not displayed to the user – pre-filled identifiers, application-side context, session-level flags – can also be read by a script with DOM access. An AI system assembling a prompt may incorporate data the user was never aware was on the page.
By the time a user sends a message to a chatbot or triggers an AI-powered feature, the agent may already have assembled a context package that includes their identity, session history, payment details, behavioral signals on the page, and proprietary application data, all drawn from sources the user never explicitly offered and the organization may not have intended to share.
This isn’t a flaw in one vendor’s script. It’s the default capability of every script on the page: the browser gives third-party code the same access as your own.
Differences From Traditional Data Leakage
The security industry has governance models for data leakage. They rely on a core assumption: that the data being leaked follows deterministic, rule-governed logic. A script either sends data to an endpoint, or it does not. A configuration is either correct or it is not. Fix the misconfiguration, block the unauthorized transmission, update the policy, and the problem is addressed. AI-powered data collection doesn’t follow that model, and the difference isn’t minor.
AI agents are non-deterministic. Traditional scripts follow fixed rules, while AI agents interpret context and can decide at runtime what’s relevant on the page. On top of that, vendors often control what a script collects remotely, so its behavior can change from one session to the next without notice.
This creates a governance problem that static, configuration-level controls alone cannot solve. There’s no single configuration to audit, no static policy that covers the full collection surface, and no way to validate compliance by examining a ruleset instead of observing actual runtime behavior.
Exposure can become irreversible. With conventional data leakage, remediation is possible: revoke access, patch the misconfiguration, block the endpoint. With AI ingestion, the remediation window may have already closed before discovery.
When browser-assembled data flows into an external AI system, it can be logged as interaction history, retained for abuse and safety monitoring, or, depending on the provider’s terms, used to train future models. Enterprise terms often exclude training, but retention is harder to rule out. OpenAI, for example, keeps API abuse-monitoring logs for up to 30 days by default, and in 2025 a US court ordered it to preserve output logs that would otherwise have been deleted, including those deleted at users’ request. You rarely know which AI provider a third-party script relies on, or under what terms. Once data enters that pipeline, you have no reliable way to get it back. A deletion request may not reach logs, backups, or training data already absorbed, and no incident response playbook recovers context that has become part of a model’s operational state.
This changes the nature of the risk. With traditional data leakage, the harm follows the exposure. With AI ingestion, harm may persist long after the original session ends.
Two Distinct Risks: Privacy and Competitive
The governance conversation around AI data tends to collapse into a single category: privacy risk. This is where regulatory pressure is most immediate. But client-side AI data ingestion creates two structurally distinct risks, and conflating them leads to incomplete governance programs.
The privacy risk is the one most governance frameworks address, at least in principle. AI scripts may collect personal or regulated data beyond the scope of user consent, violate data minimization principles, or collect it before consent is recorded. Consent management platforms capture user intent; they do not technically restrict what a script does once it has permission to run. An AI script operating under a broad “analytics” consent category may collect data that no reasonable user would associate with analytics — and the governance framework has no mechanism to detect or prevent it.
The regulatory exposure compounds. For high-risk AI systems, the EU AI Act requires providers to apply data governance practices and deployers to ensure input data under their control is relevant to the system’s intended purpose. The AI Omnibus, in force since July 2026, moved those obligations for stand-alone high-risk systems to 2 December 2027. GDPR requires a lawful basis for processing and the ability to demonstrate compliance with data minimization and purpose limitation. Organizations certifying against ISO/IEC 42001 must show controls over the data their AI systems use. No consent banner alone can satisfy these frameworks. They require evidence of what was actually collected, when, by what system, and under what authorization.
The competitive risk is less discussed but in many contexts more immediately damaging. Proprietary workflows, pricing logic, and behavioral signals embedded in browser execution represent genuine competitive assets. When AI scripts collect this data and transmit it to external AI systems, that information becomes model input. Behavioral signals from customer sessions can inform external recommendation systems. Pricing interactions can become training signals for models you don’t control. Proprietary workflow logic can become shared context in external AI environments. The risk is well understood when employees do it by hand: in 2023, Samsung engineers leaked internal source code and meeting notes by pasting them into ChatGPT. Third-party scripts can do the same thing silently, at scale.
Data doesn’t need to be stolen for competitive harm to occur. It only needs to flow through AI systems not exclusively under the organization’s control. Your data becomes model fuel, and your differentiation becomes shared context.
What Enforceable AI Data Governance Looks Like at the Browser Layer
The governance gap described here can’t be addressed by improving model-side controls. By the time the model sees it, the data has left the browser. If collection exceeded its authorized scope, the harm has already occurred, whether or not the model was secured.
Closing the gap requires extending governance upstream, into the browser, where AI inputs are assembled. That means three specific capabilities.
Continuous AI-powered script discovery and data access mapping. An organization cannot govern what it cannot see. The first requirement is a real-time inventory of every AI-powered script and agent operating within browser sessions, with visibility into what data each one can access. Not a point-in-time audit: a continuous map that updates as scripts are added, modified, or expand their behavior. AI scripts are deployed through tag managers, updated independently by third-party vendors, expanded in scope without notification, and can quietly call fourth-party AI services you never vetted. Non-continuous discovery is not sufficient.
Runtime data access enforcement. Visibility without control is observability, not governance. Effective AI data governance requires enforcing least-privilege principles directly in the browser, restricting which AI scripts can access which form fields, DOM elements, storage objects, and network requests in real time during live sessions. This is technically distinct from what consent management platforms do. CMPs control script loading; runtime enforcement controls script behavior after loading.
Audit-ready runtime evidence. Because AI data collection can change at runtime, you can’t verify compliance by examining static rules. It requires continuous observation of actual runtime behavior — what each script accessed, what it transmitted, and to which endpoints — generating an audit trail that reflects what actually occurred, not what was intended. That telemetry provides the evidence base to demonstrate compliance with the EU AI Act’s data governance provisions, GDPR’s accountability requirements, and any internal AI governance policy that must withstand external scrutiny.
Map which AI-powered scripts on your site can access sensitive form fields before they do. Explore Jscrambler AI Data Governance & Security.
