How to Verify a Document Scanner Doesn't Upload Your Files

Disclosure. Strike Labs makes Strike Gate, a document scanner that claims local processing. That gives us a reason to want you to believe local-processing claims. This guide is written so you don't have to believe ours: every test applies to any vendor, and we describe what the tests cannot prove.

"Private," "secure," "encrypted," and "local-first" are not the same claim. An encrypted service can still upload your document to its servers. A local scanner can still send telemetry. An app that works offline today can start uploading after an update.

What a "files never leave your device" claim should cover

A meaningful claim says which of these leave the machine, where they go, and why:

• Document contents — the file itself, in any encoding.
• Derived content — extracted text, snippets, hashes, or embeddings.
• Metadata — filename, size, page count, author, path.
• Findings — which markings were found, where, and how many.
• Account and licensing data — identifiers, scan counts, purchases.
• Diagnostics — analytics, crash reports, and error logs, which often capture whatever was in memory at the time.

Findings and metadata deserve the same scrutiny as content. A report that says "this file named Program_X_Brief.pdf contains SECRET//NOFORN banners on pages 3–7" leaks a great deal without sending a single page.

Some network traffic may be acceptable, such as a license check. The vendor should disclose it precisely, and you should be able to confirm the disclosure matches what you observe.

Set up the test

Use synthetic documents only. Never test with real CUI or government information. Testing on an unauthorized system can itself be an incident.

Plant canary strings. Put a unique, searchable token in each test file — for example CANARY-7f3a91 in the body, a different one in the filename, and another in the document properties. If any of those strings later appears in captured traffic, logs, or a vendor's dashboard, you have proof of transmission. This is far more reliable than eyeballing requests.

Include realistic markings. A scanner that behaves differently when it finds something should be tested when it finds something. Use clearly fake but correctly formatted banners and portion marks, plus a clean control file.

Use a clean, disposable environment. A fresh virtual machine or browser profile avoids interference from other extensions, cached sessions, and background apps. It also makes the first-install test in Test 2 possible.

Record versions. Note the product version, build, operating system, browser, and date. Results apply to that combination only.

Test 1: Watch the browser's network traffic

For web-based scanners, start with the browser's own tools (Chrome DevTools Network panel).

1. Open DevTools, select Network, enable Preserve log, and clear existing entries.
2. Load the page and let it settle. Note the baseline requests.
3. Select the test file and run a scan.
4. Keep recording for several minutes afterward. Some apps send data later, in batches, or when the tab closes.
5. Search all captured requests for your canary strings (DevTools search covers request and response bodies).

What to look for:

• Uploads — POST or PUT requests, multipart form data, or base64 blobs.
• Size — any request whose payload is close to the file's size, or that grows with file size. Scan a 50 KB file and a 5 MB file and compare.
• Less obvious channels — WebSockets (check the Messages tab), sendBeacon calls, service-worker requests, and third-party analytics or session-replay scripts. Session-replay tools can capture what's rendered on screen, including scan results.
• Destinations — every domain contacted, not just the vendor's.

Loading scripts and stylesheets from the vendor's host is normal and does not mean your file was sent. But it does mean the vendor can change the code you run on any page load (see "What these tests cannot prove").

Test 2: Scan with the network cut off

Load the app, then cut the network at the operating-system level — disable Wi-Fi, unplug the cable, or block traffic with a firewall. The DevTools "Offline" toggle is weaker: it doesn't cover extensions or other processes.

If the scan still completes, the tested workflow can run without a connection. That is good evidence, not proof:

• The app may rely on files it cached earlier.
• It may queue data and send it when the network returns. Reconnect while still capturing traffic and watch what happens.
• It may fail safe or fail open. Note whether it scans, errors, or silently returns no findings — a scanner that reports "clean" when it can't reach a server is a serious problem.

If you need fully disconnected deployment, test the whole lifecycle on an isolated machine: install, license activation, first scan, and updates.

Test 3: Monitor traffic outside the browser

Browser tools cannot see desktop apps, CLIs, Office add-ins, or other processes. Use operating-system or network tools approved by your security team:

• Per-process firewalls such as Little Snitch (macOS) or Windows Defender Firewall rules show which process tries to connect where, and can block it.
• Packet capture with Wireshark shows every destination, DNS lookup, and transfer size.
• An intercepting proxy such as mitmproxy, with its certificate trusted on the test machine, lets you read encrypted request bodies and search them for canary strings. Some apps pin certificates and will refuse to connect; that is worth noting in itself.
• Hard isolation — run a CLI in a VM or container with networking disabled. If it works with no network interface at all, it cannot be uploading during that run.

Encryption hides content from passive capture. If you can't decrypt, rely on destinations, timing, and payload size compared with file size.

Test 4: Review the implementation

If source code or an architecture document is available, look for:

• Where parsing happens: in the local process, or in a remote API?
• Third-party libraries or hosted services that receive content (OCR, conversion, AI models).
• Temporary files, caches, and logs: what is written to disk, and is it cleaned up?
• Telemetry and crash reporting: what they collect and whether they're on by default.
• For browser extensions, the manifest's permissions. Broad host access such as <all_urls> lets an extension read and send data from any page.

Source review raises confidence but does not prove the build you run matches the code you read. For hosted web apps, the code can change between page loads.

Test 5: Test each integration separately

Vendors often ship several interfaces on one engine. Each has its own network behavior:

• Web app — must load from a server; the server controls what code runs.
• Browser extension — runs with extension permissions; inspect its background service worker separately (in Chrome, via the extension's "service worker" link on chrome://extensions).
• Office add-in — modern Office add-ins are web pages loaded from a URL in the add-in manifest, running inside Office. Treat them like a web app and monitor at the OS level.
• CLI — often the easiest to fully isolate.
• AI-agent integrations (MCP servers, plugins) — the scanner may run locally, but the AI assistant calling it may send the document, extracted text, or findings to a model provider. A local tool does not make the surrounding agent local. Check the AI provider's data handling separately.

A clean result for one integration says nothing about the others.

What these tests can and cannot prove

These tests show what one build did, in one environment, during the time you watched. They cannot show what the product will always do.

They can show:

• No canary string left the machine during the tested runs.
• Which destinations the app contacted and roughly how much it sent.
• Whether the tested workflow functions without a network.

They cannot show:

• Future behavior. An update, or a hosted page that serves new code, can change everything. Pin versions where you can and re-test after updates.
• Conditional behavior. Code can act differently for certain file types, file sizes, users, dates, or findings. Test the cases you actually use.
• Untested paths. Error handling, crash reporting, and rarely used features may behave differently from a normal scan.
• Intent. A vendor that wanted to hide transmission could make it harder to see. Testing raises the bar; it is not an audit.

For high-stakes deployments, the strongest controls don't rely on the vendor at all: run the tool on a machine or network segment that physically cannot reach the internet, or block it by policy and allow only what you've approved. Then a local-processing claim is enforced by your environment, not just stated by the vendor.

Write it down: a verification report

A result no one else can reproduce isn't worth much. Record:

Questions to ask any vendor

• Exactly what data leaves the device, for each integration? Can you show a list of every endpoint?
• Is telemetry, analytics, or crash reporting on by default, and what does it capture?
• Do any third-party services (CDNs, analytics, payment, AI models) receive data during scanning?
• Can the product run with no network at all, including install, licensing, and updates?
• How do we pin a version, and how will you notify us when network behavior changes?
• Has anyone outside your company tested these claims? Can we see the report?

A vendor that answers precisely and welcomes testing is more trustworthy than one with stronger marketing language.

How this applies to Strike Gate

Strike Gate is designed to parse and scan documents on your device. Here is what we expect you to see, so you can check it:

Like any request, the demo-counter calls reveal your IP address and the fact that a scan happened.

What we have not established:

• No independent audit. These are our statements about the current build. We have not commissioned a third-party review.
• The web demo loads code from our server. We could change it. Use the CLI or an isolated deployment if that matters to you.
• Each integration is different. Test the web app, extension, Office add-in, CLI, and MCP server separately.
• MCP use runs through your AI assistant. Strike Gate's scan is local, but the assistant that calls it may send findings or document text to its model provider.

Run the tests above on the exact build you plan to use. If you find traffic that doesn't match this table, tell us at <john@strikelabs.io>; we'll publish the correction.

Strike Gate flags patterns for human review. It does not make classification decisions or authorize handling. Follow your organization's approved procedures.

Tools and further reading

• Chrome DevTools: Network panel
• Wireshark
• mitmproxy
• Little Snitch
• Strike Gate local-scanning notes