Security
Security is not a feature we ship - it is the condition everything else runs on. This page explains, in plain language, how we protect your workspace, your customers' conversations and your payment details.
Effective 22 October 2026 · Applies to sajamaone.com and the Sajama One app.
How your data is protected
All traffic between your browser, your customers' browsers and Sajama One is encrypted in transit using TLS. Your data is stored on infrastructure that encrypts at rest by default, and we review the configuration of that infrastructure as part of our release process.
We keep the amount of data we collect to what the product needs to work. The website widget, for example, does not read or transmit your visitor's page history, query strings or timezone - it sends only what is required to open a conversation. Optional location counting on our own public website is off unless a visitor allows it; it produces only anonymous daily country/region totals, while the consent receipt is stored as a one-way hash and is not linked to an account.
Workspace isolation and access control
Each workspace's conversations, contacts and settings belong to that workspace alone. Access is enforced in the application and at the database layer with workspace-scoped row-level security, so cross-workspace requests are denied rather than merely hidden in the interface. Within a workspace, access is further scoped by team and role.
Administrative and internal tooling is separated from customer-facing surfaces and requires its own authorization. Sensitive credentials - channel tokens, CRM tokens and server keys - are held server-side only, are encrypted at rest (AES-256-GCM) in our database, and are never sent to a browser or included in workspace exports. Webhook deliveries from channel platforms are signature-verified before anything is accepted, and login codes are stored as keyed hashes, never in plain text.
Authentication
Sign-in supports passwords managed by our authentication provider and, where configured, Google or Microsoft sign-in. Every user can add authenticator-based two-step verification, and a workspace owner can require it for everyone at once (Settings, then Security); access to our internal platform console always requires that second step. One-time codes used for invitations and password resets are stored as keyed hashes, expire quickly, are purpose-scoped and single-use, and are rate-limited against guessing. A successful password reset revokes the account's existing sessions. If you believe your account has been accessed without your permission, contact us immediately and we will secure it with you.
Attachments and uploads
Files shared in conversations are stored privately, are size-limited, and are checked by filename, declared type and actual contents before being accepted. Executables, scripts, active PDFs and macro-capable or otherwise unsafe Office files are rejected. In production, an attachment is accepted only after the configured malware scanner reports it clean; if scanning is unavailable, the upload fails closed. Documents used for assistant training are parsed into inert text under strict size and structure limits and are never executed. Links to attachments are short-lived and signed, and non-image files are delivered as downloads with a safe canonical filename.
Payments
Payments are processed by our payment provider, Lemon Squeezy, which acts as the merchant of record. We never see or store your full card number; it goes directly to the payment provider over their own secure checkout. Plan changes and renewals are confirmed to us by the provider through signed, verified messages - a change cannot be made by the browser alone.
Voice calls and SMS gateways
In-widget voice calls are peer-to-peer: audio flows directly between the visitor's and the agent's browsers and never passes through our servers, so there is nothing for us to record or leak - we keep only call metadata (times, answered or missed). The Android SMS channel works through a gateway phone that you own and control; texts travel over your carrier's network exactly like texts from that phone normally would.
Our assistants and your content
The answers Sajama One suggests are drawn from the knowledge you add to your own workspace. Your training content is scoped to your workspace and is not shared with, or used to answer for, any other customer.
Audit trail
Owners and admins can read who changed what in the workspace - who was invited, who had a role changed, which API key was created, when the sign-in policy changed - at Settings, then Security activity. The record is append-only at the database level, kept for 12 months, and included in the workspace export.
Independent assurance
We do not currently hold SOC 2 or ISO 27001 certification, and we do not describe our internal controls as a substitute for an audit. Enterprise reviewers can contact us for a current, evidence-based account of the controls and deployment checks that apply to their workspace. The data processing agreement and the subprocessor list are published, and support hours and response targets are stated rather than implied.
Report a vulnerability
If you believe you have found a security issue, we want to hear about it. Email support@sajamaone.com with the subject “Security” and a short description of what you found. Please avoid accessing or changing data that is not yours, and give us a reasonable window to investigate and fix before publishing anything. We will acknowledge your report and keep you informed.
Questions?
If anything on this page is unclear, write to support@sajamaone.com. We answer within two days.