· SECURITY

Security

Last updated · August 10, 2026

Dagur combines a private personal new tab with a company briefing shared to invited workspace members. Both can contain sensitive information. This page is the technical companion to our privacy policy: where that data lives, who can reach it, and what we'd have to do to recover or export it.

Four data modes

1 · Local-only (default for every user)

Widgets, notes, todos, captures, layouts, backgrounds — everything — live in your browser's localStorage and IndexedDB. Nothing is transmitted to any server. Clearing browser data deletes it permanently. You can export and import layouts at any time from Settings.

2 · Personal sync (Personal Pro, opt-in via sign-in)

When you sign in, a defined set of data syncs to Supabase (EU-hosted Postgres) under your user ID. AI threads and messages sync here too, so memory travels across your devices. The source of truth is Supabase; your browser is a cache.

3 · Company briefing (Free and Organization)

Workspace membership, channels, updates, intended-audience snapshots, delivery receipts, and explicit responses are stored in Supabase. Browser-facing row-level security limits recipients to their own membership, audience, delivery, and response rows. Workspace API routes also authenticate the caller and check membership and role before privileged operations. Invite and integration credential hashes are server-only; raw keys are shown only when created.

4 · Never persisted (BYOK)

If you provide your own Anthropic API key, AI requests go directly from your browser to api.anthropic.com. Our servers never see the request, the response, or the key. The key is stored in your browser's localStorage under mmdb:api-keys.

AI memory architecture

Tables

TableContentsAccess
ai_threadsThread id, title, surface, metadata, summaryOwner only via RLS
ai_thread_messagesUser and assistant turns, content, model, tokensOwner only via RLS
subscriptionsTier, Stripe IDs, period endServer reads via service key; you read your own row
google_oauth_tokensEncrypted refresh tokens for connected Google accountsServer-write only; owner-read
workspace_updatesCompany briefing updates, schedule, expiry, and source labelOnly intended recipients via RLS
workspace_update_audienceRecipient snapshot captured when an update is publishedEach recipient reads only their own row
workspace_connectorsPublishing source, scopes, usage timestamp, and one-way credential hashServer only

Access enforcement

Dagur uses more than one policy because personal data and company briefings have different ownership models:

  • Personal rows — browser-facing access is scoped to the signed-in user's ID through row-level security.
  • Briefing recipients — browser-facing policies restrict membership, audience, delivery, and response rows to the signed-in recipient.
  • Workspace operations — API routes authenticate the caller, require workspace membership, and enforce publisher, inviter, or connector-manager roles before using a server credential.

The server credential can bypass row-level security, so those explicit API membership and role checks are a real part of the security boundary—not a detail we hide behind a blanket database claim. They are covered by workspace API and local end-to-end tests.

Encryption

  • In transit — TLS 1.2+ end-to-end (browser → Vercel → Supabase → AI providers)
  • At rest — Supabase encrypts managed database storage. Dagur does not intentionally write briefing request bodies or integration keys to application logs
  • API keys (BYOK) — stored in browser localStorage. Browser isolation is the security boundary. Anyone with physical access to your machine can read them, the same as any API key in any SaaS app
  • OAuth tokens — Google refresh tokens are encrypted server-side and never exposed to the client

Long-thread summarization

When a thread outgrows the model's context window, our server uses a small Claude model to roll older turns into a compact summary stored on the thread row. The summary is derived from your messages; your messages are never sent to anyone other than our AI inference providers. We do not use your data to train models.

What we can and can't do

Things we can do (with your permission)

  • Export your data — email hello@dagur.co and we'll send a JSON export of your threads, messages, subscription, and synced settings within 7 days
  • Delete your account — Settings → Account, or email us. Cascade deletes remove threads, messages, and tokens within 30 days
  • Pause data processing — sign out. Cloud sync stops immediately; local data stays in your browser

Things we can't do

  • Expose personal canvas content through the workspace briefing — workspace publishers receive briefing results, not access to a recipient's personal widgets, notes, or canvas
  • Recover deleted local-only data — Free-tier data lives in your browser. If you clear it, it's gone. We never had a copy
  • See your BYOK key — it never leaves your browser

Sub-processors

We use a small, deliberate set of vendors. Each is named in the Privacy Policy with links to their compliance pages.

  • Supabase — database and auth. SOC 2 Type II. EU-hosted
  • Vercel — hosting and serverless functions. SOC 2 Type II
  • Anthropic — AI inference. Data is not used for training under default API terms
  • OpenAI — secondary AI inference. Data is not used for training under default API terms
  • Stripe — payments. PCI DSS Level 1
  • PostHog — anonymous product analytics, EU-hosted

Reporting a vulnerability

Email security@dagur.co (or hello@dagur.co if that bounces). We acknowledge within 2 business days and coordinate disclosure. No paid bug-bounty program yet — serious reports get a credit on this page and a personal thank-you.

A note on threat modeling. Dagur is not the right place for secrets that require a dedicated password manager or vaulted storage. Don't paste private keys, customer PII, or credentials into Capture. For everything else a builder keeps in their head — meeting notes, decisions, open loops — this is the job.