Security & privacy

Security architecture: a trusted first-party layer acts as a byte-courier that downloads and integrity-verifies packages, while all untrusted code runs in an isolated opaque-origin sandbox with no network and no access to keys, the page, or chrome APIs. — The trust boundary: the UI and every dependency run sandboxed; only a minimal first-party Host touches privilege, and it hands the sandbox only integrity-verified bytes.

The security model

Six principles, enforced in code — every claim below is implemented and tested.

🧪

Privilege separation

A minimal first-party Host owns chrome.*, storage and the network. The entire UI and every third-party library run in opaque-origin sandbox frames with none of those — reaching the Host only through a validated capability channel — and each LLM-generated artifact (HTML, React, Python) executes in its own fresh, throwaway frame.

🚫

The sandbox has no network

CSP connect-src 'self'; image/media/font sources are scoped (no *); WebRTC is nullified; forms and top-navigation are blocked. There is no channel to exfiltrate data.

📦

Integrity-checked packages

Need numpy or an npm library? A trusted courier downloads it and verifies its SHA-256 / SHA-512 before the sandbox ever sees it. The courier never executes package code.

🔐

Encrypted at rest

API keys and secrets are sealed with WebCrypto AES-GCM using a non-extractable key — the raw key never leaves the browser key store.

🧬

Prompt-injection defense

Hidden/invisible DOM is stripped before pages reach the model, planner prompts treat page content as untrusted data, and form submission always asks first.

🔗

Supply-chain hardening

npm ci sha512 integrity + npm audit gate in CI; vulnerable transitive chains are pinned out. No remotely-hosted executable code — runtimes ship from npm.

What that means in practice

Opaque-origin sandbox — untrusted code can't read your keys, the host page, or call extension APIs.
Byte-courier, not code-runner — the trusted layer downloads & verifies bytes; it never imports or evals them.
SHA-pinned dependencies — Python wheels and npm tarballs are verified against pinned hashes before use.
Guarded URL fetches — dependencies are requested by name, never a URL; when a feature does fetch a URL (an artifact's data source), an SSRF guard refuses private, loopback and cloud-metadata targets before the request is made.
Strict postMessage schema — the host accepts only a known, validated set of messages from the sandbox.
Sensitive sites excluded — banking, payment and brokerage domains are excluded from content-script injection.
Human checkpoints — approval is required before payments, submissions, and agent-initiated screenshots.
Never types into passwords — the agent skips password fields and pauses before destructive actions.
Zero-dep content scripts — page work uses native browser APIs only.
No cookies permission — chrome.cookies is unreachable by design.

Privacy by default

There is no Hyperion server. The developer never receives your data — see the full privacy policy.

Privacy data flow: your keys, chats, memory, tasks and sources stay on your device; only the prompt and context you choose are sent to the AI provider you select. No telemetry, tracking, data sale, or Hyperion server. — Your data stays local; only the prompt and context you choose reach the provider you pick.

🏠

Stays on your device

Credentials, chats, artifacts, agent history, memory and sources live in your browser (chrome.storage + IndexedDB). Export or wipe them anytime in Settings → Data.

📨

Sent only when you act

Your prompts and the context you provide go to the AI provider you choose (OpenAI, Claude, Copilot, GitHub Models). Optional tools (/wiki, /news, /stock, /github) call only when invoked.

🙅

Never

No analytics, telemetry, tracking or advertising. No selling or sharing your data. No transmission to any server operated by the developer.

Read our policies anytime.

Privacy Policy Terms of Service ← Back to Hyperion

Safe by architecture, private by default