How your workspace is protected

The application runs on Railway in its EU West region (Netherlands). The database and authentication run on Supabase in Frankfurt, Germany (AWS eu-central-1). Both providers operate their infrastructure in data centres with physical access control, redundant power and network, and independent security certifications, which we review before engaging them.

The application and the database are in the same region, so workspace data does not leave the EU in normal operation. The exceptions are listed on the Subprocessors page.

• In transit: all traffic to Falrow uses HTTPS with HSTS. Connections from the application to the database use TLS with certificate verification against the provider's root certificate.
• At rest: the database and its backups are encrypted at rest by the provider (AES-256).
• Application-level: Slack credentials, meeting notetaker API keys, Sentry tokens, workspace AI keys, data source credentials and queued invitation emails are encrypted with AES-256-GCM before they are written, with a key held outside the database.
• Tokens: workspace API tokens and OAuth tokens are stored only as one-way hashes, so a database copy does not contain usable credentials.

• Four workspace roles: owner, admin, member and viewer. The same service-layer check answers every request from the browser, Slack, the REST API and every MCP tool.
• Tenant isolation through workspace scoping on every query and row-level security in the database.
• Coding agents connect with OAuth 2.1 using read or write scope and rotating refresh tokens, or with workspace tokens that expire after 90 days. Owners can see and revoke every connection.
• Writes from agents and the API are version-checked, so an agent cannot silently overwrite a newer change by a person.
• Passwords are at least 12 characters and are hashed by the authentication provider. Sign-ins are throttled per account and per hashed IP address. Users can revoke their other sessions.
• Session cookies are HttpOnly, Secure and SameSite=Lax.

Staff access. Production access is limited to the people who operate the Service, uses individual accounts with multi-factor authentication at our infrastructure providers, and is used only to provide support you request, to keep the Service running and secure, or when the law requires it.

• A fresh content security policy nonce on every page, so injected scripts do not run.
• Bounded upload and request sizes, and read deadlines on the API and MCP endpoints.
• Outbound requests to model providers and integrations refuse redirects and never echo remote error bodies, so secrets and customer content do not leak into logs.
• AI prompts and completions are never stored. Only token counts are recorded, for the spend cap.
• Dependencies are tracked and updated, and every change is reviewed and tested before deployment.

Each workspace has an activity log of who changed what, through which door, which owners can review. Server logs record the kind of a failure, not submitted content. Raw IP addresses are not stored in the database; rate limiting uses a one-way hash.

The database is backed up regularly. Backups are verified against a checksum manifest, retained on a rolling cycle of no more than 35 days, and restored to a new database so that a restore never overwrites live data. A restore revokes access tokens copied with the data and pauses pending jobs so that old notifications are not sent again.

During the private beta there is no contractual uptime commitment. We will tell affected workspaces about significant outages and their cause.

We have a documented process to detect, contain, investigate and recover from security incidents. If an incident affects Customer Personal Data, we notify affected customers without undue delay and within 48 hours of becoming aware of it, with what we know, what we are doing, and who to contact, as the Data Processing Addendum requires. Afterwards we share a written account of the cause and the fix.

Everyone with access to Customer Data is bound by confidentiality obligations and briefed on these measures. Access is removed the day someone leaves. We review each subprocessor's security and privacy commitments before engaging it, and bind it by contract to protections at least as strong as our own.

Email bas@falrow.com with a description, the steps to reproduce it and the impact you believe it has. We acknowledge reports within three business days and keep you updated until it is fixed.

If you act in good faith and follow these rules, we will not pursue legal action against you or ask authorities to do so:

• Test only against your own workspace, or one whose owner has agreed in writing.
• Do not access, change or delete data that is not yours; stop and report as soon as you see someone else's data.
• No denial of service, spam, social engineering or physical attacks.
• Give us reasonable time to fix the issue before telling anyone else.

A machine-readable version of this contact is published at /.well-known/security.txt.