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.