Local first does not mean that nothing ever crosses the network. It means your server remains the authority: it holds the durable data and credentials, decides what each actor may do, and records the result. Data leaves that boundary only for a connection, model call, public endpoint, or publication you configured.
#What lives where
| Surface | What it may hold or receive | What it does not become |
|---|---|---|
| Your server | Warehouse records, provider credentials, installed recipes and packs, grants, audit, memory, and encrypted backups | A cloud-managed account or hosted copy |
| Paired webclient | A revocable client token and the data the server sends for display | The recipe engine, provider credential store, or audit authority |
| Paired Browser Bridge | A revocable client token and narrowly scoped browser commands | A general remote-control channel or durable warehouse |
| Recued cloud | Content you publish, optional account and billing state, and optional naming or certificate coordination | A relay for ordinary server traffic or a copy of your warehouse, credentials, and audit |
| A model or connected provider | The request and data needed for the call you chose to make | An implicit Recued authority |
Provider and model traffic goes directly from your server to that provider. Its own privacy and retention terms still apply. Recued's local boundary cannot undo data you deliberately send to another service.
#Encryption and recovery
The first successful pair enrolls the server's protected state under a 24-word recovery key. The running server normally unlocks with a key file in its data directory; the recovery key is the independent route back into the same protected state and is also required to open encrypted Recued archives.
What protects the key file itself is a choice made once, when that file is
created. The server uses RECUED_IDENTITY_PASSPHRASE if it is set, otherwise a
platform secret store that keeps its secret outside the data directory, and
otherwise nothing. The third case is a supported configuration, not a failure:
the warehouse is still encrypted, and stored material is still protected when
the database alone is copied, backed up, or snapshotted. What an unsealed key
file gives up is defence against capture of the entire directory, because the
key travels inside it. Containers land in that case by default; see
Install the server for how to seal one and what
changing the factor later costs.
Both recued auth-status and Settings → Server → Key Health report the
current factor, so the answer is always visible rather than assumed.
Keep the data directory, its key file, and the recovery key under different failure boundaries:
- restrict the data directory to the operating-system account that runs the server;
- keep the recovery key offline and away from that server;
- store encrypted archives somewhere that survives losing the server host;
- test that you can find the recovery key before you need a restore.
Anyone who controls an unlocked server process or its host can act with that server's authority. At-rest encryption protects stored material when the keys are unavailable; it is not a substitute for host security. Losing both the server key material and the recovery key makes protected state unrecoverable. See Backup and restore for the supported archive and restore paths.
#Network boundary
Loopback HTTP is suitable for same-machine setup. Use HTTPS whenever a browser connects over a LAN or the public internet: browser cryptography used by the webclient and pairing requires a secure context, and TLS protects the direct client-to-server path.
A public Recued name still resolves to your server. Recued may coordinate DNS and certificate issuance for the optional Pro path, but it does not proxy or decrypt the resulting traffic. Opening a public name also makes the listener an internet-facing service, so expose only the doors and endpoints you need. Read Reachability before opening ports.
#Authority, grants, and revocation
Possessing a URL is not authority. Every recipe, schedule, chat request, and external-agent call reaches the same server-side policy boundary. The server resolves the actor and installed capability, checks its grant and risk tier, requests approval where required, then writes the audit record.
Different access paths have different ways to close them:
- revoke a paired webclient or Browser Bridge from Devices;
- close an MCP, Reception, or messenger door to revoke its derived access;
- narrow or remove a pack grant without copying or re-enrolling its provider credential;
- delete or re-enroll a connection when the provider credential itself must change.
Recipes receive connection outputs and non-secret fields, not raw provider credentials. A pack's install disclosure is the moment to review the ceiling of what its recipes can request. The live call still has to pass policy; a manifest declaration alone does not grant access. See Grants and approvals.
#What an AI source sees
An AI source sees the prompt and context routed to that call. Known names, email addresses, phone numbers, and physical addresses can be replaced with typed aliases before the request leaves and restored locally afterward. That is targeted pseudonymization, not a promise that arbitrary prose or an attachment contains no identifying detail.
Choose a local model when data must stay on the host. For an external model, review the step's requested body or attachment access, the source you selected, and that provider's policy. Pause AI suspends background AI work; it does not revoke a provider key or erase requests already sent. Read AI and models for routing controls.
#Operator checklist
- Install signed releases or digest-pinned images, and keep the server current.
- Protect the persistent data directory and recovery key separately.
- Use HTTPS off loopback and expose only required inbound surfaces.
- Enroll provider connections with the smallest useful vendor permissions.
- Review pack contents, grants, audience, and model access before installing.
- Revoke devices and doors that are no longer in use.
- Keep encrypted archives and verify the recovery path.
- Use Runs and entity timelines to inspect what actually happened.
Security here is a set of visible boundaries, not a single switch. The server owns enforcement, but the host, connections, models, and public doors you choose still define the system around it.