Standing privacy modes

Most apps treat network access as one switch. You install the app, it asks for network permission once, and from then on anything inside it can reach the internet. The feature you wanted, the analytics SDK, the ad library, the module nobody has audited: they all sit behind the same granted permission.

For ordinary software that is already a weak model. For agent software it stops working entirely, because the modules doing the reaching may not exist yet when you grant permission.

We ran into this in Curated Thoughts, our agent-memory product, and shipped the first version of the answer in July 2026. We call it standing privacy modes. Instead of ruling on each request, the user picks one of three modes, once, and the mode governs everything the app does with the network.

Three modes, set once

Strict is the default. Inference, embeddings, storage: all of it happens on the device. There is no prompt to dismiss and no dialog to misread; the cloud configuration fields are simply not there. Nothing leaves the machine.

Ephemeral keeps storage and embeddings local but lets generation run through an external API. Before you enable it, the app shows you exactly what will be sent: the prompt and the retrieved chunks. The backend processes the request and keeps none of it.

Connected adds one more capability: a read-only query channel so your own agent can ask the vault questions on demand. Query results leave the machine when the agent asks. Nothing syncs, no copy of the brain lives on a server, and nothing can be written back over that channel. Leaving Connected deletes the pairing token.

Naming is consent

The naming took a revision. We originally labeled the third mode "Full cloud sync", and we renamed it, because the bridge does not sync anything. A label that promises synchronization gets users consenting to a mental model that does not match what the software does. "Connected" says what actually happens: the agent connects and asks.

Enforcement, not preference

Two design decisions carry most of the weight. First, the mode is enforcement, not a preference. It gates the app: in Strict, the cloud fields in the settings are hidden, not grayed out with an asterisk. A shield glyph in the status bar, filled, half, or outline, keeps the current posture visible at all times, because a privacy setting you forgot about protects no one. Second, moving between modes is honest about what it breaks. Downgrading a paired user to Strict surfaces a disclosure instead of silently dropping their connection, and re-enabling Connected requires pairing again from scratch.

We got the sequencing wrong at first, which is worth admitting. The cloud bridge shipped two releases before the mode gating did. For a while, the most sensitive capability in the product was the least governed one, and we closed that gap as soon as we saw it. The order should have been reversed, and App of Apps will not repeat it.

What App of Apps inherits

That last point matters because of where we are headed next. In Curated Thoughts, the modes govern the app's own features: the inference provider, the bridge. App of Apps generates bespoke tools while it works. A tool is created, used, maybe discarded, all within a session, so there is no feature list to gate and no component you can vouch for in advance. Every generated tool is untrusted by default. You also cannot put a human in the loop for every request. People stop reading permission dialogs somewhere around the third one; a prompt per background call trains the user to tap Allow, which is the same as having no prompt at all.

So the modes carry over, and one boundary gets sharper: the difference between a person handing data off and a tool doing it. When you tap the share sheet or open a file in another app, that is you, making a decision, and the OS handles it the way it always has. When a generated tool opens a connection on its own, that is the app acting without you. Tool-initiated connections need an explicit, revocable grant bound to one capability. Revoke it and that tool is blind. We are baking this into the foundation of App of Apps now, and it is more rigid and more expensive to build than an app where every module can dial home. We think the trade is right. An app that composes software dynamically runs unreviewed code, and containment is the baseline requirement for that, not a privacy feature bolted on at the end.

The problem we have not solved

There is one problem we have not solved. Ephemeral promises that nothing is retained, but when something breaks, logs are how you find out what broke. A backend that keeps nothing is a backend you cannot debug after the fact, and a backend that keeps "just enough" logging has already broken its own promise. Client-side diagnostics get you part of the way; they cannot tell you what the server did. For now we are treating it as an open design question rather than pretending the modes settle everything.

We will write more here as App of Apps takes shape, including how the grant system works in practice and where the isolation model fights us. If your software generates tools your users never reviewed, we would like to compare notes.