Email Triage

Privacy, Sovereign AI & HIPAA

Email content never leaves your network. By default. By design.

The plain version: the AI that reads your mail runs on hardware you control, so nothing is handed to an outside AI company. Below is the proof in depth — the code-level and cryptographic detail is written for an IT or security reviewer, so skip the parts that aren't your job.

For legal teams

Sovereignty is a confidentiality and privilege argument — not only a compliance one.

When privileged client communications or attorney work-product pass through a third-party AI service, two problems follow. First, that vendor now holds discoverable material an opposing party could try to compel. Second, routing privileged content to an outside party can be argued as a waiver of attorney-client privilege or work-product protection. A sovereign, on-box AI removes both surfaces: the classifier and drafter run inside your walls, so there is no third-party AI vendor to subpoena and no third-party disclosure to argue a waiver from. Nothing leaves your network — there is nothing at a vendor to produce.

Strategy, not legal advice. This is a technology-architecture argument for shrinking the surface a privilege or discovery fight can reach; your privilege analysis is yours to run with your own counsel. The Legal / law-firm vertical covers it in full.

Sovereign AI in Email Triage

Three concentric privacy guarantees.

Sovereign AI is implemented at three levels of the stack — each strictly stronger than the last.

1. Local-First Classifier

Default Ollama backend on your own GPU host. Qwen / Llama / Mistral families supported. Email content never traverses a third-party API. No SOC 2 boundary to argue about. No data-processing addendum to negotiate. The classifier is yours.

2. BAA-Gated Cloud Backend

Operators with BAA coverage (OpenAI, Gemini, OpenAI-compatible) can configure cloud classification. The BAA gate is enforced in code, not policy. HIPAA-flagged messages skip cloud routing until the operator records BAA acknowledgment in the audit log. The compliance officer's question — "what stops PHI from going to OpenAI?" — has a code-level answer.

3. Hard-Locked Embedding Allowlist

The RAG path (sent-mail context for drafted replies) is hard-coded to local-only — ollama, in-process sentence-transformers, and a fallback composite. A static privacy-invariant test fails the build if anyone tries to add a non-local backend here. Drafted-reply context is higher-volume PHI exposure than per-message classification; the allowlist forecloses cloud embedding entirely.

HIPAA Mode

A single toggle. Cascading enforcement across the codebase.

PHI-Scrubbed Logs

Sender, subject, body, and classification reasoning are redacted from system logs. The [redacted] token replaces these fields in every log line.

Static Privacy Scan

A test suite runs on every build that greps the production source for forbidden field references in log calls. Any new code that would log a sensitive field fails the test before merge.

Redacted Notifications

SMS / push notifications include category and timestamp only. Never the sender, subject, or body content.

Recipient Verification (opt-in)

When you enable it, the daily-digest feature refuses to send if the configured to-address doesn't match the account owner — protection against accidentally cc'ing PHI to the wrong stakeholder. Off by default; you turn it on.

PHI-Aware Caching

On HIPAA-flagged accounts the classification cache stores no free text: the classifier’s free-text reason is stripped at write time and the cache key is hashed, so no PHI sits in the side-cache.

Tamper-Evident Audit Log

Every login, account view, credential use, and security-relevant event is written into an append-only HMAC-SHA256 keyed hash chain — each row cryptographically linked to the one before it. As of v0.2.0 the chain spans 8 audit-event tables plus a per-request PHI-access log. Because it is keyed (not a plain SHA-256 hash), an attacker can't recompute a valid chain after editing a past row; it survives master-key rotation and fails closed — with no key present, a chained write is refused rather than downgraded to a secretless hash. Any alteration is detectable in seconds via the email-triage audit verify CLI or the paginated /compliance review surface.

Compliance dashboard

/compliance — HIPAA mode, audit-chain status, BAA acknowledgments, TLS certificate lifecycle

Supply Chain Security

You verify the image before you trust it.

Sovereign AI ends at the model boundary if the runtime itself isn't trustworthy. Email Triage publishes a verifiable supply chain so compliance officers can answer "where did this binary come from?" with a cryptographic chain instead of a vendor email.

Cosign-Signed Images

Every published container image is signed with cosign using keyless OIDC against the GitHub Actions identity. No long-lived signing key to lose or rotate. Operators verify with cosign verify before pull.

SLSA-3 Build Provenance

Each image carries a SLSA-3 build provenance attestation: who built it, when, from which source revision, in which builder. Proves the image came out of the public CI pipeline running against the public source — not a one-off developer laptop build.

Operator Approval Attestation

A separate human-validated review event signed against the same digest (predicate operator-approval/v1). Distinguishes "the CI passed" from "an operator reviewed and approved this release."

HIPAA Install Gate

For HIPAA installs the operator verifies both attestations on the same image digest before pulling. A poisoned CI run with no operator attestation can't satisfy the check, so it can't reach a HIPAA host. Verification recipe in the public repo's docs/.

Air-Gap Verifiable

Air-gap installs use scripts/download-embedding-bits.sh on a connected machine to produce a hash-pinned tarball + SHA-256 sidecar. Sideload through the admin UI runs the same hash verification as the auto-download path — operator-staged bytes are not trusted.

Pinned Tags, Floating Aliases

Customers pin to immutable vX.Y.Z tags (same digest under both vX.Y.Z and X.Y.Z forms). Float to X.Y, X, or :latest for development-friendly upgrades. :edge for every push to main.

Automated Dependency-CVE Watch

Every dependency baked into the image is watched automatically across six public advisory sources — pip-audit, OSV, the National Vulnerability Database, GitHub Security Advisories, upstream releases, and base images — so a newly disclosed vulnerability surfaces on its own instead of waiting for someone to remember to look. Ecosystem noise that can’t reach a live code path is filtered out; a CVE that genuinely reaches the code raises an alert, and the fix ships only after the full test suite passes and a human signs off — each leaving a §164.316 register entry. Proven by the pyasn1 remote-code-execution advisories (CVE-2026-59885/59886), closed in a single release cycle.

Source: github.com/Unlimited-Data-Works-LLC/Email-Triage · Image: ghcr.io/unlimited-data-works-llc/email-triage · License: Apache 2.0

Encryption at Rest

The whole database is encrypted. Secrets are encrypted again inside it.

Layer 1 — whole-database encryption (SQLCipher). The entire database file — emails, classifications, accounts, audit logs, and credentials — is AES-256 encrypted on disk (single-file SQLCipher: AES-256-CBC with HMAC-SHA512 page integrity). Encryption at rest is on by default for new installs as of v0.2.0. The storage key is HKDF-SHA256–derived from your master key, and every connection — live, backup, and migration — opens through one encryption-aware path, so no code path can quietly write a plaintext copy.

Fail-closed boot. If encryption is required (HIPAA mode) or requested but the SQLCipher library or master key is missing, the application refuses to start rather than silently falling back to plaintext. A HIPAA install that hasn’t requested encryption is loudly advised, not silently downgraded — disk-level LUKS is a documented equivalent.

The crypto build itself is pinned. The container source-builds SQLCipher from a version-pinned amalgamation (v4.17.0), and a boot-time assertion refuses to start on any SQLCipher below the required version floor. A base-image rebuild or dependency change can’t silently downgrade the encryption path underneath you — the app fails closed rather than serve on a weaker crypto library.

Layer 2 — secrets encrypted again, inside the encrypted database. Provider passwords, OAuth refresh tokens, and other secrets are additionally encrypted with Fernet (AES-128-CBC + HMAC-SHA256). One master key powers both layers — it directly unlocks the Fernet secrets and, via HKDF, derives the SQLCipher storage key — and it is held outside the database. Storage options for that master key:

Backing up the database without also backing up the master key leaves it unrecoverable — a safety property for off-site backup storage.

Transmission Integrity (TLS)

  • Built-in ACME / Let's Encrypt issuance + automatic renewal (DNS-01 via RFC-2136, or HTTP-01 in standalone or webroot mode), or bring-your-own cert
  • Self-signed for internal-only deployments
  • Operator-supplied certificates
  • Tailscale-issued certificates for funnel deployments

Authentication

  • Email OTP (default)
  • WebAuthn / Passkey (YubiKey, Touch ID, Windows Hello)
  • CSRF protection with session-bound tokens
  • Per-session audit row (auth method, IP, user agent)

Multi-Tenancy & Delegation

Three-role audit model.

The user model supports three roles with distinct audit semantics:

Delegate actions are stamped with both the actor and the account-owner in the audit log. The audit gate distinguishes owner self-access from delegate access — owner self-access is treated, by operator-configurable design aligned to the §164.502(a) self-disclosure carve-out, as not a loggable PHI-access disclosure; delegate access is, and writes an audit row every time. (Whether that carve-out applies to your setup is your compliance call — not a determination the software makes for you.)

Standards Honored

RFCs and regulations the system aligns to.

StandardApplication
RFC 5322Internet Message Format. Parsing inbound mail, writing outbound headers with proper In-Reply-To threading.
RFC 6154IMAP SPECIAL-USE flag. Drafts / Sent folder auto-discovery via \Drafts / \Sent markers.
RFC 5545iCalendar. Parsing .ics payloads on incoming meeting invites.
RFC 5546iMIP. Invite-acceptance / decline / tentative drafted as METHOD=REPLY with proper threading.
HIPAA §164.312(b)Technical Safeguards — Audit Controls. Hash-chained audit log; CLI verifier.
HIPAA §164.312(e)(1)Transmission Security. TLS posture, certificate lifecycle.
HIPAA §164.502(a)Self-Disclosure carve-out. Audit gate avoids spurious "PHI access" rows on owner self-access.
HIPAA §164.502(b)Minimum-necessary. Delegate-vs-owner gating, metadata-only notifications, and PHI-locked alerting limit exposure by construction.
HIPAA §164.528Accounting of disclosures. The tamper-evident HMAC access-event chain is built to support the disclosure record.
HIPAA §164.402(2)Breach safe-harbor. Encryption at rest is the technical basis a breach analysis turns on — unreadable PHI supports, but does not by itself conclude, a safe-harbor determination.
NERC CIP-007-R4Logging and Monitoring. Audit-log shape informed by CIP-007.

What self-hosting wins you. Because Email Triage runs on your own infrastructure and classifies with a local model by default, PHI never leaves your network — no outside AI vendor receives it, so no BAA with a cloud AI vendor is required. If you deliberately enable a cloud backend, the code-enforced BAA gate blocks PHI from reaching it until you record that specific vendor’s BAA. Encryption at rest gives your breach analysis its technical basis under §164.402(2) — unreadable PHI is the fact a safe-harbor determination turns on; the HMAC audit chain is built to support a §164.528 accounting of disclosures; and delegate-vs-owner gating plus PHI-locked alerting keep access minimum-necessary by construction.

Honest scope. These are engineering controls aligned to the cited rules — not a certification, and not legal advice. Email Triage is a technical tool that helps you meet your obligations; it does not by itself make an organization HIPAA- or 21 CFR Part 11–compliant. Compliance is a program you own: your policies, your BAAs with other vendors, your validation and your attestations. The cryptographic attestations described here prove an image’s provenance, not your regulatory posture. Confirm applicability with your own compliance counsel.

Beyond Email

Need sovereign AI for your organization, not just for email?

Email Triage is one application of sovereign AI patterns. The same approach — local-by-default LLM, code-enforced compliance gates, audit-ready architecture — applies to any AI initiative in a regulated environment. I help organizations design and implement sovereign AI strategy across their stack.

Sovereign AI for Medical Research →   Sovereign AI for Regulated Industries →   Sovereign AI for Legal →