Security Policy

Least privilege, and fail closed.Every access path starts from “denied” and is opened deliberately. When a control is ambiguous we choose the more restrictive option, because an over-restricted system is recoverable in an afternoon and a breach is not recoverable at all.

Each hosted assistant is a separate entity with its own configuration, its own corpus, and its own access rules. One client's assistant cannot read another's content, and cannot be induced to reveal another's configuration.

This is enforced in two places rather than one. Requests carry a tenant identity that is applied at the data layer, and a dedicated check runs on every build that fails the deployment if a code path could cross a tenant boundary. We added the second layer after finding that a carefully worded prompt could extract a system prompt by position rather than by name — a class of flaw that rule-based filtering alone did not catch.

All traffic is served over HTTPS only. The site is on the HSTS preload list, which means compliant browsers refuse to connect over plain HTTP even on a first visit — an attacker cannot downgrade the connection. A strict content security policy limits what may execute in the page, and framing is blocked except where an assistant widget is deliberately embedded.

Data at rest is encrypted by our database and hosting providers using their standard platform encryption. Conversation content is additionally subject to the 30-day retention rule — the strongest protection for data is not keeping it.

API keys and service credentials are held in a dedicated secret manager and injected at runtime. They are never committed to the repository, never written into client-side code, and never printed into logs. Every commit is scanned for accidentally included secrets before it lands.

Hosted assistants run behind a gateway layer that inspects both what goes in and what comes out. It screens incoming messages for prompt-injection patterns and scans outgoing responses for content that should not leave — the same mechanism that keeps one client's configuration from surfacing in another's conversation. Separately, per-assistant spending limits cap what any single deployment can consume, so a runaway loop or an abusive visitor cannot generate unbounded cost.

We do not hold SOC 2, ISO 27001, HIPAA, or PCI DSS certification. We are a small operator and have not undergone those audits. If your procurement process requires one, tell us before you buy rather than after — we would rather lose the deal than imply an attestation we do not have.

Card payments, when they go live, are handled entirely by our payment processor. Full card numbers do not reach our servers, which is what keeps our PCI scope minimal. This is described in Payment & Card Terms.

If we become aware of a security incident affecting client data, we will investigate immediately, contain it, and notify affected clients without undue delay and in any event within 72 hours of becoming aware of a personal data breach. That notification will describe what happened, what data was involved, what we have done, and what we recommend you do.

Where we act as a processor for a client, we notify the client so they can meet their own regulatory deadlines — under the GDPR, Thailand's PDPA, and US state breach laws the controller's clock starts when we tell them. The mechanics are in the Data Processing Addendum.

If you have found a flaw, please tell us — there is a safe harbour for good-faith research and a commitment to respond, set out in the Vulnerability Disclosure Policy. Reports go to [email protected].