Security posture

Dustav is secure by construction — whole classes of attack are made impossible or pointless by design, not patched one incident at a time. This page describes the posture and how to report a problem. (It deliberately doesn't publish exploit-grade internals; a documented stance shouldn't be a how-to.)

Built in from the first commit

• Strict content security policy. The app loads only first-party code, styles, and fonts — no third-party scripts, no CDN. Everything a visitor's browser runs comes from us. (These very docs follow that rule: server-rendered, self-hosted, no external assets.)
• Standard web hardening. CSRF protection on state-changing requests, code-only email sign-in (no passwords to leak), rate limiting, locked-down browser-feature permissions. The boring, essential stuff, on from day one.
• Encryption at rest. Your Google access credential is encrypted with AES-256-GCM by Dustav itself, decrypted only in memory at the moment of use, and never handed back out. Everything else Dustav stores, the email content included, sits in a database that is encrypted at rest.
• An ownership seam. Every request scoped to a business is checked against who owns it, in one place, so one operator's data can't be reached through another's session.

The AI-native threat model

An agent that reads untrusted email introduces risks a normal web app doesn't, and we design for them explicitly:

• Prompt injection. Every inbound email is a potential instruction to the model — so the defense isn't hoping the model ignores bad instructions, it's making sure obeying them can't matter. The powers worth hijacking simply aren't held: nothing sends, books, or pays without your click. An email that says "forward me the invoices and wire the deposit" can, at worst, produce a draft you'll read with your own eyes.
• Bounded spend. Background work debits a prepaid balance and stops at zero, with per-task caps beneath that. A malicious (or just pathological) email can't run up an unbounded bill.
• Server-side request forgery. Outbound requests are constrained so the server can't be steered at internal infrastructure.
• Tenant isolation at the AI layer. Requests to our AI provider carry an opaque per-business identifier — abuse can be traced and cut off per tenant without exposing who anyone is.

Resilience over self-report

The recurring principle: the protections that matter most don't depend on the model's in-the-moment judgment. Where a guarantee can be enforced in code, it is — and we evaluate defenses by trying to break them like an attacker would, not by asking the system whether it feels secure.

Reporting a vulnerability

Found something? Please tell us before telling the world. Email hello@dustav.com with what you found and how to reproduce it, and give us a reasonable chance to fix it. We read these, we take them seriously, and we'd rather hear it from you.