Legal

Security

How the platform is built to keep tenants separate and data protected.

Last updated 4 September 2026

This is a template, not legal advice. It describes how the software actually behaves, which is the part we can state accurately. Before relying on it commercially, have a lawyer review it against your jurisdiction, your sub-processors and your real retention practice.

This describes the controls that are actually implemented, not aspirations. Where something is in progress it says so.

Tenant isolation

Every record carries a workspace identifier, and every query is scoped to the workspace of the authenticated caller before it runs. Identifiers supplied by a client are re-checked against that workspace on every mutation — a guessed id from another tenant returns 404, not data.

Vector search filters by chatbot before the nearest-neighbour scan, so one customer's embeddings cannot surface in another customer's answers.

Encryption

Traffic uses TLS. Data at rest is encrypted by the storage layer. On top of that, integration credentials and TOTP secrets are sealed with AES-256-GCM authenticated encryption using a key held outside the database — so a database dump on its own reveals nothing usable.

Passwords are hashed with bcrypt. API keys are stored only as SHA-256 hashes and looked up by a public prefix, so reading the database never yields a working key.

Access control

Five workspace roles form a strict privilege hierarchy. Billing and workspace deletion are restricted to owners. Every permission is enforced on the server for every action; hiding a control in the interface is never the only check.

Two-factor authentication is available on all accounts, with single-use backup codes. Changing a password ends every other session.

The embedded widget

The chat runs inside an iframe on our origin, so a host page's styles cannot leak in and the widget cannot read the host page's DOM. The only channel between them is a narrow message protocol where both sides verify the origin.

Chatbots can be restricted to a list of domains. The public embed key identifies a chatbot; it does not authenticate, which is why domain restriction matters and why the public configuration endpoint returns presentation data only — never your instructions, model or retrieval settings.

Operational controls

Rate limiting per visitor, per API key and per authentication identifier.
An immutable audit log of privileged actions, visible to workspace admins.
Webhook events recorded before processing, so a redelivery cannot be applied twice.
Exported CSV cells are neutralised against spreadsheet formula injection.
Automated dependency and type checking, with a test suite covering the authorisation matrix.

Reporting a vulnerability

If you believe you have found a security issue, contact us before disclosing it publicly. We will acknowledge within two business days. Please do not run automated scans against production or access data that is not yours.

Certifications

We are not currently certified against SOC 2 or ISO 27001. The controls above are implemented, but they have not been audited by a third party, and we will not claim otherwise.

Who we are and how to reach us

BotForge is operated by Onzira Labs Private Limited ("Onzira Labs", "we", "us"), a company incorporated in India (CIN U62011DL2025PTC447666, GSTIN 07AAECO7169F1Z8).

Registered office: 293, Lane-2, Westend Marg, Saket, New Delhi 110030, India.

Questions about this document: support@onzira.com or +91 7631 995 541.

Governing law

This document is governed by the laws of India. Any dispute is subject to the exclusive jurisdiction of the courts of New Delhi, India, without prejudice to any mandatory consumer or data-protection rights you hold where you live.