Sentinel

Sentinel is on by default. It requires HTTPS for every external web request from the computer, keeps saved keys behind stand-ins, and applies your web permissions outside the computer.

Outside the computer

Sentinel is on by default. Your helper's computer is where it runs commands and code. Its HTTP and HTTPS requests go through Sentinel, which runs outside the computer, in 1Helm itself. Code on the computer cannot replace or disable that checkpoint.

Stand-in keys

When you save a key in Settings → Passwords & keys, the computer never gets the real thing. It only holds a stand-in (a placeholder that starts with 1hs_). When a request leaves for one of the sites that key is for, Sentinel swaps in the real key on the way out. Sent anywhere else, the stand-in stays a useless placeholder, so a stand-in that leaks reveals nothing. Real keys are stored encrypted, and only Sentinel can unlock them.

HTTPS only

Every external web request from your helper's computer must use HTTPS, including reads, downloads, scripts and browser background requests. Sentinel blocks a plain-HTTP request before it looks up a saved key, asks for approval or forwards anything. It does not silently upgrade the request: your helper must use the site's HTTPS address. A redirect from an HTTPS site back to HTTP is blocked too, including for storage downloads.

The computer's internal controller link is a runtime binding, not an internet destination. Separately, the hosted 1Helm app redirects HTTP page requests to HTTPS and rejects HTTP writes without replaying them. Your own AI service must also have an HTTPS address.

When a web request asks you

Reads, such as opening a page or downloading a file, can proceed automatically. So can permitted browser background requests, Git downloads and package-security checks. Other requests that send data, such as a submitted form or a script's upload, need approval unless your web permissions or an existing grant already cover them:

You see "OK to send this to (site)?", how much is being sent, and which saved key it uses. Nothing is sent until you choose.
It shows in the app, or by text if you're away and texting is set up.
Your choices: Allow once, Allow for this task, Always allow that site in this channel (after an "Are you sure?"), or Don't allow.
Your helper can't approve its own requests, can't answer the question for you, and doesn't route around it. A "Don't allow" is final.

The sites you've always allowed are listed in Settings → Permissions, each with Remove.

Knowing where answers came from

Sentinel keeps a log of which sites answered during each command. Your helper uses it to mark that output as coming from outside, so what a web page or a download says is treated as information, never as instructions.

What it doesn't cover

Sentinel applies web-request rules; it is not a guarantee that no data can leave through an allowed request. Direct SSH and managed Tailscale access have separate network permissions. A relay carried inside permitted HTTPS or WebSocket traffic is outside that direct-connection gate; Sentinel does not identify every protocol carried inside web traffic.

Sentinel guards the computer's own traffic (commands, scripts and downloads). Connected apps use a separate path: ordinary requested work runs directly, while payment and API-key operations retain protected confirm cards. Purchases through Link require your approval there.
Saved website passwords aren't stand-ins: 1Helm types them into the site's own sign-in page, and your helper never sees them. See Saved logins.