Sovereign Privacy &
Zero-Trust Architecture.
Nuncio is being engineered to keep your data on your hardware and your credentials out of reach of everything else. Two pillars below are real and enforced today. The rest — at-rest encryption, memory zeroization, HTML sandboxing, a fail-closed updater — are hardening work still ahead. Do not point Nuncio at real accounts or sensitive data until they land.
Six Security Pillars
Each card is tagged with what's actually true today, not just the target.
1. Column-Level Payload Encryption
The design target: every email body, HTML string, and subject header encrypted before database persistence, so a stolen disk or raw SQLite dump reveals nothing. Not implemented yet — message content is currently stored unencrypted.
- Target: authenticated encryption (AEAD) for every column write
- Target: key derivation seeded from the OS keyring, not a hardcoded secret
- Tracked under the engine's security hardening milestone (M6)
- Do not store sensitive real mail in Nuncio until this lands
2. Attachment Stream Encryption
Large binary attachments are meant to be encrypted with a modern streaming cipher so the daemon never buffers a full attachment in memory. This is a design goal, not shipped behavior today.
- Target: chunked, authenticated encryption for attachment blobs
- Target: constant, low RAM ceiling regardless of file size
- Not yet implemented — attachments are not currently encrypted at rest
3. Memory Hygiene (Secret Zeroization)
Cryptographic key material, passwords, and refresh tokens should be held in memory that is explicitly zeroed on drop and never swapped to disk. Work is underway; it isn't verified complete across the codebase yet.
- Goal: explicit zeroing of secret buffers on drop
- Goal: OS-level page locking against swap for sensitive buffers
- Tracked under the engine's security hardening milestone (M6)
4. OS Keyring Enclave Integration
This one is real today. Nuncio never writes plaintext passwords, OAuth refresh tokens, or private keys into configuration files or the SQLite database. Secrets go through the OS credential store.
- Windows Credential Manager, macOS Keychain, and Linux Secret Service, via the keyring crate
- Zero credentials in SQLite or on-disk config files
- Enforced across every code path that touches account credentials
5. WORM Cryptographic Audit Ledger
Also real today. Filter matches, webhook dispatches, and account mutations are recorded in an immutable, Write-Once-Read-Many audit ledger sealed with HMAC-SHA256 block linking.
- Block linking: H_n = HMAC-SHA256(K, seq || ts || actor || action || data_hash || H_n-1)
- SQLite triggers reject updates or deletes against the audit table
- Chain integrity is verifiable via the CLI today
6. HTML Email Sandboxing
HTML email carries tracking pixels and can carry hostile markup. The target is to render it inside a strict sandbox with JavaScript disabled — but no client renders HTML yet, so this hasn't shipped.
- Target: <iframe sandbox> with a strict content-security-policy blocking script execution
- Target: stripped tracking beacons and remote-image proxying
- Depends on a GUI or TUI client existing to render into — neither exists yet
A Governed AI Gateway (Planned)
PlannedThe MCP client doesn't exist yet — this is the design it will be held to.
When local LLMs and AI agents eventually connect to Nuncio via a Model Context Protocol client, the plan is that they never receive raw credentials or direct provider access. Every agent action would pass through a policy gateway governed by rules like these:
Explicit capability flags (read mail, send mail, manage filters). Unauthorized tool calls get blocked.
Restrict agent access to specific accounts or folders you choose.
Sensitive identifiers scrubbed before any text reaches an LLM context window.
Threat Model & Defensive Engineering
What Nuncio defends against, and how far along each defense actually is.
| Attack Vector | Threat Scenario | Defense | Status |
|---|---|---|---|
| Remote Code Execution via HTML Email | Malicious HTML emails executing scripts in a rendering client. | Planned strict sandbox with script execution disabled — no rendering client exists yet to apply it to. | Planned |
| Uncontrolled AI Agent Data Access | An AI agent reading or acting on your mail without a boundary. | Planned RBAC gateway and PII redaction for the MCP client, which does not exist yet. | Planned |
| Server-Side Request Forgery (SSRF) via Webhooks | A webhook action reaching an internal service or cloud metadata endpoint. | The webhook dispatcher already blocks redirects and known private/loopback targets. Real in the engine; not yet wired into the live sync path. | In progress |
| ReDoS via Malicious Regex Rules | A crafted regular expression causing catastrophic backtracking. | The rule validator statically rejects dangerous nested-quantifier patterns before a rule can be saved — this is a compile-time check, not a runtime timeout. | In progress |
| Database Corruption from Crash or Power Loss | A sudden outage corrupting the local SQLite database. | Startup integrity checks and a recovery path exist in the storage engine and are under active hardening. | In progress |
| Credential Exfiltration from Disk | Malware or an attacker scanning local files for plaintext passwords. | Real today: credentials are never written to files or SQLite — only to the OS credential store. | Available now |
Verify your WORM audit ledger integrity from the CLI, built and run from source:
# Build and run from source (no packaged installer yet) git clone https://github.com/KofTwentyTwo/nuncio.git cargo run -p nuncio-cli -- store verify-audit-chain
Reporting a Vulnerability
Nuncio is pre-alpha; several hardening items above aren't complete. Please report privately, not via public issues.
Email security@kof22.com — do not open a public GitHub issue for a security report.
Acknowledgment within 48 hours, and an assessment with a remediation timeline within 7 business days.