This page is an honest list of everything we do today to keep your workspace safe, and a short note at the end on what we do not do. It is meant to be readable by a curious developer, a customer security team, or you. We follow the practices below carefully and we keep improving them.
1. Sign-in and access
Sign-in is handled by Clerk. Email and password, social sign-in, magic links, and multi-factor authentication all go through Clerk. Passwords are stored as bcrypt hashes inside Clerk. We do not see the plain password at any point.
Sessions are short-lived and rotate as you use the product. Signing out invalidates the session on our side, and that invalidation is covered by an automated test that tries to reuse the old token and confirms it fails.
Multi-factor authentication is available on every account from the profile page. It supports authenticator apps, short message codes, and backup codes.
AI clients connect through OAuth using the standard authorisation- code flow with PKCE. New clients register through dynamic client registration. Access tokens are stored only as one-way hashes.
Windows agents authenticate with a short-lived JSON Web Token issued at pairing time. The pairing token is single-use and expires after thirty days. Tokens used by the MCP interface are 256-bit secrets stored only as SHA-256 hashes, and the bearer string is shown to you exactly once at creation.
Two-factor authentication is on for every account on our side that touches production. That includes the Clerk dashboard, GitHub, the hosting provider, and the domain registrar.
2. Encryption
In transit, every request between your browser, your Windows app, the AI client you connect, and our servers uses TLS 1.2 or 1.3 with a strict modern cipher list. Older protocols are switched off at the edge.
At rest, every database file we hold is encrypted with SQLCipher. Each workspace gets its own database file with its own key, derived from a master key using HKDF. The master key is held inside our infrastructure in a file with restrictive permissions, and never leaves it.
Tokens, webhook signing secrets, and anything similar are stored only as SHA-256 hashes. Webhook secrets sit in environment files with mode 0600 and are excluded from version control. Passwords live inside Clerk, never in our database.
3. Network and infrastructure
At the edge, Cloudflare provides DNS, a web application firewall, rate limiting, and basic bot blocking. The origin is a single virtual private server located in India. All application processes bind to localhost and are reached only through the nginx proxy. Your workspace information has not left India and we do not plan for it to.
On the host, database files are mode 0600. Workspace directories are 0700 and owned by the service user. The host runs a firewall, protects ssh with fail2ban, and accepts ssh only with a key. Root sign-in over ssh is off.
4. HTTP security headers
Every response carries the standard set of modern security headers. Strict-Transport-Security is set for two years with includeSubDomains and preload. X-Content-Type-Options is nosniff. X-Frame-Options is DENY. Referrer-Policy is strict-origin-when-cross-origin. Permissions-Policy disables camera, microphone, geolocation, payment, USB, and the legacy interest cohort. The Content Security Policy is restrictive and only allows the Clerk sign-in widget, Cloudflare Turnstile, our payment provider, and assets we host ourselves.
5. Cookies
We use the minimum number of cookies needed. Those are the cookies that keep you signed in, the Cloudflare Turnstile cookie that protects the contact form, and a single first-party cookie that remembers your consent choices. With your consent we also load Microsoft Clarity for analytics, which loads only if you turn on analytics cookies. We do not use marketing trackers or advertising pixels.
Sign-in cookies set by Clerk are HttpOnly, Secure, and SameSite Lax. They rotate on session activity. You can review or change your choices at any time on /cookies.
6. Application security
Every input boundary is validated by a schema. Route handlers, MCP tool inputs, server actions, and webhook receivers all run input through a strict shape check before doing anything with it. Database queries are parameterised through prepared statements. The few identifiers that come from user input are checked against a strict allow-list before being put into a query.
Cross-site scripting is held back by React's default escaping, by the Content Security Policy that restricts scripts to a vetted allow-list, and by not using dangerouslySetInnerHTML on any input we do not control. Cross-site request forgery is held back by SameSite Lax cookies and by Cloudflare Turnstile on the public state-changing endpoints such as the contact form and the waitlist.
Rate limits are applied per endpoint, keyed by IP. Sign-in, sync pipeline, contact form, and waitlist all have their own counters. Webhooks from Clerk are verified with Svix and webhooks from Razorpay are HMAC-signed and verified on every receipt.
7. Workspace isolation
Each workspace lives in its own SQLite file at its own path under the data directory. The query path opens that file with a read- only handle as a defence in depth. We have written tests that try to read another workspace's data through crafted requests, and we run them on every release. The file-system permissions on the host prevent any process other than the service user from reading another workspace's file.
8. Audit logging
Privileged actions are recorded in an audit log with the actor, the action, the target, the IP, the user agent, the timestamp, and a free-form details JSON. We keep these rows for between twelve and thirteen months. A nightly sweeper removes anything older.
9. Your data lifecycle
You can download a copy of what we hold about you at any time from Account Settings › Account closure › Download my logs. The endpoint is rate-limited to three exports per hour.
You can ask us to close your account from the same screen. We handle deletion by hand so we can cancel your subscription, verify you are the one asking, and clean up your sign-in identity in one pass. Workspace data is held for thirty days and then deleted. Your sign-in, business profile, and payment history are preserved so you can come back any time.
10. Backups and recovery
Each workspace database is backed up nightly. Backup files are encrypted again with a separate key using the age tool and kept on an object store in a different region. Backups are retained for thirty days.
We run restore drills on a throwaway machine to make sure the backups are actually usable. The drill restores the latest backup, runs a smoke test against every primary code path, and tears the machine down. We do not commit to a specific recovery window. Restoring from a backup is fundamentally slower than not needing to.
11. Operations
Secrets live in environment files on the production host with restrictive permissions and are excluded from version control. The pre-commit hook in the repository runs the relevant test suites before allowing a commit and warns on patterns that look like an accidental secret. Dependencies are scanned automatically and we block merges that introduce a high or critical finding.
Logs are tagged with a request identifier, the workspace, and the actor so one line is enough to start an investigation. We keep a written incident-response runbook covering the decision tree for when and how to notify you of an incident, and a post-incident review for any incident that occurs.
12. We try our best, no system is perfect
Everything above is what we do today and we keep improving it. No software system anywhere is ever completely safe though, and we do not promise the product will be free from every possible incident. If an incident affects your workspace we will tell you and explain what happened.
You use the product knowing this. We do not accept responsibility for incidents that originate on infrastructure we do not run, for the behaviour of the AI clients or external services you connect, for force majeure events, or for indirect costs such as lost business or lost goodwill that may follow.
13. Things we do not do
Bring-your-own-key is not offered today. We use a single master-key model. The product runs in one region (India) and we do not replicate to multiple regions. End-to-end encryption is not offered because the product is built around a server-side AI query path that is incompatible with it.
We do not hold third-party security certifications such as SOC 2 Type II or ISO 27001 today, and we do not claim to. We will look at these when customer demand and the maturity of the product justify the spend.
14. Reporting a security issue
If you believe you have found a security issue, write to [email protected] with "SECURITY REPORT" in the subject line. We read every report and reply as soon as we can. We do not run a paid bug-bounty programme today, but we welcome responsible disclosure and will credit you in a public advisory where you want to be credited.