Your Documents Never Leave Your Computer: How docrew Works

The upload problem

Every major AI assistant asks you to do the same thing: upload your file. Drag a PDF into the chat window. Attach a document. Send it to the cloud.

The moment you click upload, your file copies to a server you don't control. It travels across the internet, lands on storage infrastructure managed by a third party, and gets processed by systems whose security practices you accept on faith. For a recipe or a travel itinerary, this is fine. For a client contract, medical record, or financial statement, it's a problem.

The upload model was designed for convenience, not security. It was built for consumer use cases where the user's main concern is speed, not data sovereignty. When professionals adopted these tools for real work, they inherited an architecture that was never designed for sensitive documents.

docrew takes a different approach. Your files never leave your computer. Here's exactly how that works.

The architecture, step by step

When you give docrew a task that involves files -- "analyze the contracts in this folder" or "extract data from these invoices" -- the following sequence happens:

Step 1: The agent reads files locally.

docrew's agent runtime is a compiled Rust binary running on your machine. When it needs to read a file, it calls a local file reader. For PDFs, it parses the document structure. For DOCX files, it unpacks the ZIP archive and reads the OOXML content. For XLSX files, it extracts cell values, shared strings, and formatting.

This happens entirely on your hardware. No network call, no server, no upload. The file read takes milliseconds -- as fast as your SSD can deliver data.

Step 2: Text is extracted from the file format.

Raw file formats are complex. A PDF contains fonts, images, layout information, metadata. A DOCX file is a ZIP archive containing XML, styles, relationships, media. An XLSX file has sheets, shared string tables, styles, formulas.

docrew's parsers strip away the format-specific complexity and extract the semantic content: the actual text, table structures, headings, and metadata that matter for analysis. The output is clean text that a language model can understand.

This extraction is the privacy boundary. The raw file -- with its embedded images, tracked changes, revision history, digital signatures, and metadata -- stays on your machine. What moves forward is only the textual content needed for the task.

Step 3: Extracted text goes to the language model.

The text content (not the file) is sent to the language model via docrew's proxy server. This is the only point where data leaves your machine. And what leaves is text -- not the original file format, not embedded images, not file metadata.

The language model processes the text and returns its analysis: extracted entities, summaries, comparisons, classifications, or whatever the task requires.

Step 4: Results return to your machine.

The model's response streams back to your desktop. The agent can then use these results to write new files, update spreadsheets, create reports, or continue with the next step of a multi-step workflow. All output files are written locally.

Step 5: Nothing persists remotely.

The language model API processes text in a transient context. There's no remote storage of your document content. The text was processed, the response was returned, and the processing context is discarded. Your files were never uploaded to begin with.

What this means in practice

The practical implications of this architecture affect every aspect of working with documents.

No upload limits. Cloud AI tools impose file size limits because uploads are expensive -- they cost bandwidth, storage, and processing time. When files are read locally, the only limit is your disk space. A 200-page contract processes the same way as a 2-page memo. A folder of 500 invoices is no harder than a folder of 5.

No upload wait. Reading a 50MB PDF from a local SSD takes less than a second. Uploading that same file on a 50 Mbps connection takes about 8 seconds. For batch processing -- reading 100 files, extracting data, comparing results -- the time savings multiply. What might take 15 minutes of upload time in a cloud tool takes seconds locally.

No format restrictions. Cloud AI tools support a limited set of file formats. Many can't handle DOCX styles, XLSX formulas, or PDF tables reliably through their upload interfaces. docrew's local parsers are purpose-built for each format. The DOCX parser understands paragraph styles, numbering, headers, and tracked changes. The XLSX parser handles shared strings, merged cells, and formula references. The PDF parser extracts text with positional information for table reconstruction.

No batch complexity. Cloud tools process files one at a time. You upload, wait, get results, upload the next one. Local processing is naturally parallel. The agent can read multiple files simultaneously, extract text in parallel, and send batch requests to the model. Processing a folder is a single operation, not a series of individual uploads.

The sandbox layer

File reading is half the story. The other half is execution.

When docrew's agent needs to process data -- not just read it, but transform it, calculate with it, or cross-reference it -- it writes code. Typically Python scripts that manipulate the extracted data, run calculations, generate reports.

This code runs inside an operating system-level sandbox. On macOS, that's Apple's Seatbelt framework. On Linux, it's bubblewrap (bwrap). These aren't virtual machines or containers -- they're syscall-level filters that restrict what the executed code can do.

Inside the sandbox:

• The code can read files in your project folder (the workspace you pointed the agent at)
• The code can write files to that same folder
• The code cannot access the internet
• The code cannot read files outside the project folder
• The code cannot modify system files or install software
• The code cannot access other applications' data

This means if the agent writes a Python script to parse your invoices and extract totals, that script runs in complete isolation. It can see the invoices (because they're in the project folder) and it can write the output (a spreadsheet of totals), but it can't phone home, exfiltrate data, or touch anything else on your system.

The network restriction is particularly important. Even if a malicious instruction somehow made it into the agent's workflow, the sandboxed code couldn't send your data anywhere. The sandbox is enforced at the operating system level -- it's not a software promise, it's a kernel-level restriction.

What the model sees vs what it doesn't

A common concern with any AI tool: "If text is sent to the language model, isn't that still exposing my data?"

Let's be precise about what the model receives and what it doesn't.

The model receives:

• Extracted text content from your documents
• Your task instructions ("compare these contracts," "extract all dates")
• Context from the current session (previous messages, task state)

The model does NOT receive:

• The raw file (PDF binary, DOCX archive, XLSX binary)
• File metadata (author, creation date, revision history, digital signatures)
• Embedded images, charts, or diagrams
• File system paths beyond the project folder
• Any files you haven't explicitly included in the task

The distinction matters for compliance. Many regulations care about "personal data" or "sensitive records." The raw file contains all of it -- metadata, embedded content, revision history. The extracted text is a subset: the words on the page, without the container.

This is also why docrew's approach is different from uploading a file to a cloud AI service. When you upload a PDF to ChatGPT, the entire file -- binary data, metadata, everything -- goes to OpenAI's servers. When docrew processes that same PDF, the file stays on your machine. Only the extracted text reaches the model.

The Rust runtime: why it matters

docrew's agent runtime is written in Rust, compiled directly into the desktop application. This is a deliberate architectural choice.

Rust compiles to native machine code. There's no interpreter, no virtual machine, no runtime environment that needs to be installed separately. The file parsers, the sandbox, the agent loop -- they're all compiled into a single binary that runs directly on your operating system.

This matters for several reasons:

Speed. Native code is fast. File parsing, text extraction, and sandbox management happen at the speed of compiled Rust, not interpreted Python or JavaScript. For batch operations on hundreds of files, the difference is measurable.

Security. Rust's memory safety guarantees prevent entire categories of vulnerabilities -- buffer overflows, use-after-free, data races. The file parsers that handle your documents are written in a language designed to prevent the security bugs that plague C/C++ parsers. This is especially relevant when parsing complex formats like PDF and OOXML, which have historically been vectors for security exploits.

No dependencies. There's no Node.js server to install, no Python environment to configure, no Docker container to manage. The agent is part of the application. Install the app, and the agent is ready. This reduces the attack surface -- fewer dependencies mean fewer potential vulnerabilities.

Verifying the claim

"Your documents never leave your computer" is a strong claim. How can you verify it?

Network monitoring. Use any network monitoring tool (Wireshark, Little Snitch, tcpdump) to observe docrew's network traffic. You'll see HTTPS requests to the language model API containing text content. You won't see file uploads. The request payloads contain extracted text, not binary file data.

Offline file processing. Disconnect from the internet. docrew can still read files, extract text, and prepare analysis. The only step that requires internet is the language model call. This proves the file processing is genuinely local.

Sandbox verification. On macOS, you can inspect the Seatbelt profile that docrew uses for sandboxed execution. It's a declarative policy that explicitly denies network access and restricts file access to the project folder. The restrictions are visible and auditable.

Open proxy architecture. docrew's proxy server handles authentication and model routing. It receives text content and forwards it to the language model. It does not receive or store files. The proxy's sole purpose is to manage API access and billing -- not to aggregate user data.

Why this architecture exists

docrew wasn't designed for privacy and then had AI bolted on. It was designed as a local-first AI agent, and privacy is a natural consequence of that architecture.

The agent needs fast file access -- so it reads locally. It needs to handle hundreds of files -- so there's no upload bottleneck. It needs to execute code safely -- so there's a sandbox. It needs to protect sensitive documents -- so raw files never leave the device.

Every architectural decision that makes the agent faster and more capable also makes it more private. Local file reading is faster than uploading. Local parsing handles more formats than web interfaces. Sandboxed execution is safer than remote code running. And keeping files on your machine eliminates an entire category of data exposure risks.

This isn't a trade-off between privacy and capability. It's an architecture where privacy and capability reinforce each other. The same design that keeps your documents private also makes them faster to process, easier to handle in bulk, and more reliable to work with.

Your files don't leave your computer because the architecture works better that way.