privacy
What happens to a trace you upload.
Last updated 2026-09-16
This page describes the service as it is built today, not as it is planned. There are two ways to use Boxdawn and they are not the same: a one-off upload, where you are not signed in and nothing about your trace is kept, and a connected project, where you are signed in and we keep measurements over time. Signing out is how you choose the first one. Where a section below applies to only one of them, it says so.
Optional account, no tracking
You can use Boxdawn without signing in, and that is the default. Signing in is optional, and it sets cookies whose names begin with sb-, which carry your session and nothing else. The site loads no analytics script and embeds no third-party tracker, so no other cookie is set. Our hosting providers keep their own standard request logs, as every web host does.
What happens to the file itself
An uploaded file is sent over HTTPS to the analyzer, written into a temporary directory, analyzed, and that directory is destroyed when the request ends. We do not copy it anywhere of our own, and we do not use it to train anything. On a one-off upload that is the whole story: the run happens inside that single request, and nothing about the file outlives it. A connected project is different. The run is handed to Modal as a background job so this page can poll for the result, and Modal keeps that job's result fetchable for up to seven days before it expires. The boxdawn submit command sends the file to that same hosted analyzer with a project key, so it takes the same background path. On that path the file itself travels to Modal as the arguments of that job, and Modal's client puts arguments above a size threshold into its own blob storage rather than passing them inline. In the client we read, that is 2 MiB for any call at all and 8 KiB for a background call like ours. The platform can raise either, and for our own function it does not: we asked the service on 16 September 2026 and it sends no such override, so those two figures are what apply. How long Modal keeps that copy we do not know. The seven days above is documented for the job's result, we have found no published figure for the arguments, and we would rather write that down than guess.
Where the analysis runs
The hosted analyzer runs on Modal, a third-party serverless platform, so an uploaded trace leaves your machine. Modal routes uploads through its servers in Virginia, USA, which is its default region. We have not fixed the region the analysis itself runs in, so we do not promise a country here. If that matters to you, run the same detector locally: the deterministic detectors need no network and no API key. Transfers out of the EU are covered by the standard contractual clauses in Modal's data processing addendum, which comes with its terms rather than being something we negotiated.
Where your account and measurements are kept
Accounts and measurements are stored in Supabase, in Seoul, and that one we do fix. The analysis happens elsewhere, and neither the trace nor the report is stored there; what is kept afterwards is kept in Korea. Korea is one of the countries the European Commission has recognised as providing adequate data protection, in a decision adopted on 17 December 2021, so personal data can move there from the EU on the same footing as a transfer inside it.
What could reach a model provider
The deterministic detectors do the analysis on our own machines. The semantic-duplicate LLM-judge, which the command-line tool can turn on with your own API key, is never enabled on the hosted analyzer, on any plan. One further layer is different: a verification check that asks a model whether a session confirmed what it changed. Our own API key is present on the hosted analyzer as of 3 September 2026, and on a paid project this check runs on every upload, automatically. It is on by default, and a project admin can switch it off for that project; while it is off this check never starts, so this check sends nothing from that project's traces to a model, and waste measurement keeps working as before. There is no request parameter that turns it off for a single upload, and a free project is refused before the call is made. The command line has two commands and the rule is not the same for both. boxdawn analyze runs on your own machine, and there the rule is the reverse: nothing goes to a model unless you pass --verification yourself, with your own key. boxdawn submit is not that. It sends the file to the same hosted analyzer with your project key, so the hosted rule above is the one that applies: on a paid project with the check on, it runs there, on our key, whether or not you asked for it. When the hosted check runs it does not send a summary: tool names go up with their inputs, which include file paths and commands exactly as they appear in your trace, plus up to 2,000 characters of each tool's output, inside a rendered view capped at 120,000 characters. It also carries what you asked for: the text you typed to the agent, de-duplicated and in the order it appeared, at the top of the view. Tool results are not included, even though the trace format records them under the user role. The model's answer is not written to our database, so this is a transfer and not a second copy. That is the same data we keep out of our database on purpose, which is why this section names it instead of summarising it.
Trace bodies are never in the report
The analyzer is invoked with --no-snippets, so prompt text and tool output from your trace are not included in the report at all.
What the report does contain
A report can contain file paths and commands taken from your own trace: which file was read twice, which command ran again. Those are not masked, because that is the finding. The report is returned to the browser that asked for it. On a one-off upload that is the only place it goes: no share links, no history, nothing to come back to. On a connected project we do not store the report file either, but it does not disappear when you close the page: the report comes back as the result of a background job on Modal, and Modal keeps that result fetchable for up to seven days before it expires. The ticket your browser uses to fetch it does not expire on its own, so anyone holding that ticket can fetch the report during those seven days. What we keep is a set of measurements derived from it (counts, sizes, costs) plus salted hashes of the targets.
If the analysis fails
A failure returns diagnostic output. That output is sanitized before it is returned or written to logs: caller-side file paths, email addresses, and secret-shaped strings such as API keys and bearer tokens are masked. The report body itself is deliberately left unmasked, for the reason above.
Limits
One file per analysis, .json or .jsonl. Up to 10 MB on a one-off upload, which runs while you wait; up to 16 MB on a connected project, where the run happens in the background and this page polls for the result.
Questions
Open a GitHub issue. There is no support inbox yet, and we would rather say so than publish an address nobody reads.
Claims on this page describe implemented behavior. We do not claim encryption at rest, anonymization, or regulatory compliance that we have not built and verified.