Trust & security

Built to hold as little as possible, and to protect the rest.

This page describes the architecture as it is built today. It makes no certification claim, and where a control is configured per deployment, it says so.

Personal health information

  • Inbound text is redacted for personal identifiers before retrieval or generation, and every answer is checked for personal health information after it is generated, with the result recorded.
  • These guardrails are set at the platform level. No deployment’s configuration can switch them off.
  • Visitors to an embedded assistant need no account. Each visit is its own anonymous session, isolated from every other visitor, with no memory carried between sessions.

Isolation between deployments

  • Each deployment has its own public key, bound to the origins you nominate. A key lifted from your page does not work anywhere else.
  • A deployment can be restricted to a defined portfolio or to its own private content. That scope is enforced during retrieval, not filtered afterwards, and covered by cross-tenant isolation tests.
  • Feature flags, prompt configuration, webhooks and pharmacovigilance routing are set per deployment.

Infrastructure

  • Hosted on Amazon Web Services in the United States (us-east-1).
  • Only web traffic reaches the application host. There is no SSH access; operators reach it through AWS Systems Manager.
  • Data volumes are encrypted at rest, and traffic is encrypted in transit with TLS.
  • The database is backed up nightly to encrypted storage and kept for 30 days, alongside daily volume snapshots kept for 7.

Audit and governance

  • Events are written to an append-only audit log. Each deployment’s administrators can read and export their own entries, with a hash chain that shows whether the log has been altered.
  • Possible adverse events are flagged by category, with detection and routing configured per deployment.
  • How content is sourced, graded and corrected is set out in the editorial policy.
Read the editorial policy →

Models and providers

  • Answers are generated by Anthropic models; search embeddings are produced by Voyage AI; the platform runs on Amazon Web Services.
  • OpenSupport does not train models on your conversations. Questions reach our model providers with personal identifiers already redacted, under each provider’s data terms.
  • The full, current list of subprocessors, with their data terms, is available on request.

Reporting a vulnerability

If you believe you have found a security issue, email founder@opensupport.me with the details. Please give us a reasonable chance to fix it before disclosing it publicly. The same contact is published in security.txt.

Questions we get asked

Straight answers.

Do you hold a security certification?
Not today. This page describes the architecture as it is built, and we answer security questionnaires on request.
Where is data hosted?
On Amazon Web Services, in the us-east-1 region in the United States.
Are our conversations used to train models?
OpenSupport does not train models on them. Questions are sent to our model providers with personal identifiers already redacted, under each provider’s data terms, which the subprocessor list sets out.

Bring your security questionnaire.

We will walk your security and procurement teams through the architecture behind every answer.

Request a demo Try it live