Back to Helen

Security and threat model.

Architecture in one diagram

        ┌──────────────┐                  ┌──────────────┐
        │   Visitor    │  HTTPS / SSE     │  helen-api   │
        │  (browser)   │ ───────────────▶ │  (FastAPI)   │
        │              │  creds + Q       │              │
        │  Web Crypto  │                  │  no DB       │
        │  AES-GCM key │                  │  no logging  │
        │  in memory   │ ◀─────────────── │  of body     │
        └──────────────┘   trace events   └──────┬───────┘
                                                 │
                                                 │  direct HTTPS
                                                 ▼
                                          ┌──────────────┐
                                          │  Your SIEM   │
                                          │  (Splunk,    │
                                          │   Sentinel,  │
                                          │   Wiz, …)    │
                                          └──────────────┘

What is in scope

  • Confidentiality of your SIEM credentials in transit and in browser memory.
  • Confidentiality of your prompts and Helen’s answers.
  • Integrity of the trace events we surface to you.
  • Honest TLS posture from the public helen.joon.co edge.

What is explicitly out of scope

  • Authentication of you. There is no account; we don’t know who you are.
  • Tamper-resistance against the LLM provider seeing your prompts at runtime. Helen forwards your question and tool-call results to OpenAI / Anthropic per request. Their data-retention terms apply.
  • Protection from somebody with shell access to your machine. Anyone who can read your tab’s memory can read your credentials.

Specific controls

Browser side

  • AES-GCM 256-bit per-tab key, non-extractable, generated by Web Crypto.
  • Ciphertext lives only in sessionStorage; cleared on tab close.
  • Strict CSP: no inline scripts loaded from third parties; connect-src is self plus optional Sentry.
  • HSTS, X-Frame-Options DENY, Referrer-Policy strict-origin-when-cross-origin.
  • No cookies. No localStorage entries except the consent record.

Server side

  • Stateless FastAPI service. No Postgres, no Redis on the request path.
  • Middleware strips credentials, question, and Authorization-style headers from log context.
  • Credential locals are zeroized in finally blocks.
  • X-Helen-No-Retain: true response header on every endpoint.
  • Sentry initialization is gated on the X-Helen-Telemetry-Consent header.
  • CORS allow-list is a single origin (the Helen frontend).

Reproducible audit steps

  1. Open DevTools » Network and start a chat session.
  2. Confirm only two outbound hosts appear: helen.joon.co (this site) and, if you opted in, *.ingest.sentry.io. Your SIEM’s hostname does not appear from your browser; the API talks to it on your behalf.
  3. Switch to the Application tab and inspect sessionStorage: you should see helen.siem.v1 with two base64 fields, never plaintext.
  4. Inspect server logs (we publish a sample bundle on request): you will not find your credentials, your hostname, or your prompt anywhere.

Reporting issues

We treat security reports seriously. Email security@joon.co with reproduction steps.