Security at NebulaHex

NebulaHex Pvt Ltd builds and operates an AI-powered customer support and chatbot platform. This page describes the security controls we have in place to protect customer data, the trust posture of our infrastructure providers, and how to report security issues. It is a companion document to our Privacy Policy and Terms of Service.

We treat security as a product feature, not a checkbox. The controls described here are live in production today.

All customer data is encrypted at rest using AES-256 encryption. This includes the primary database (Postgres on Supabase), backups, and object storage.

All data in transit between your browser, our application, our APIs, and third-party providers is protected using TLS 1.2 or higher. We do not accept connections downgraded to plaintext or to older TLS versions.

Sensitive credentials — including OAuth tokens for connected integrations (Google, Salesforce, HubSpot, Shopify, Slack, Zendesk, Freshdesk, Zoho, Intercom), webhook secrets, and BYOK API keys — are encrypted at the application layer before storage using authenticated encryption with a key managed in our key management system. Token rotation is supported on a per-connector basis.

Customer authentication is handled by Clerk, our identity provider. Clerk supports password authentication, magic-link authentication, and a range of social identity providers. Multi-factor authentication is available to all users and required for accounts with billing access.

Within a workspace, NebulaHex enforces four roles:

• Owner: full workspace control including billing and member management.
• Admin: bot management, integration connections, and channel configuration.
• Editor: bot content and knowledge source editing.
• Viewer: read-only access to bots, conversations, and analytics.

Role assignments are enforced at the API layer on every request. Modifications to sensitive workspace settings (member roles, integration credentials, billing) are audit-logged.

NebulaHex employees do not access customer workspace data except in three documented circumstances:

• The customer has explicitly authorized access for a support case.
• An active security incident requires investigation.
• Compliance with a valid legal request.

In all three cases the access is logged, time-bounded, and accompanied by written justification.

All inbound webhooks from third-party providers are verified using the provider’s documented signature scheme:

• HMAC-SHA256 with raw-body signing for Paddle, Meta (WhatsApp/Instagram/Messenger), Shopify, and our own outbound webhooks.
• Replay-tolerance windows enforced per provider documentation (e.g., 5-second replay window for Paddle).
• Constant-time signature comparison to prevent timing attacks.

Outbound webhooks from NebulaHex to your downstream systems are signed with HMAC-SHA256 using a per-endpoint secret you can rotate from the dashboard. The signed payload is the exact request body bytes; signatures are verifiable using any standard HMAC-SHA256 library.

Webhook endpoints fail closed when signing secrets are absent or invalid, rather than accepting unsigned requests.

OAuth flows we initiate (Google, Slack, Shopify, HubSpot, Salesforce, Zendesk, Freshdesk, Zoho CRM, Zoho Desk, Intercom) use the authorization-code flow with PKCE where the provider supports it. We generate a cryptographically random state parameter on every authorization request and validate it on the callback, preventing CSRF attacks against the OAuth flow.

We request only the OAuth scopes necessary for the documented use case. Where a provider distinguishes read from read-write scopes, we default to read-only unless write is required (e.g., creating leads in HubSpot or tickets in Zendesk). Granted tokens are stored encrypted; refresh tokens are used to obtain new access tokens without re-prompting users.

Disconnect actions immediately invalidate the stored tokens and stop accessing the provider on your behalf within the same session.

Sensitive actions in your workspace are logged to an audit trail that survives 180 days. Logged actions include:

• Bot settings changes (persona, instructions, customization).
• Integration connections and disconnections.
• Channel connections and disconnections.
• Member role changes.
• Knowledge source additions and deletions.
• API key creation and revocation (including BYOK).
• Billing events (subscription changes, plan upgrades, payment events).

The audit log is accessible to Owners and Admins from the workspace dashboard. Audit log entries are immutable from the application UI; they can only be deleted by the retention cron (180 days) or by full workspace deletion.

Retention is enforced by a daily cleanup job. The job runs against an automated schedule, deletes audit log rows older than 180 days from the primary database, and reports a count of deleted rows.

NebulaHex runs on the following infrastructure providers:

• Vercel for application hosting (global edge network).
• Supabase for primary database (Postgres with pgvector for embeddings), Storage, and authentication-adjacent services. Our production database is hosted in the ap-south-1 region.
• Upstash for Redis-backed rate limiting and caching. Our production Upstash database is in ap-south-1.
• Resend for transactional email delivery (verified sender domain: nebulahex.com).

All infrastructure providers we rely on hold SOC 2 Type II attestations published on their respective trust pages.

See our Subprocessors page for the complete list of subprocessors, processing purposes, data categories, and regions.

We use a small number of subprocessors to deliver the Service: identity providers, database/storage providers, AI model providers, transactional email, billing, and selected functional integrations.

The complete, current list — including legal entity names, processing purposes, data categories, and regions — is published at our Subprocessors page. We update the list whenever a subprocessor changes; material changes are announced via email to workspace Owners with at least 30 days notice before the change takes effect, where practicable.

Each subprocessor is engaged under a contract that requires equivalent or stronger data protection commitments than the ones we make to you.

We maintain encrypted backups of the primary database. Backups are retained on a rolling schedule and used solely for disaster recovery — they are not used for analytics, exports, or any other purpose.

When customer data is permanently deleted from the primary database (either by your explicit action or by the retention cron), the corresponding backup data is purged within 90 days through normal backup rotation.

Our recovery objectives in the event of infrastructure failure are tracked internally and reviewed by NebulaHex leadership; specific RPO/RTO targets are available to enterprise customers under NDA.

We welcome security research and operate a coordinated disclosure program. To report a vulnerability:

• Email security@nebulahex.com with a description of the vulnerability, reproduction steps, and any proof-of-concept material.
• We acknowledge receipt within 2 business days.
• We aim to provide an initial assessment within 5 business days.
• We will coordinate disclosure timing with you for credited researchers.

Our published security contact is available at /.well-known/security.txt.

We do not currently offer monetary bounties. We do offer public acknowledgment with the researcher’s permission, and we treat coordinated disclosure as a sign of good faith.

If a security incident affecting customer data is confirmed, we will:

• Investigate and contain the incident as a priority.
• Notify affected customers via the email address associated with their workspace Owner role.
• Provide a description of what occurred, what data was affected, what steps we have taken, and what (if any) action affected customers should take.
• Provide notification within timeframes consistent with applicable law (GDPR Article 33: 72 hours from confirmed breach affecting personal data).

Customers can subscribe to security-incident notifications by contacting security@nebulahex.com.

NebulaHex Pvt Ltd does not currently hold an independent SOC 2, ISO 27001, or HIPAA attestation. We rely on:

• The attested infrastructure of our subprocessors (Vercel, Supabase, Upstash, Clerk, Paddle, Resend, Anthropic, OpenAI — see /subprocessors for each provider’s published attestations).
• Our own controls described on this page.
• Contractual commitments to enterprise customers via DPA (available on request — see Privacy Policy §06).

Customers requiring an attested security posture can negotiate enhanced contractual commitments through enterprise agreements. Contact legal@nebulahex.com to discuss.

This is the canonical security commitment on AI model training:

Customer data is never used to train, fine-tune, or improve any AI/ML model — by NebulaHex, by our AI model providers (Anthropic, OpenAI), or by any third party we engage. This commitment is established contractually through:

• Anthropic’s Commercial Terms of Service, which confirm Anthropic does not train on data submitted via its API.
• OpenAI’s API Data Usage Policy (effective March 2023), which confirms OpenAI does not train on data submitted via its API by default for API customers.
• Google’s Workspace API User Data Policy, which we follow verbatim for any data accessed via Google Sheets connector or other Google Workspace APIs.

If you use NebulaHex’s Bring Your Own Key (BYOK) feature, your conversation data passes through your own AI provider account on terms governed by your direct contract with that provider.

For the full legal expression of this commitment, see Privacy Policy §05a.

For security questions or vulnerability reports: security@nebulahex.com.

For security questionnaires or enterprise security commitments: legal@nebulahex.com.

For privacy and data-handling questions: privacy@nebulahex.com.