Security

JestBot handles two categories of sensitive data by design: the content you feed into a bot’s knowledge base (which may include internal documentation, product details, or customer-facing policy) and, if you use BYOK, your own API credentials for third-party model providers. Both are treated as sensitive by default, and the security choices below reflect that — encrypted storage, minimal retention beyond what’s needed to run your bots, and deletion that actually removes data rather than just hiding it.

All traffic between your browser, the embedded widget, and JestBot’s servers is encrypted via TLS. This covers the dashboard, agent panel, chat API, data API, and the widget’s streaming responses over SSE — there is no unencrypted HTTP path for any of these in production.

Sensitive fields are encrypted at rest rather than stored as plaintext in our database. This includes BYOK provider credentials (Section 4) and hashed — not encrypted-and- reversible, but one-way hashed — password and refresh-token storage, so that even database-level access doesn’t expose usable credentials directly.

If you add your own OpenAI, Anthropic, Gemini, Groq, or Mistral key to a bot, it’s encrypted with AES-256-GCM before it’s written to disk. The key is only decrypted in memory, per request, at the exact moment your bot needs to call that provider to answer a message — it is never logged in plaintext, never returned in any API response (including to your own dashboard after the initial save, which shows only a masked value), and never exposed client-side.

Dashboard and agent-panel sessions use short-lived (15 minute) JWT access tokens paired with a longer-lived (30 day) refresh token that’s stored hashed in our database, not in plaintext — so a database compromise alone doesn’t hand over usable long-lived sessions. Google sign-in is handled via Firebase Authentication rather than JestBot storing your Google credentials directly. Passwords, where used, go through standard salted hashing before storage; we never store or have access to your actual password.

Access within the platform is scoped by role: dashboard Users (account owners) are distinct from Agent accounts, which have their own login and are limited to the handover queue, assigned conversations, and canned responses — agents cannot access billing, API keys, or bots they haven’t been assigned to. Platform Admin accounts, used internally by JestBot, are separately gated and audited, and exist to support the platform rather than to browse customer content casually.

Every bot can be locked to a specific set of domains. Once configured, the widget script checks the embedding domain against that allowlist and will refuse to render or respond on any domain not on the list — this prevents your bot’s public key from being copied and reused to serve your bot (and potentially your knowledge base’s content) on a site you don’t control.

Every bot’s documents, embeddings, and conversation history are logically scoped to that bot and its owning account. Retrieval queries at chat time are always scoped to the specific bot being queried — there is no cross-bot or cross-account retrieval path, by design, regardless of how similar two different customers’ content might be.

You can delete a single document, an entire bot, or your whole account at any time. Document deletion removes that document’s stored content and its associated vector embeddings from the retrieval index. Account deletion cascades further — it removes your bots, documents, embeddings, conversation history, and leads. Deletion is not reversible once processed, and we don’t retain deleted content for model training or any other secondary purpose.

JestBot runs on managed cloud hosting infrastructure rather than self-managed physical servers, which means underlying host security (patching, physical security, network isolation) is backed by our hosting provider’s own security practices in addition to our application-level controls. See our Subprocessors page for the specific third parties involved.

We log application-level events (authentication attempts, API errors, billing events) for operational and security monitoring. Widget session analytics store hashed IPs rather than raw IP addresses, consistent with what’s described in our Privacy Policy. We monitor for anomalous access patterns — unusual login locations, abnormal API usage spikes, repeated authentication failures — as part of ongoing account security.

We maintain an internal process for triaging, containing, and disclosing security incidents: identify and contain the issue, assess what data (if any) was affected, fix the underlying cause, and notify affected account holders directly with what happened, what data was involved, and what we’re doing about it. Notification timelines follow applicable legal requirements for the type of data involved.

Internal access to customer data (bot content, conversation history, BYOK configuration) is limited to what’s necessary for support, debugging, and abuse investigation, and is not used for any purpose unrelated to operating the platform or responding to a specific support/compliance need. BYOK provider keys, specifically, are never accessible to us in decrypted form outside the automated, per-request decryption described in Section 4.

If you’ve found a security vulnerability in JestBot, please report it via the contact page with subject line “Security Report” rather than filing it publicly or testing it against other customers’ live data. Include enough detail to reproduce the issue. We’ll acknowledge reports, investigate promptly, and ask for a reasonable window to fix confirmed issues before any public disclosure.

JestBot does not currently hold SOC 2 or ISO 27001 certification. We are continuing to strengthen our security, privacy, and compliance practices as the platform grows. Organizations that require additional security or compliance documentation may contact us for information about our current security practices and available documentation.