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.)
• Self-host everything. We avoid third-party resources loaded into a user's browser as a matter of policy — the bar is "could a stranger's browser be made to talk to anyone but us?" and the answer stays no.
• Standard web hardening. CSRF protection on state-changing requests, code-only email sign-in (no passwords to leak), encrypted storage of your API key, rate limiting, locked-down browser-feature permissions. The boring, essential stuff, on from day one.
• An ownership seam. Every request scoped to a particular household is checked against who owns it, in one place, so one user's data can't be reached through another's session.

The AI-native threat model

An agent introduces risks a normal web app doesn't, and we think about them explicitly:

• Prompt injection. Because Dustav runs on your own key in your own account, the usual prize for hijacking an agent — someone else's resources or data — mostly isn't there. The attacker and the victim collapse into the same person. That doesn't make injection harmless, but it removes the multi-tenant payoff that makes it lucrative.
• Data exfiltration via web access. With web access, a fetch can only open a URL already present in the conversation — a boundary enforced by Anthropic's own server-side tooling, which closes the "trick the agent into sending your data to attacker.com" hole structurally.
• Server-side request forgery. Outbound requests are constrained so the server can't be steered at internal infrastructure. This is one of the few risks BYOK doesn't neutralize, so it gets real, dedicated defense.
• Key custody. Your key is encrypted at rest, decrypted only in memory at the moment of a call, and never handed back to anyone — and how it's stored and rotated is treated as a priority, not an afterthought.

Resilience over self-report

A 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 our defenses by trying to break them like an attacker would, not by asking the system whether it feels secure. (The constitution shows this same structure-over-prose stance applied elsewhere.)

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.

We evaluate our defenses the way an attacker would, not by asking the system whether it feels secure. Secure-by-construction earns the right to be transparent about how we work — a documented posture you can hold us to, not a "trust us."