Security and compliance

This page is written for the person doing chatbot security due diligence. It says what we have, what we do not have, and what we are doing about the gap, because a security review that discovers a missing report is worse for both of us than a page that states it.

What we have not certified

We hold no SOC 2 report and no ISO 27001 certificate, and we have not yet commissioned an external penetration test. If either report is a hard requirement for your procurement, we are not the right choice this quarter. What we can give you is the architecture below, a signable data processing agreement and a named engineer to answer your questionnaire. The data processing agreement is on this site, and our security contact is in /.well-known/security.txt.

Certifications and status

Certification status as of 23 September 2026
FrameworkStatusDetail
SOC 2 Type II Not started Planned. We will publish the observation window when an auditor is engaged.
ISO/IEC 27001 Not started No certificate today. We will not claim alignment as a substitute for one.
GDPR Applicable We act as processor for visitor conversations. A DPA with SCCs is available and signable.
India DPDP Act Applicable Notice, grievance route and Data Protection Officer named in our DPDP notice.
EU AI Act Article 50 In scope, met AI disclosure on by default, before the first assistant message, not silently removable by a tenant. Held by a test in our build rather than by intent: a store that sends an empty disclosure gets the default back, and no stylesheet rule may hide the line.
Penetration test Not yet commissioned First external test scheduled before general availability. We will publish the summary letter.

What we check, and when

A claim nothing tests is a sentence. These run on our own machines and in our build, and each one fails the build rather than filing a warning somebody reads later.

The automated security checks, what each one proves, and when it runs
CheckWhat it provesWhen
Tenant isolation One store's conversations, products and settings cannot be read with another store's session. Every route is scoped, and the scoping is tested. Every push
Secrets never readable Store tokens, model keys and two-factor secrets round-trip through encryption and never appear in the stored bytes or in a log. Every push
Outbound request guard A store URL that resolves to a private address, a loopback address or a cloud metadata service is refused, including after a redirect. Every push
AI disclosure The line that tells a visitor they are talking to an assistant cannot be blanked by a store, and no stylesheet rule hides it at any screen size. Every push
Dependency advisories No package we ship, in either language, has a known vulnerability. Every push, and weekly
Secret scan No key, token or private key has been committed to the repository. Every push, and weekly
Live headers and refusals The running service still sends its security headers, and every private endpoint still refuses a caller with no session. Every release
Upload identification An upload is identified by its own bytes, never by its name or the type it claims. Files that can carry script are refused. Every push

Result on 23 September 2026: every check above passed, and no package in the product or in the tooling that builds it has a known vulnerability. When one appears, this line changes before anything else does.

How your data is protected

  • Secrets encrypted at rest

    Tool credentials, store access tokens and two-factor secrets are encrypted with AES-256-GCM and never returned to the browser once saved.

  • API keys stored hashed

    A leaked database would not reveal a usable key.

  • Two-factor sign-in

    Available for every merchant account and for our own staff accounts.

  • An audit log

    Every staff action that touches a customer's workspace is recorded before it runs, including viewing a workspace to give support.

  • Workspace isolation

    Every query is scoped to its workspace, so one store's catalogue can never reach another store's assistant.

How the assistant protects your site

  • Allowed origins

    Your assistant answers only on the websites you list; requests from anywhere else are refused and shown to you.

  • No reaching into private networks

    Crawls and custom tools can never be pointed at internal or private addresses.

  • Rate limits

    Per visitor and per key, so a script cannot run up your bill or slow your assistant for real shoppers.

  • Checked payments

    Payment notifications are verified by signature, and the amount paid is checked.

Sub-processors

The full list, with change notifications you can subscribe to, is on the sub-processor page.

Sub-processors and their locations
ProcessorPurposeLocation
Model provider Generates answers from your content United States
Cloud host Runs the service and stores your data India (Bengaluru, DigitalOcean)
Payment processor Billing. We never see a full card number. Varies by method
Email provider Transactional mail, invites, resets, receipts United States
OpenStreetMap Nominatim Turns coordinates into a locality, only when a visitor presses the find-my-nearest-store button European Union

Practicalities

Your control over conversations

You choose how long conversations are kept, and you can delete any single conversation from the console. Shoppers are told they are talking to an AI before the first reply, and can end a chat at any time.

Residency, retention, access

The full retention table is in the privacy policy.

  • Data residency

    Customer content, conversations and traces are stored in India (Bengaluru, DigitalOcean). Generating an answer sends the question, the retrieved excerpts and your instructions to a model provider that may process them in the United States. That hop is inherent to using a hosted model, and we would rather name it than describe ourselves as India-only. If you need in-region inference, tell us what your requirement is and we will tell you honestly whether we can meet it.

  • Retention and deletion

    Conversations are kept until someone deletes them. A workspace can set a period — 30, 90, 180 or 365 days — and an admin applies it by running the purge in the console, which deletes everything older in one go. We do not run that purge for you on a schedule, and we would rather say so than let a setting imply a deletion nobody performs. Deleting a conversation removes its messages and its retrieval traces with it, and is not reversible. Deleting a workspace deletes its content at once. A deleted row can still sit in an encrypted backup for up to 30 days, after which the backup itself is gone.

  • Access control

    Workspaces carry three roles, admin, editor and viewer. Roles are recorded and shown throughout the console; per-role server-side enforcement ships with SSO, and until then an admin should treat editor access as trusted.

Questionnaires and reviews

Send us your security questionnaire and we will answer it in writing, with a named engineer, and tell you plainly where an answer is “no”. The contact page reaches us.

Reporting a problem

If you find a vulnerability, our responsible disclosure policy explains how to report it. We acknowledge reports within two working days.

Write to our contact form. Our machine-readable contact is at /.well-known/security.txt.

Documents

The data processing agreement, the sub-processor list, the India DPDP notice and our responsible disclosure policy are linked below and are kept current.

The awkward questions

Answered here rather than at the security review, including the ones where the answer is no.

How long do you keep our conversations?

Until someone deletes them. A workspace can set a retention period of 30, 90, 180 or 365 days, and an admin applies it by running the purge in the console; we do not delete your conversations on a schedule of our own. Deleted rows can remain in an encrypted backup for up to 30 days. If automatic deletion on a fixed schedule is a requirement for you, tell us — it is a change we would make for a customer who needs it, not a claim we will make before it is true.

Are you SOC 2 or ISO 27001 certified?

No, and neither is in progress. There is no SOC 2 report, no ISO 27001 certificate and no published VPAT. If your procurement requires one, we would rather you knew now than after a trial.

Where is our data stored?

In India. Answer generation is the exception: the visitor's question and the excerpts retrieved for it are sent to a model provider that may process them outside India. That is the one boundary worth reading carefully before you decide.

Can the assistant invent an answer about our business?

It is constrained to answer only from what was retrieved from your own content, and to say it does not know and offer a human otherwise. When it answers without grounding, that turn is recorded as a gap you can review rather than passing unnoticed.

Who can see our conversations?

Your own team, through your console. Support access is separate, logged, and read-only: a staff session opened against your workspace cannot write anything, and every one is recorded in an audit log we can show you.

Do you track our visitors?

There are no third-party scripts on this website, and the widget loads nothing beyond itself. Visitor identity is not signed, so treat a conversation as belonging to a browser rather than a verified person.

Get the DPA

Signable, with SCCs, and a named engineer to answer the questionnaire that follows it.