Yes. And you don't have to take our word for it.

Most AI privacy claims are promises. "We don't store your data." "Privacy Mode is enabled by default." "We're SOC2 certified." These are statements about what a company says it does with your data after it arrives on their servers. They require trust. They can't be independently verified by the person asking the question.

ToolPiper's local features are different. The audio for voice dictation, the text in your chat, the documents in your RAG index, the images you process - none of it travels over the network. That's not a privacy policy statement. It's an architectural fact. And you can confirm it yourself.

What does "local inference" actually mean?

Local inference means the AI model runs directly on your Mac's hardware - its Neural Engine, Metal GPU, and unified memory. Your input goes from your device to the model in local memory, and the output comes back the same way. No network request is made. Your prompts, files, and inference stay on your machine.

When you hold Right Option and dictate in ToolPiper, the audio travels from your microphone to Parakeet v3 running on your Mac's Neural Engine. The transcription happens in local memory. The result pastes into your app. The audio never left the device. When you type a message to a local LLM, that text goes to llama.cpp running on your Metal GPU. The response generates in local memory. Same principle.

This is what makes the privacy claim verifiable. The processing happens on hardware you own. The network path doesn't exist.

How do you verify it yourself?

Open Activity Monitor while ToolPiper is running. Click the Network tab. Start a voice dictation session, send a chat message to a local model, run an OCR scan. Watch the network column for ToolPiper's process.

You won't see an upload that tracks your work. A dictation, chat message or OCR scan adds no request of its own; any ToolPiper traffic you do see is a small update, license or activity request, and none of them carries your content.

For a more complete picture, run Little Snitch or any firewall that logs outbound connections. Block ToolPiper's network access entirely, then use every local feature. Dictation works. Chat works. RAG works. OCR works. Voice chat works. None of these features require a network connection because none of them use one.

That test is the answer to the question. Not a policy. Not a certification. A verifiable result.

What does ToolPiper send over the network?

A short list, and none of it carries your content. We'll be specific.

Account authentication. When you sign in, ToolPiper sends your email address to request a one-time code. When you enter the code, it's verified server-side. While you are signed in, ToolPiper checks your license with our server about every six hours. That check identifies your account and this Mac's device record, and we keep the device's most recent IP address and check time. None of these requests contain your AI content - no prompts, no audio, no documents.

Model downloads. When you download a model from the model browser, ToolPiper fetches the GGUF file from HuggingFace. You initiate this explicitly by clicking Download. After the model is on your device, no further network activity occurs for that model. It runs entirely locally from that point on.

Cloud provider API calls, if you configure them. ToolPiper supports connecting to external providers - OpenAI, Anthropic, Groq, Mistral, and others. If you configure one and use it, your messages go to that provider's servers. This is expected and transparent: you configured the connection, you know the provider, you know where the data goes. ToolPiper's local proxy adds your key from the macOS Keychain and sends the request from your Mac straight to the provider you chose, not through ModelPiper servers.

Three more complete the list. Update checks: ToolPiper asks releases.modelpiper.com for updates at launch and about every six hours. A daily activity check-in (days used, app build, release channel), on by default with its own stop switch in Settings > Activity; signed out it carries no account or device identifier, and we keep only aggregate totals for 400 days. Optional usage counts (which MCP tools are used, and paid-feature refusals) sent to PostHog, on by default and off in Settings > Analytics. None of these includes your prompts, audio, files or outputs. The ModelPiper interface bundled inside ToolPiper - the same web app that runs at modelpiper.com - is served locally from your machine when running through ToolPiper. It does not send analytics calls anywhere when running locally. Usage reporting is limited to the daily activity count and the optional usage counts above.

If you're using local models and haven't added a cloud provider, ToolPiper's outbound traffic is update checks, sign-in and license checks, the daily activity count, optional usage counts and any model downloads you start. None of it carries your content.

How is local access secured?

"Runs locally" raises a fair follow-up: if ToolPiper is exposing tools to clients like Claude Code or Cursor, what stops something else on the network from reaching in? The short answer is that the trust boundary is the loopback interface, and everything beyond it is gated by a bearer token.

Local clients connect with zero config. When ToolPiper launches, it mints a short-lived ambient bearer token to ~/Library/Application Support/ToolPiper/.toolpiper-token (file mode 0600, rotated on every launch) and trusts loopback connections at the socket level. A tool client on the same machine just works - there's no key to copy into a config file, and no token is written into ~/.claude/ or any client config you don't control.

Off-machine access is scoped and explicit. Anything that isn't loopback - a LAN device, or a PiperMesh peer - has to present a scoped Bearer tp_<64 hex> token with the correct audience. Those tokens are 64 hex characters of cryptographically random entropy. No token, no access; wrong audience, no access. This is the same observable model as the rest of the article: you can watch the connections and see exactly who is authenticated.

You can see and revoke every client. The Connected Apps pane inside ToolPiper lists each authenticated client as a row you can label, inspect (including its MCP-tools access state), and revoke in a single click. Revoking kills the bearer immediately, and the row stays visible as revoked - state is never hidden from you.

You can narrow what any client may do. A tool governance overlay lets you deny specific tools - for example system_run_command - for every connected client, or flip the built-in tool marketplace from open browse to an explicit allow-list of servers and tools. To be precise about scope: this is a per-device, locally-edited overlay available today, and it can only narrow what your tier already permits, never widen it. It is not an enterprise SSO or admin-console product yet. The policy is built in the same shape so an organization could push it down the road, at which point the controls would lock with a "Managed by your organization" badge - but that's the planned direction, not something shipping today. Allow/block tool governance is here now, per device; org-managed push is coming.

Why can't cloud AI products answer the same question?

Cloud AI products process your data on remote servers, which means your input must travel over the network to be processed. There is no way for a user to audit what happens to their data during that transit or on those servers. Privacy policies and certifications govern what the company says it does with data - they cannot be independently verified by the user.

This is a structural limitation, not a criticism of any specific company. When you ask a cloud voice app "can I verify that my audio is private," the honest answer is no. You can read their privacy policy. You can see that they have a privacy setting. You can check their compliance certifications. But you cannot inspect their servers, you cannot monitor what happens to your audio during processing, and you cannot verify that traffic under that setting follows a different path than standard traffic.

The Wispr Flow episode in 2025 illustrates what happens when users look closely. Users monitored their network traffic and publicly questioned what the dictation app sent to its cloud. Wispr's data controls have changed since: a setting called "Improve the model for everyone" (formerly Privacy Mode) decides whether your audio, transcripts and edits may train its models, a separate setting decides whether your history is stored on its servers, and Enterprise plans have model training locked off. Those are real controls. But here's the question no setting answers: how would you know if your audio were handled differently from what the setting says? From outside the provider's infrastructure, you can't. Full analysis: Wispr Flow's Privacy Incident.

The same question applies to every cloud AI product. It's not a policy problem. It's a verification problem. The processing happens on infrastructure you can't see.

What about when you use cloud providers through ToolPiper?

If you connect OpenAI or Anthropic and use them through ModelPiper, your messages go to those providers exactly as they would from any other app. The request goes from your Mac directly to the provider's API; it never passes through ModelPiper servers.

The privacy question for those interactions is then the same as using those providers directly. Read OpenAI's data usage policy if you're sending OpenAI API calls. Read Anthropic's if you're using Claude. ToolPiper's local architecture doesn't change what those providers do with your data - and we don't claim otherwise.

The point isn't that cloud providers are bad. It's that local and cloud are different trust models. Local: you verify it yourself. Cloud: you trust the provider. Knowing which you're using at any moment is what matters.

Is ToolPiper open source?

The MCP server specification and shared tooling are open. The core macOS application is not currently open source. We know that for some users, open source is the only fully satisfying answer to "how do I verify this." Fair point. The network traffic verification above is the practical substitute for most people - it doesn't require reading source code, and it tests the actual runtime behavior rather than the stated implementation.

We're considering a public build of ToolPiper's inference server components. If that changes, it'll be documented at modelpiper.com.

The short answer

Local features stay local. You can verify that yourself in five minutes with Activity Monitor. ToolPiper's own traffic is limited to update checks, license checks when signed in, a daily activity count and optional usage counts, none of which carry your content. Beyond that it connects only for model downloads you start and cloud providers you add.

Everything else - voice, chat, RAG, OCR, vision, image upscale, video upscale - runs on your Mac. No policy required. No trust required. Just observable architecture.

Download ToolPiper at modelpiper.com and run the Activity Monitor test yourself.

Related: Wispr Flow's Privacy Incident - what users raised about cloud voice AI and what changed. ToolPiper vs Wispr Flow - full comparison. Voice Chat with Local AI - how the on-device pipeline works.