Privacy
This page explains how BriarKit handles tool input, what data may be collected by normal site infrastructure, and how users can evaluate those boundaries.
Local tool processing
BriarKit is designed so that supported utility workflows run locally in the browser. In practical terms, that means text you paste, files you drop into a tool, and results generated by that tool are intended to remain on your device rather than being submitted to an application server for processing.
This model is especially important for developer workflows because the material people test with is often sensitive even when it is not formally regulated. JSON payloads may include customer records. Logs may contain internal URLs. Tokens, secrets, keys, or private snippets may appear in copied content. Local execution reduces the exposure that would otherwise come from uploading that material to a third-party backend.
What this does and does not mean
Local tool processing does not mean the website itself operates without any normal web infrastructure. Like most sites, BriarKit may still rely on hosting providers, delivery networks, analytics products, and advertising scripts that receive standard technical request data when a page is loaded.
That category of information can include IP address, browser and device details, referrer information, page URLs, timestamps, and general interaction data associated with loading or using the site. This is different from the specific content you place into supported browser-only tools, and that distinction is fundamental to how the site is positioned.
Analytics, diagnostics, and ads
Basic analytics and operational diagnostics may be used to understand site stability, traffic patterns, and high-level product usage. Those systems help identify broken pages, performance regressions, and broad usage trends, but they should not be treated as a channel for collecting the full contents of tool inputs when a workflow is documented as local-only.
If advertising is present, ad providers may also collect information according to their own technologies and policies, including cookie or device-level signals where applicable. Advertising and analytics behavior is separate from the promise that supported tool transformations themselves are intended to happen inside the browser.
Retention and disclosure principles
Because supported tool inputs are intended to remain local, BriarKit should not need to retain the contents of those inputs on an application server for the ordinary use of those tools. However, standard infrastructure providers may temporarily retain routine access logs or telemetry according to their own operational retention policies.
Information may also be disclosed when required to comply with law, enforce site security, investigate abuse, or protect the service and its users. Those are standard platform constraints and should not be interpreted as a reason to submit highly sensitive information anywhere a workflow is not clearly documented as local.
User responsibility and verification
Users should make their own judgment before processing confidential or regulated data. The strongest way to evaluate the privacy model is to inspect network activity directly in browser developer tools while using a specific page or feature. That gives a concrete view of what requests are being made and helps distinguish local computation from normal page-level infrastructure.
If your environment has strict compliance, contractual, or internal security requirements, you should validate those requirements independently before relying on any web-based utility. BriarKit is designed to reduce unnecessary data movement, but users remain responsible for the policies that apply to the material they handle.