How to use AI without exposing your private data.
Qwen Code plus a model on your machine can still let credentials, source code, tools, logs, and child processes reach the internet. This report shows how to contain the whole session on macOS, Windows, or Linux.
You receive a licensed PDF specification and a ready-to-paste coding-agent brief for every selected edition. Your coding agent builds the boundary. You verify it on the target machine. Source patches, binaries, model weights, credentials, and preconfigured system policy are not included.
Do not confuse convenience with containment.
Privacy is a workflow decision, not a single switch. Choose how much automation and network-capable tooling a session actually needs.
Automatic approval never substitutes for process, file, credential, broker, and cleanup controls.
Manual approval, local tools only
Local shell, editing, builds, tests, and local MCP. No external browser or remote-data broker.
Reviewed exceptions
Manual by default, with named browser or service brokers, per-session credentials, isolated profiles, and cleanup.
Automatic approval, boundary intact
Use only with a trusted repository, narrow write paths, scrubbed credentials, and independently tested brokers.
One misled agent, one bad dependency, one loose tool.
Without a real boundary, the coding session can act with everything the signed-in account owns. This is what “just run it locally” quietly leaves exposed.
A private repository does not prevent credential theft, source movement, harmful commits, or hidden changes.
SSH keys, tokens, cloud logins
Child processes can inherit saved credentials and send them through any tool with a network path.
Repositories, documents, build output
Private material can move through prompts, logs, terminal output, browser requests, or compromised install scripts.
Commits, pushes, releases
Saved GitHub or cloud access can enable harmful pushes, file changes, or malicious edits hidden in dependencies and builds.
Local inference is one layer. The session has five.
Each layer protects something different. A local model alone does not control the agent, its shell, inherited credentials, connected tools, or operating-system boundary.
Approval mode is a human checkpoint. It is not a network, process, or filesystem boundary.
Keeps inference on the machine
It does not control the coding agent, shell, plug-ins, browsers, or update services.
Limits who can retrieve code
It does not review every dependency, instruction file, hook, extension, or saved credential inside the workspace.
Controls when a human confirms
Automatic or manual approval changes action timing. Neither one creates containment by itself.
The paths out are not where most teams look.
Even with a local model, these routes remain open until each one is closed as its own control.
Normal developer convenience can carry prompts, source, credentials, and session data outside the machine.
Usage events, prompts, request bodies
Product reporting, chat records, and debug logs can persist or transmit prompts and replies unless recording is refused.
Cloud keys, proxies, provider presets
Child processes normally inherit API keys, cloud credentials, proxy settings, and provider URLs from the developer shell.
Browsers, remote MCP, updates
Legitimate tools and maintenance paths need narrow, authenticated, session-owned routes of their own.
One authenticated model route. One contained process tree. One clean exit.
The report treats Qwen Code, the model host, tools, credentials, logs, and the operating-system boundary as one system with named parts.
Qwen Code inside a platform boundary
Manual approval by default, filtered child environment, no ambient cloud fallback, and interactive shell capability preserved.
Loopback proxy to the model host
Random session port and token, exact destination, exact approved API path, and rejection of every other route.
Brokered browser and remote tools
Reviewed capabilities get separate routes, credentials, temporary profiles, and shutdown cleanup.
A specification and a ready-to-paste coding-agent brief. Not a prebuilt product.
Your coding agent writes the gatekeeper proxy, platform launcher or supervisor, containment profile, and tests. You approve every privileged step.
You start with a bounded implementation plan and verification criteria instead of designing the boundary from scratch.
One per selected edition
macOS, Windows, and Linux are separate line items and separate PDFs, each licensed per named user.
Proxy, launcher, and tests
A bounded prompt asks your coding agent to create the authenticated proxy, platform launcher or supervisor, containment profile or policy, focused tests, and a changed-file summary.
Positive, negative, and shutdown checks
Capability, route, listener, process-ownership, PTY, and cleanup checks are rerun on the target machine.
Buy the boundary for the machine you will actually protect.
Each edition uses the same local-only model, tool, credential, and verification principles. The implementation changes where the operating system can enforce the boundary.
Seatbelt and Apple Silicon
MLX or GGUF model paths, the macOS launcher, working pseudo-terminals, Seatbelt containment, and Mac-specific verification.
ConPTY and Job Objects
Q8_0 GGUF, PowerShell or service supervision, ConPTY support, protected session files, and program-scoped Windows network controls.
PTY and cgroups
Q8_0 GGUF, systemd or another supervisor, PTY/devpts support, cgroups or namespaces, and Linux network controls.
Choose one edition for each operating system you need to protect. Each selected edition is a separate report and purchase line item, delivered as its own licensed PDF.
A private session needs a controlled start and a clean stop.
The launcher, host, proxy, tools, browser profile, temporary directory, and cleanup act as one workflow every session.
Choose the host
Select standard Ollama, LM Studio, or source-hardened Ollama and record the exact version.
Choose the profile
Use strict private, controlled tools, or trusted automation with manual approval as the baseline.
Start the boundary
Launch the authenticated proxy, filtered environment, platform-native process boundary, and approved tools together.
Verify before private code
Run capability, negative-route, listener, process, and cleanup checks.
Stop and record
Shut down the process group, brokers, browser, and session directory, then record the result.
Designed for developers comfortable with terminal or PowerShell commands. Plan for an implementation session of one to several hours depending on your environment, then repeat verification after software updates.
Containment reduces identified paths. It does not replace verification on your machine.
The report separates focused evidence from the checks every buyer must repeat after assembly, updates, and platform changes.
No written specification can prove how every future agent, model host, helper, or operating-system release will behave.
Focused categories of checks
Local routing, proxy, process ownership, platform-boundary, PTY, negative-route, and cleanup checks are documented as evidence categories.
Verify on the target machine
Recheck the exact host, helpers, logs, model, operating-system policy, and shutdown behavior on the buyer's machine.
Model hosts remain separate boundaries
Ollama, LM Studio, native runtimes, and helper processes remain separate trust boundaries that the selected edition asks the buyer to verify.
Make local coding a verifiable boundary.
Select macOS, Windows, Linux, or any combination on the purchase page. Each selected edition is a separate report line item and a separate licensed PDF for every named user.
Local model. Contained session. Verified on your machine.
Turn a local model into a controlled system.
Select the platform editions you need, see the per-edition and named-user totals, accept the purchase terms, and continue to checkout.
- Ready-to-paste coding-agent implementation prompt
- Ollama and LM Studio host paths
- Positive, negative, and shutdown verification checks
- Per-edition PDFs licensed per named user