Privacy and sandboxing for verifiable AI workflows

Privacy, sandboxing, and verifiable AI development

When AI enters a real engineering environment, privacy is not a single question of whether code is uploaded. It is a system of constraints on data residency, inference routes, tool authority, network egress, third-party extensions, audit evidence, and reversible change. This research note describes a local-first architecture that makes those constraints executable and testable. It uses RFC 2119-style language for control goals; it does not replace an organization’s threat model, compliance assessment, or certification.

1. Privacy is an architecture

An intelligent development tool can encounter far more than the lines visible in an editor: project structure, dependency relationships, Git history, failing tests, terminal output, design documents, credential paths, and external resources can all be combined into a task. Risk usually emerges from their unexpected combination across processing stages, not from one feature in isolation.

We define the customer control domain as the local device, internal network, VPC, private inference service, and self-hosted gateway that the customer administers. That definition does not imply those environments are automatically safe. It makes responsibility explicit: the goal is to keep default data flow inside a controllable domain and require every cross-domain action to have a clear precondition, minimum scope, and auditable trace.

2. Interactive privacy paths

The following model distinguishes local control and permitted outbound paths for different operating modes. The visual encoding is explanatory rather than a measurement of data volume. Its purpose is to make an important question reviewable: which assets may leave, under which conditions, and who can observe the action?

3. From asset classification to sandbox execution

Source code, Git-tracked files, semantic indexes, worktrees, prompts, model responses, and telemetry are not one kind of asset. An index may reconstruct symbols, call relations, and business meaning even when it is not a source file; a temporary worktree can contain unreviewed patches; a short prompt can combine a path, code, error, and organizational terminology. Governance begins by assigning each asset a default sensitivity, residence, permitted processors, and observable deletion path.

A lock icon is not a trust boundary. Effective boundaries operate at four layers: operating-system processes, the agent tool sandbox, command and network sub-policies, and delegated capabilities for third-party Skills or MCP servers. Permissions must narrow as execution moves deeper. An extension triggered by an agent must not gain broader file, command, or network access than its host.

The local semantic index exists to understand a project, not to compress an entire repository for upload. It builds relationships among symbols, types, references, calls, tests, and documentation on-device, then selects the smallest sufficient evidence for the task. Standard mode does not promise zero egress; it promises local retrieval and minimization before egress, preserving why each selected piece of context was included.

4. Modes, extensions, isolation, and audit

High Privacy mode fits sessions where code, indexes, context, and inference must remain on-device or inside a customer network. Standard mode fits daily work with an approved inference service while repositories and indexes remain local by default. Enterprise self-hosted mode concentrates cross-network trust in a customer-operated gateway. These are different control domains and responsibility allocations, not a ranking from unsafe to safe.

Restricting model egress alone is insufficient. An agent that can read an external secret directory, execute unrestricted commands, or permit an MCP server to connect directly to the internet can bypass the intended control domain. Workspace read/write scope, sensitive-directory allowlists, project deny globs, fixed working directories, subprocess limits, and destination allowlists need to work together. High Privacy sessions should default command networking to deny; necessary internal services should be opened through specific, reviewable rules.

Skills and MCP servers should receive delegated capabilities, not ambient authority. Their file, network, command, and resource permissions cannot exceed the owning agent’s sandbox. High-impact writes bind authorization to a target, scope, and lifetime rather than to one permanent “always allow.” Parallel worktrees provide a complementary reversible boundary: they make changes comparable, rejectable, and discardable before they return to the main branch, but do not replace process, credential, or network isolation.

Telemetry must also be minimized. Fields containing code fragments, paths, prompts, or responses are off by default. Audit exists to answer whether an outbound request, command, or write followed policy—not to collect more content. Policy requires versioning, explicit owners, reviewable exceptions, expiry, and a rollback path.

5. Team verification checklist

Before deployment, run a black-box High Privacy check: block public egress and confirm that local models, indexing, and core editing still work; attempt to read sensitive files and execute outbound commands and verify a clear denial; inspect the residence of indexes, temporary worktrees, and behavioral summaries; enable a restricted MCP and confirm that it cannot bypass host network rules. In Standard mode, verify that retrieval is local before a request and that only task-relevant fragments enter the prompt. In Enterprise mode, verify that clients connect only to the customer gateway, identity and certificates are checkable, and gateway records reconcile with client-side behavior summaries.

These checks do not replace penetration testing and cannot prove the absence of unknown defects. They turn the most important promises into acceptance tests that can be repeated after every release, policy change, or extension integration.

6. Conclusion

Privacy-first AI tools should not force a choice between capability and control. A durable design builds project understanding locally, minimizes any cross-domain inference context, constrains tools with sandbox and network policy, makes parallel edits reversible in worktrees, and lets users verify the critical invariants themselves. That is what allows an intelligent system to remain useful inside real organizational boundaries, responsibilities, and trust structures.