Security at HundredFold

HundredFold is a multi-tenant business-intelligence and action platform for direct-to-consumer ecommerce brands. Merchants connect their store, advertising, email, and inventory data; we turn that data into AI-prioritized insights and let teams act on them. Because that requires connecting real business systems and processing data on a merchant's behalf, security is a core part of the product rather than an afterthought.

This page describes the controls we have in place today, the architecture we are building toward, and the areas we are honest about still being in progress. We use the SOC 2 Trust Services Criteria as our reference framework. To be clear about what that means: HundredFold does not currently hold its own SOC 2 report. Our controls are designed to align with the SOC 2 criteria, and a formal SOC 2 program is planned. Where we rely on third parties, we note their independent attestations separately.

Our security commitment

We commit to:

• Keeping each merchant's data isolated from every other merchant's data.
• Encrypting data in transit and at rest.
• Limiting the personal data we process to the minimum needed to deliver the product.
• Never sending end-customer personal information or secrets to the AI model.
• Being transparent about what is built, what is rolling out, and what is still planned.

Multi-tenant data isolation

HundredFold is multi-tenant: many merchants are served from shared infrastructure, with strict logical isolation between them.

• Org scoping in application code. Every record carries the org id of the merchant that owns it. Every database read and write is scoped to the org of the authenticated caller. One merchant cannot read or write another merchant's data.
• PostgreSQL Row-Level Security (RLS) backstop. On top of application-level scoping, the database itself enforces row-level security policies as a defense-in-depth backstop. Even if an application-layer query were written incorrectly, the database is configured to prevent cross-tenant access.
• Tested. This isolation model is built and tested, not aspirational.

There is no feature that allows one merchant to access another merchant's data.

Encryption

Integration token storage (rolling out)

Connecting an integration produces credentials — OAuth tokens or API keys — that must be stored to keep syncing your data. The architecture we are migrating to stores these credentials in Supabase Vault by reference: the credential is encrypted at rest, the application tables hold only an opaque secret ID, and decryption runs through SECURITY DEFINER database functions that are revoked from the anonymous and authenticated roles — only the server's service-role connection can call them. Token resolution already reads Vault-first, and each provider is being migrated over with a one-time backfill.

In the interest of accuracy, this is not yet the active path for every provider: some credentials currently live in server-side environment variables, and some OAuth tokens remain in database columns pending backfill. Regardless of where a credential sits today, it is never exposed to the browser or to the AI model, and the database itself enforces the PostgreSQL Row-Level Security and per-organization scoping described above — so credentials are reachable only by the server and isolated per tenant. We describe the Vault-by-reference model as our target end-state and update this page as providers are migrated.

Authentication and access control

• Passwordless authentication. Sign-in is via a magic link sent to a work email address, or via Google sign-in (SSO), through Supabase Auth. HundredFold stores no passwords.
• Invite-only allowlist. There is no public self-serve signup. Access is granted only by an account owner adding a user to the org's allowlist.
• Role-based access. Each user holds a role — owner, admin, member, or viewer — that governs what they can do within their org.
• Identity-provider-backed MFA. Because authentication is delegated to a magic-link email or to Google sign-in, multi-factor authentication is inherited from the user's own email or Google account. Merchants who enable MFA at their identity provider (for example, Google Workspace) extend that protection to HundredFold automatically.
• Minimal account data. For each user we store only their email address, role, and an internal Supabase user id. We do not store user phone numbers, postal addresses, or payment details.

Data minimization (what we process)

Limiting the data we hold is itself a security control. HundredFold processes a deliberately small amount of personal data.

• Account / user data (we are the controller). Merchant team members' work email, role, and an internal user id, as described above.
• End-customer data (we are the processor; the merchant is the controller). From a connected Shopify store's orders, we store only the customer's email address and the shipping city, state, and country. We do not collect or store customer names, street addresses, phone numbers, payment or card data, or customer profiles. The stored email is used to export win-back audience lists to the merchant's own Klaviyo account.
• Integrations. Meta, Google, and Amazon data we read is aggregate metrics (spend, impressions, clicks, ROAS, sessions, conversions, revenue and order counts, placement breakdowns) and contains no end-user PII.

AI privacy

HundredFold uses Anthropic's Claude model for the daily briefing, ad and email strategy, and copy generation. The AI receives business aggregates only — for example revenue/ROAS/AOV KPIs, inventory summaries, top-ad metrics, customer-health rates such as repeat and refund percentages, email metrics, and the replenishment plan — plus the merchant's own written business-context notes.

The AI model never receives:

• end-customer names, emails, or addresses;
• any API keys, tokens, or other secrets.

No end-customer personal information is sent to the AI model.

Secrets management

Provider keys and application secrets (OAuth client secrets, API keys, signing secrets) live in server-side environment variables. They are never exposed to the browser and never sent to the AI model. Operational secrets are not transmitted over insecure channels or pasted into application data.

Infrastructure and sub-processors

HundredFold is built on a small set of vetted providers. The two providers that host the application and store its data both maintain independent SOC 2 Type II attestations.

Hosting region per provider: United States (confirm per provider before publication).

Sub-processor due diligence. Before relying on a sub-processor we review its security posture and relevant attestations, and we limit each sub-processor to the minimum data required for its function (for example, Anthropic and Resend never receive end-customer PII). A current sub-processor list is maintained on this page; material changes are communicated by updating this page and notifying account owners by email.

Merchant-connected platforms (not HundredFold infrastructure). Shopify, Meta, Google, and Amazon are data sources that the merchant authorizes through OAuth or API credentials. They are governed by their own terms and are not HundredFold infrastructure sub-processors.

Backup and recovery

Application data is stored in our managed database provider, which performs automated backups and supports point-in-time recovery (PITR). Formal recovery objectives (RPO/RTO) and a backup-restore test cadence are being defined as part of our SOC 2 program.

Monitoring and logging

We maintain operational logging across the application and infrastructure to support troubleshooting and security investigation. Access to logs is restricted to authorized personnel; log-retention periods and security alerting / anomaly detection are being formalized as our security program matures. Logs are scoped to operational and security needs and are not used to expose end-customer personal data beyond what the product already processes.

Vulnerability and dependency management

We monitor application dependencies for known vulnerabilities and apply security updates as part of ongoing maintenance. Formal remediation-timeline targets by severity, and any periodic code scanning or penetration testing, are being established as our security program matures.

Incident response

If we become aware of a security incident affecting merchant or end-customer data, we will:

1. Investigate and contain the incident.
2. Assess what data and which parties are affected.
3. Notify affected parties without undue delay, with a target notification window of 72 hours from confirmation of a qualifying incident.
4. Support affected merchants in meeting their own notification obligations as controllers of their end-customer data.

A documented incident-response plan covering roles, escalation, and post-incident review is being formalized. Specific notification mechanics for end-customer data flow through the merchant, who is the controller of that data.

SOC 2 alignment

HundredFold's controls are designed to align with the SOC 2 Trust Services Criteria (Security, and where applicable Availability and Confidentiality). A formal SOC 2 program is planned.

We want to be precise: HundredFold does not currently hold its own SOC 2 report. It is accurate that our core infrastructure providers, Supabase and Vercel, maintain SOC 2 Type II reports, and that we design our own controls to align with the same criteria. We will update this page when our own audit status changes.

Responsible disclosure

We welcome reports from security researchers and the community. If you believe you have found a vulnerability in HundredFold, please email admin@gohundredfold.com with enough detail to reproduce the issue.

We ask that you:

• give us a reasonable opportunity to investigate and remediate before any public disclosure;
• avoid accessing, modifying, or deleting data that is not your own, and avoid degrading service for others;
• not run automated testing that could disrupt the service.

We will acknowledge your report, keep you informed of our progress, and work in good faith to resolve confirmed issues promptly. We do not currently operate a paid bug-bounty program, but we will not pursue legal action against researchers who act in good faith and follow this policy.

Contact

• Security, vulnerability reports, and privacy inquiries: admin@gohundredfold.com
• Legal entity and registered address: Heem Megacorp LLC, 8500 Blazyk Drive, Austin, Texas 78737
• Governing law / jurisdiction: State of Texas, USA