Security and trust

jawb's caller is an AI agent that reads untrusted web pages and can be steered by what it reads. So jawb's security starts from one question: who is trusted to do what? This page answers it, then separates what is built today from what is planned.

Threat model

Malware running as your user with UI-automation rights, and an administrator or kernel compromise, are out of scope for any local tool, jawb included.

One gap is open on macOS and Linux. On Windows, jawbd asks Windows Hello to verify you before a purchase proceeds, and a program that only reads jawb's files cannot produce that verification. macOS and Linux have no verifier yet: approvals there come from a terminal prompt backed by a credential file in the data directory, and are recorded as asserted. Any program running as you can read that file and approve, so on those systems jawb does not meet this model for purchases yet (see Planned).

Built today

• A local daemon only you can reach. jawbd listens on loopback only, with no remote mode. Every /v1 call except the health check needs a bearer token from the data directory, requests that carry a browser Origin header are refused, and the CLI refuses daemon addresses that are not canonical loopback.
• An owner-only data directory. Profiles, tokens and keys live in a directory only your user can read, written in a crash-safe way, with one daemon per directory.
• Encrypted profiles. Cookies and storage are encrypted at rest with a per-profile key held by the OS key store, or by a keyfile you supply on hosts without one. Encryption protects against other users and offline theft of the disk. It does not protect against your agent, which acts with your profile.
• Incognito sessions. Their state lives in memory. A download you ask for in incognito is deleted when the session ends, and any left behind by a crash are removed the next time the daemon starts.
• A confirmation policy. Uploads, downloads of executable or unknown file types, filling a password or card field, and submitting a form that has one need a confirmation. Every policy decision is written to jawb trace.
• A purchase hold. Purchase-like actions are held as a pending confirmation, and no approval token is ever issued to the agent that triggered them. --yes never satisfies the hold, and no flag does. A person approves through one of the approval channels, in this order by default: the jawb desktop app (in development), the operating system's own verification prompt that jawbd raises itself (Windows Hello today), and the terminal, by typing purchase at jawb confirm. An approval from the terminal still asks Windows Hello where it is available. Each approval is bound to the exact request you were shown, runs exactly one held action, and expires (120 seconds by default). Every approval is recorded with how it was made: verified when the operating system verified you, asserted when jawb could not check. Pages opened in jawb can never reach jawbd's own control port. jawb holds purchase-like actions at three layers, plus a fourth by default:
  1. A classifier, before the action runs. It matches purchase words in several languages ("Place your order", "Buy now", "Subscribe") on the control being activated, payment fields, and forms that submit to a checkout step. Enter, Space and typed newlines are classified like the click they trigger.
  2. A marker on purchase-like submissions, checked at the network layer. A marked request fails unless the action carries a human-approved token.
  3. An effect-level hold. While an agent action runs, and for 3 seconds after it ends, any state-changing request to a checkout-like path, or one that carries a payment card number, is held, however the page built it.
  4. A payment-context hold, in the default strict detection mode. On a page with a payment field, a frame from a known payment provider, or a checkout path, every state-changing request from that tab is held while an agent action runs and refused otherwise, for 30 minutes after the last payment signal.
  
  What it does not cover: WebSocket handshakes, in either mode; a page with no payment signals at all, such as a one-click button on an otherwise neutral page; requests sent more than 3 seconds after the action when no payment context exists; and a page that deliberately disguises a purchase. On macOS and Linux a program running as you can still approve (see the gap above). The hold is a safeguard for honest checkout flows, not a guarantee against a hostile page.
• A configurable gate with a floor. config.toml in the data directory sets purchase.gate (approve by default, deny to refuse every purchase, allow to let them run with a warning) and purchase.detection (strict by default, or standard), globally or per profile, with jawb config from jawb 0.1.1. A value weaker than the default takes effect only after a person approves it through the same channels, and that approval lasts until the daemon exits, so an agent that edits the file and restarts jawbd does not switch the gate off.
• Bridge helpers in an isolated world. jawb's helper scripts inside Chrome run apart from the page's own JavaScript, so a page cannot remap the element ids an agent targets or forge the facts a click relies on. Certificate errors fail navigation.
• No cloud-metadata access. Link-local and cloud-metadata addresses are always refused, including after a redirect or a DNS answer that points there. No flag allows them.

Planned

• Content-integrity guardrails. jawb will hand the agent what a person reading the page would see, and flag what they would not: CSS-hidden, off-screen, zero-size or same-colour text; zero-width and bidirectional Unicode tricks; and instructions hidden in tool descriptions. Hidden content is dropped from the default observation, or kept and marked with the reason it is hidden, so you can still inspect it. Every piece of page content will carry where it came from (page, frame, declared tool) and an untrusted label, kept structurally apart from jawb's own messages. This is in research now.
• A local-network rule. Opening localhost or a LAN address yourself stays allowed with no flag, because local automation and UAT testing against dev servers are primary uses of jawb. A public page that redirects or sends requests into your local network will be blocked unless you allow it for a profile or a command.
• Encrypted per-session downloads. Downloads encrypted with a key that lives only in memory for the session, so even a crash or a hard kill leaves only unreadable files.
• OS-verified purchase approval on macOS and Linux, which closes the open gap in the threat model there, and the jawb desktop app as an approval channel.
• One gate for every route. When declared-tool invocation and native actions arrive, they go through the same purchase and policy checks as a click. A cheaper route is never a weaker one.
• Account sign-in. Everyone will sign in with a jawb account (Firebase Authentication). Sign-in and licence refresh send your account identity, never URLs, page content, history or traces. The daemon checks your licence locally, and a signed-out or offline install keeps browsing during a grace period.

What jawb does and does not claim

jawb aims to reduce an agent's exposure to hidden prompt injection, and to contain its consequences, so that injected instructions cannot spend money or move data without you. It does not prevent prompt injection. The model still decides what to do with what it reads, and it can be misled by text that is plainly visible.

These protections are part of the free product. Safety is never a paid feature.

See Roadmap and status for everything else that is built and planned.