Local-First Is a Control System

OpenHuman’s privacy and autonomy features answer two different questions: where may information go, and what may the agent do? This chapter separates those axes and follows them through approvals, path and sandbox boundaries, local-only inference, external-transfer checks, model routing, and recoverable compression. The practical result is a more precise judgment than either “the assistant is private” or “the assistant is autonomous”: each claim depends on a particular control point.

Two kinds of permission

A model can be allowed to reason locally and still be allowed to send an email. It can be prevented from using a cloud model and still be unable to write to a protected application directory. Privacy and autonomy overlap, but neither subsumes the other.

OpenHuman’s policy model treats autonomy as act-power. Current policy types distinguish read-only, supervised, and full modes, and classify operations into broad command classes such as read, write, network, install, and destructive. A command that is not provably read-only is treated conservatively. The agent may be able to describe a shell command, but the policy decides whether that command is allowed, requires approval, or is blocked before execution.

Privacy Mode treats data egress. In local-only mode, the Rust provider factory refuses to construct an external inference provider. The important word is “construct.” The system is not relying on the model to remember a privacy instruction after it has already received a client. It prevents the cloud provider from becoming an available inference path for that session. Local runtimes such as Ollama, LM Studio, MLX, or local OpenAI-compatible endpoints can remain eligible.

These controls answer different failure scenarios. If a supervised agent wants to modify a file, autonomy policy can pause it for approval even when the model is running locally. If a fully autonomous agent is configured to use a cloud model, local-only privacy mode can block provider construction even though the action policy would otherwise allow the turn. A user can therefore choose a high-action local assistant or a low-action cloud assistant; the two settings should not be collapsed into one slider.

flowchart LR Q[Agent request] --> P{Privacy and egress path} P -->|local-only provider| L[Local inference] P -->|external user-data transfer| X[Egress check] X -->|blocked| B[Policy result] X -->|permitted or control-plane| C[External service] Q --> A{Autonomy and command class} A -->|read| R[Run or observe] A -->|write/network/install/destructive| G[Approval or block] G -->|approved and bounded| S[Sandboxed side effect] G -->|denied or expired| D[Fail closed] L --> M[Compressed tool context] C --> M M --> H[Recoverable original when needed]

The paths can intersect. A cloud inference call may pass the privacy check in standard mode but still be subject to tool and approval policy. A local model may pass the egress check but still be blocked from an unsafe filesystem action. The diagram’s point is not to suggest that every path is always available; it is to show that the system evaluates different kinds of permission at different boundaries.