Security at Quack Stack

Last reviewed: September 4, 2026

You hand us interview transcripts, support conversations, call recordings, and the strategy behind a product you have not shipped yet. This page says where that data lives, who can reach it, and what we do to protect it. Everything below is specific on purpose, so you can check it.

The short version: Quack Stack is operated by Willow Stories FlexCo, a company registered in Vienna, Austria. Your workspace data is stored in the EU. Some AI processing happens in the United States, and we name every provider that does it. We are preparing for a SOC 2 Type 1 audit and do not yet hold a report.

Questions, security questionnaires, or anything this page does not answer: [email protected].

Where your data lives

Your workspace data is stored in the European Union.

Primary database: Neon PostgreSQL in eu-central-1, Frankfurt.
Application hosting and project files: Railway in EU West, Amsterdam (GCP europe-west4). A single-region deployment with no replicas outside the EU.
Backups: Cloudflare R2, in an EU-jurisdiction bucket. The backup job refuses to start if it finds itself running outside an EU region.
Product analytics: PostHog EU Cloud.
Error monitoring: Sentry, EU region.

Some processing happens outside the EU. We would rather be specific than claim nothing leaves:

Anthropic (US) processes the content we send for analysis and synthesis. Under our agreement it is not used to train models. Anthropic's standard retention applies: inputs and outputs are deleted within 30 days, except where their trust and safety systems flag something. Our EEA contracting entity is Anthropic Ireland, Limited. Documents you attach during signup are held at Anthropic while they are read, for at most 14 days, and Anthropic may keep their metadata such as the filename for up to 30 days after that.
Voyage AI (US) generates the embeddings behind semantic search and duplicate detection. Training on our data is switched off, and Voyage deletes inputs immediately after processing.
Google (US) generates illustrations from prompts we write, and runs brand-visibility checks using search-style queries about your market. Your uploaded content is not sent to Google for analysis unless your workspace connects its own Gemini key.
Inngest (US) runs pipeline orchestration. It receives run identifiers and metadata, not research content. Names are resolved on our own infrastructure after the event crosses.

Narrower data reaches other providers outside the EU. For example, your account email for transactional mail, research queries for web, video and app-store search, and your billing details for payment processing. Loading any page of this site or the application also fetches fonts from Google, which means your IP address reaches Google. Anthropic and Voyage AI are covered by Standard Contractual Clauses. The full list, naming every provider, what it receives, and the safeguard that applies, is in the subprocessor section of our privacy policy.

Who can get in

Multi-factor authentication is mandatory for our own staff. Every account with administrative capability must have MFA enrolled. This is not a policy someone could forget to follow: an unenrolled staff account is redirected on every page and refused on every session-authenticated API call until enrolment completes, and cannot approve a new CLI or MCP connection. MFA is also required on every provider account that can reach production, including our source control, hosting, database, and DNS providers.

For your workspace, MFA is available to everyone and enforceable by you. A workspace owner can require it for all members, and must have it enabled on their own account before they can turn that requirement on.

Method: time-based one-time codes (TOTP) plus ten single-use recovery codes, shown once and stored only as hashes. We do not offer SMS or email codes, because both are weaker than what we already require.
Passwords: bcrypt at cost 12. Sign-in is rate limited to 10 attempts per email and IP address every 15 minutes, and failures are recorded with IP and user agent.
No stolen-cookie shortcut: enrolling in MFA or turning it off both require the account password as well as an active session.
Sessions: database-backed with a fixed 7-day expiry and no sliding renewal. Cookies are HttpOnly, SameSite=Lax and Secure. Changing a password ends every other session; resetting one ends all of them, along with every OAuth refresh token.
Roles: workspaces have owners, admins, members and viewers. Viewer is a real read-only boundary enforced server-side across the HTTP API and our CLI and MCP tools, not a UI convention.
Programmatic access: our CLI and MCP server use OAuth 2.1 with PKCE. Refresh tokens are stored as hashes, single-use, and rotated on every refresh: presenting one that has already been used revokes the whole grant. Write access requires a scope you granted explicitly.
Access reviews: on a quarterly schedule, covering administrative accounts, workspace memberships held by staff, provider account membership and MFA status, and outstanding OAuth grants.

Encryption

All traffic to and from the service runs over TLS, and every outbound call to a provider is HTTPS. Our database and object storage are encrypted at rest by the providers that operate them.

On top of that, some things are encrypted by us before they are stored:

Integration credentials (the tokens and API keys you connect for Slack, Linear, support tools, meeting recorders, and anything you bring your own key for) are encrypted with AES-256-GCM.
MFA secrets are encrypted with AES-256-GCM. Recovery codes and password reset tokens are stored as SHA-256 hashes, never in the clear.

Inbound webhooks are verified before anything is processed: HMAC-SHA256 for GitHub, signing secret for Slack, signature verification for Stripe. Unverified payloads are rejected.

Audit logging

Security-relevant events are recorded to an audit log: sign-ins and failed sign-ins, password and MFA changes, permission changes, member additions and removals, integration connections, and administrative actions. Entries are treated as append-only in application code and kept for 365 days.

Every HTTP request carries a correlation ID, so any single audit entry can be traced back to every other entry and log line from the same request.

A digest of the week's security events is generated automatically every Monday and is acknowledged by a person in the admin dashboard. That acknowledgement, rather than a separate note, is the record that the review happened.

What we do not claim: the log is not cryptographically tamper-proof. There are no signed rows and no hash chain. Append-only is an application contract backed by database snapshots. Audit writes also never block the action they describe, so a database failure can cost an entry. We would rather say so than imply more.

Backups

A complete dump of the production database is written to EU object storage every day. We keep a rolling set of daily, weekly and monthly copies. We restored one end to end when the job went live, to confirm the backups are restorable rather than merely present, and that check is on a quarterly schedule. The database also supports point-in-time recovery over a rolling 7-day window.

Because a backup is a snapshot, deleting something from the live database does not immediately remove it from copies already written. Those copies age out on a fixed schedule. The privacy policy states the outside window for erasure.

Who else touches your data

We keep a named list of every third party that processes personal data on our behalf, with what each one receives, where it processes it, and the transfer mechanism where one is needed. It is checked against the providers' own documentation, rather than from memory, on a six-month cycle.

Read it in the subprocessor section of our privacy policy. We give prior notice of material changes to that list, automatically, to every customer. There is no need to request it by email.

A separate point worth making: the tools you connect, such as your Slack workspace, your issue tracker, or your support desk, are not our subprocessors. Data there sits under your own agreement with that vendor. We read from and write to them on your instruction, using credentials you supply and we encrypt.

Keeping and deleting data

We hold a written retention schedule that sets a window per category of data rather than one blanket rule, and it names the cases where deletion is not instant, including backups. Audit logs are the one category stated above: 365 days.

The published windows, your rights under GDPR, and how to exercise them are in our privacy policy.

Certifications and compliance

We would rather be precise here than impressive.

GDPR: a live obligation, not a certification. We are established in Austria and our supervisory authority is the Austrian Datenschutzbehörde. A Data Processing Agreement is included inline in our privacy policy and applies automatically. If you need one signed on your paper, ask.
SOC 2: we are preparing for a Type 1 audit. We have not been audited and we do not hold a report. When that changes, it will be said here first.
International transfers: we rely on EU Standard Contractual Clauses, the EU-US Data Privacy Framework where the recipient is certified, and technical and organisational safeguards, depending on the provider. Some entries on that list, such as a public font CDN or a public search endpoint, are not processors acting on our instructions at all, and the privacy policy says which is which. Transfer documentation is available on request.

We are a small team, and we think the honest measure at our size is not whether we hold a certificate but whether we can tell you exactly where every piece of your data goes. That is what the list above is for.

Reporting a vulnerability

If you find a security problem, please tell us at [email protected]. Include enough detail to reproduce it. A real person reads that address.

We do not run a paid bounty programme and we are not going to promise you a response time we cannot keep. What we will do is confirm we have received your report, tell you what we found, and let you know when it is fixed. Please give us a reasonable chance to fix an issue before publishing it, and please do not access other people's data while testing.

Ask us anything

Security questionnaires, vendor review forms, a signed DPA, transfer documentation, or a question this page does not cover: [email protected].

Related reading: Privacy Policy, Terms of Service, Impressum.