# 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.

Section: Trust

## 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](https://1helm.com/docs/billing/byok/) 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](https://1helm.com/docs/approvals/#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](https://1helm.com/docs/computer/#saved-logins).

---
Web page: https://1helm.com/docs/security/sentinel/