Where autonomy stops: deployment, tools, and trust
Paperclip's budgets, approvals, and audit records govern work inside a chosen control boundary. This chapter examines what changes when that boundary is exposed to a wider network, hostile input, or external tools. The practical judgment is whether a run is merely visible or actually constrained: who can reach the instance, what a low-trust agent may touch, which tools it can see, and whether a particular call is allowed now.
The same company and heartbeat model can operate on a developer's machine, across a private network, or behind a public deployment. The organizational objects do not need to change, but the assumptions around identity, reachability, credentials, workspaces, and external side effects do. Trust is therefore not a single setting attached to an agent. It is a set of boundaries around a run.
Reachability changes the trust posture
Paperclip separates authentication from binding and reachability. Its low-friction local_trusted mode assumes a local, loopback-oriented deployment with no human login. The authenticated mode supports private exposure, such as a LAN, VPN, or tailnet, and public exposure for an internet-facing or hosted deployment. The server can also bind to different interfaces independently of which authentication model is active.
That separation prevents a common mistake: treating “login disabled” and “publicly reachable” as opposite ends of one slider. Local trusted mode is low friction because the operator is expected to trust the host and the local boundary. Authenticated private mode adds identity while preserving a private-network assumption. Authenticated public mode requires stricter URL and deployment checks, enables stronger default rate limiting, and applies additional restrictions to local runtime mechanisms.
The control-plane model remains recognizable across these modes. Companies, tasks, agents, runs, and activity still use the same kind of durable records, and local development can use embedded PostgreSQL while a hosted deployment uses PostgreSQL elsewhere. What changes is the set of actors and environments that may reach those records and the runtime services that may be started on their behalf.
A public deployment therefore cannot be treated as a local instance with a wider network address. It needs a real human-authentication path, an explicit public origin, rate-limit assumptions, and a deliberate decision about where local child processes are allowed to run. The deployment guide makes local stdio fail closed for public exposure unless a trusted runtime host is explicitly designated. This is a trust decision, not a missing convenience feature: a public API edge should not casually become the host for arbitrary local process execution.
The benefit of keeping one control-plane model across modes is continuity of the operator's mental model. The cost is that the model must carry its trust assumptions explicitly. A deployment that changes reachability without changing those assumptions has changed the threat surface while leaving the policy unchanged.
The difference becomes concrete when the same agent is moved between environments. On a trusted laptop, the operator may accept a local process adapter and a loopback server because the host, credentials, and runtime are under one person's control.