Security

1. Overview

This page describes Mano's actual current security practices and the gaps we haven't closed yet. It will evolve as Mano matures. We've scoped SOC 2 readiness work to begin once Mano reaches 5+ paying merchants; today we have zero, so it's honest to say that work hasn't started.

Every claim here is verifiable against our codebase. Where a practice isn't in place, you'll find it stated plainly in section 7 rather than dressed up in compliance vocabulary.

2. Data we collect

Mano stores the minimum required to provide the product:

• Merchant data — Shopify store domain, the encrypted Shopify OAuth access token, and email addresses for authorized users via Clerk.
• Customer data— sourced from the merchant's connected Shopify store or from CSV uploads. This includes customer names, emails, shipping addresses, order and return history, and risk scores Mano computes from that history.
• Action and decision history — every action a merchant takes from the Inbox is written to a DecisionAuditLog row recording who decided what, when, and the recommendation Mano made at the time.
• Billing data — handled by Stripe. Mano stores only the Stripe customer ID and subscription metadata. We never see or store payment card details.

3. How data is stored

• Database— Postgres on Neon, hosted in AWS's us-east-1 region.
• Tenant isolation — every Mano model that holds merchant data carries a merchantId column and a foreign-key constraint to the Merchant table. Every application query is scoped by merchantId as a pre-condition; cross-tenant reads are not possible through the application layer.
• Shopify access tokens — encrypted at rest with AES-256-GCM (authenticated encryption with a random IV per token; key supplied via environment variable). The encryption module is at lib/shopify/encryption.ts.
• Backups— Neon's continuous backup and point-in-time recovery cover the database. We do not run a second backup tier today.
• Data residency— US-East only at this stage. UK/EU residency is on the Stage 2 roadmap and is not available today. If this matters to your procurement process, it's worth raising before you connect a store.

4. Authentication and access

• User authentication— managed by Clerk. Mano is currently using Clerk's development instance across all environments. A production instance is provisioned with the hosted-domain rollout; if you sign up today you may see a Clerk development banner, which we will remove with that cutover.
• Multi-factor authentication — available on user accounts via Clerk.
• Multi-user / role-based access— not supported yet. One user per merchant today. Multi-user with role-based permissions is on the roadmap and gated on reaching 2–3 active merchants.
• Session management — Clerk-managed sessions with a configurable session length.

5. Integrations

• Shopify — OAuth 2.0 with HMAC-verified callbacks. Access tokens are encrypted at rest (see section 3). Current OAuth scopes are read_customers,write_customers,read_orders,read_returns,write_orders,write_products,write_gift_cards,write_returns,write_store_credit_account_transactions. Each scope is justified by a specific code path; we don't request scopes we don't use. The full scope-to-operation map lives at the head of lib/shopify/graphql.ts.
• Stripe— secret keys stored as environment variables in Vercel. Incoming Stripe webhooks are verified using Stripe's signature scheme via stripe.webhooks.constructEvent before any processing.
• Resend (email) — API key as an environment variable; used only for daily merchant digest emails and internal notifications. We do not send marketing email through Resend.
• Webhooks — incoming Shopify webhooks (including the three GDPR compliance topics) are verified by HMAC-SHA256 computed over the raw request body, compared to the X-Shopify-Hmac-SHA256 header using a timing-safe equal. Mismatched signatures return 401 without touching the database.

6. GDPR and data deletion

• Three Shopify mandatory compliance webhooks subscribed and implemented: customers/data_request, customers/redact, and shop/redact. Routes live at app/api/shopify/webhooks/compliance/.
• Customer redaction — on a customers/redactwebhook we cascade-delete the customer's records (FraudFlag, Return, ReturnItem, MerchantAction, DecisionAuditLog, InboxDismissal, ApprovalRequest, ShopifyTagOperation, Customer) atomically in a single database transaction.
• Shop redaction — 48 hours after a merchant uninstalls, Shopify fires shop/redact. Mano cascade-deletes all of that merchant's data, severs the User↔Merchant link in Clerk-backed user records, and removes the Merchant row.
• Deletion audit trail — every deletion event writes a row to DeletionAuditLog regardless of whether the targeted merchant still exists. That table has no foreign key back to Merchant precisely so the audit record outlives a shop redact.
• Data access requests — handled within 30 days. Today the founder fulfils these manually after Shopify forwards the request through the data_request webhook. A merchant-facing self-serve export is a future enhancement.
• Retention periods — Personal data is kept only as long as needed. While the integration is active, merchant + end-customer data is retained for the life of the install. On uninstall, Shopify fires shop/redact 48 hours later, and Mano cascade-deletes the merchant's data within 30 days (typically minutes). End-customer erasure requests via customers/redact are honoured in a single atomic transaction. Operational logs are pruned at 90 days. Billing records are retained for the statutory accounting period (~6 years). The full schedule lives in section 5 of our Privacy policy.
• Data Processing Agreement — a working draft is published in our repo at legal/DPA-TEMPLATE.mdand available on request via email; we'll send the current revision the same business day. The standard published form is on the Stage 2 roadmap.

7. What we don't have yet

The honest section. We'd rather you know exactly where the edges are than discover them later.

• SOC 2 (Type 1 or Type 2) — not started. Readiness work begins when Mano has 5+ paying merchants. There is no third-party auditor engaged today.
• ISO 27001 — not started. No current timeline.
• Third-party penetration testing — not yet performed. We run a self-administered security review quarterly; an external pen test is planned at the 5+ merchant mark.
• Multi-region data residency — US-East only. EU/UK residency requires architectural work scheduled for Stage 2.
• Bug bounty program — not yet established. We accept good-faith disclosures via email (see section 8).
• 24/7 incident response— Mano is solo-founder-operated. Our current SLA is a 24-business-hour response. Critical incident escalation is by direct email to security@; we'll publish a formal severity ladder when we have a team to triage it.

8. Reporting security issues

Found something? Email security@mano.help.

We respond within 24 business hours and will not pursue legal action against good-faith security researchers. If your disclosure includes a working proof-of-concept, please do not run it against another merchant's store or against any customer data — a description plus the affected endpoint is enough to start.

What to include in your report: description of the vulnerability, steps to reproduce, potential impact, your contact details for follow-up.

Our commitment: acknowledgment within 48 hours of report; status update within 7 days; fix targeted within 30 days for critical issues, 90 days for lower severity; public acknowledgment in our security disclosures if you wish.

In scope: the production mano.help domain and dashboard, authentication and session management, data handling and storage, the Stripe billing integration, and the Shopify integration.

Out of scope: social engineering of Mano staff, physical attacks, denial-of-service or rate-limiting issues, reports about Clerk / Stripe / Shopify themselves (please report directly to them), and issues in preview or development deployments.

A machine-readable companion to this policy lives at /.well-known/security.txt per RFC 9116.