Security Policy
Effective date: 24 August 2026
BOTVEE (PRIVATE) LIMITED · SECP: 0326112 · FBR: I510669
Standards Alignment
Our security practices are guided by the OWASP Top 10, the NIST Cybersecurity Framework (CSF 2.0), CIS Controls v8, the principles of ISO/IEC 27001, PECA 2016, the Pakistan National Cyber Security Policy, and PKCERT guidance. Botvee's platform runs on established cloud infrastructure providers (Microsoft Azure and Vercel) that maintain their own security and compliance programs; Botvee itself follows recognised security principles but does not claim to be independently SOC 2 or ISO 27001 certified. No security measure can guarantee absolute security.
Our Commitment
BOTVEE (PRIVATE) LIMITED treats data security as a core obligation. This Policy describes the technical and organisational measures we use to protect personal data, platform integrity, and service availability. Because no method of transmission or storage is completely secure, we cannot guarantee absolute security; we commit to applying appropriate, industry-recognised measures.
Encryption
- In transit: the platform and API are served over HTTPS only, using TLS 1.2 or above (TLS 1.3 where the browser supports it), terminated by our hosting provider.
- At rest: AES-256 encryption for stored personal data and database contents, provided through our cloud database and storage infrastructure.
- Passwords: hashed with bcrypt; never stored or accessible in readable form, by anyone, including Botvee staff. New and changed passwords are also checked against known breach corpora and rejected if they appear in one.
- Integration tokens & secrets: third-party access tokens — Google, WhatsApp, Shopify, Telegram, and connected email accounts — are encrypted at rest with AES-256-GCM before being written to the database. Application secrets are held in the environment and not committed to source control.
Note on "end-to-end encryption". Because the Service must read message content to generate AI responses, the Service uses encryption in transit and at rest — it does not provide end-to-end encryption in the technical sense (where no intermediary can read content).
Access Controls
- Workspace role-based access control: customer workspaces support owner, admin, agent, and viewer roles that scope exactly what each teammate can see and do (for example, sensitive actions such as data erasure require an owner/admin).
- Database-enforced tenant isolation. Separation between workspaces does not rest on application code alone. Each request opens its transaction by declaring which workspace it belongs to, and PostgreSQL row-level security policies then restrict what that transaction can read or write. A query that forgot its workspace filter returns nothing rather than another customer's data.
- Two-factor authentication (TOTP) is available for account access, with recovery codes, and repeated wrong codes are locked out.
- Passkeys (WebAuthn). You can register a passkey — a platform authenticator such as Face ID, Touch ID, or Windows Hello, or a hardware security key — and sign in without a password. Passkeys are phishing-resistant: the credential is bound to botvee.ai and cannot be replayed on a lookalike site.
- Step-up re-authentication. Sensitive areas — billing, API keys, and integrations — require you to prove yourself again within the last 15 minutes, no matter how recently you signed in. The proof is a short-lived, signed token in its own cookie, separate from the session.
- Sign out everywhere. You can invalidate every existing session at once; tokens issued before that moment stop working immediately, on every device.
- Login-device recognition. Each sign-in is matched against a device identifier derived from your browser family and a hashed IP address — the IP itself is never stored in readable form. You can review and remove recognised devices in your security settings.
- Internal access follows the principle of least privilege; staff access only what their role requires. We use reputable managed infrastructure providers (Microsoft Azure, Supabase, Vercel) whose consoles support strong authentication for administrative access.
- Audit logging: key actions and security-relevant events are recorded with actor, workspace, and event details, and the log is itself workspace-scoped.
Infrastructure Security
- Primary database, vector database (knowledge-base embeddings), and file storage: Supabase. Backend application hosting: Microsoft Azure. Frontend hosting and edge network: Vercel. These providers maintain their own security and compliance programs, including managed encryption and platform-level protections.
- Edge network and DDoS mitigation via hosting infrastructure.
- SQL injection: every database query is parameterised — user input is passed as a bound value and never concatenated into SQL.
- Cross-site scripting: the interface is React, which escapes rendered values by default.
- Server-side request forgery: the website crawler resolves each URL before fetching it and refuses loopback, private, link-local, CGNAT, and cloud-metadata addresses (such as 169.254.169.254), re-checking after DNS resolution so a hostname cannot be pointed at internal infrastructure.
- Inbound webhooks are authenticated before they are trusted: Shopify and Meta webhooks are HMAC-verified with a constant-time comparison, Stripe events are verified against their signing secret, and each Telegram bot carries its own per-bot secret. An unsigned or mis-signed request is rejected before any work is done.
- Response headers set on every route include X-Content-Type-Options: nosniff, a restrictive Referrer-Policy, Permissions-Policy denying camera, microphone, geolocation and payment, and X-Frame-Options everywhere except the page that must load inside the Shopify Admin iframe.
- Rate limiting on authentication and public endpoints, and integration-health checks surfaced in the dashboard.
Secure Development
- Secure-coding practices aligned with the OWASP Top 10.
- Input validation and output handling on user-facing and API inputs.
- Use of managed, reputable infrastructure providers for hosting, database, and storage.
Backup and Business Continuity
- Backups are provided through our managed cloud database infrastructure (Supabase), which performs automated backups of the database.
- We rely on the resilience and recovery capabilities of our infrastructure providers for continuity.
- Recovery objectives are operational targets, not guarantees, and depend in part on our infrastructure providers.
Incident Response
7.1 Process
Detection (monitoring/alerts) → triage and containment → assessment of scope and impact → notification (see 7.2) → remediation → post-incident review.
7.2 Breach notification (roles matter)
- Where Botvee is a processor (customer End-User data): Botvee notifies the affected customer (controller) without undue delay, so the controller can meet its own obligations (including GDPR Art. 33's 72-hour timeframe). The controller is responsible for notifying its End-Users and any supervisory authority.
- Where Botvee is a controller (its own account/website data): Botvee notifies the relevant supervisory authority where required (including within 72 hours where GDPR Art. 33 applies) and affected individuals where a breach is likely to result in a high risk to their rights and freedoms.
- Pakistan: notification to the FIA Cybercrime Wing and PKCERT where required by applicable law.
- Incidents are recorded internally regardless of whether they meet notification thresholds.
Sub-Processor Security
The Service relies on established providers, including Supabase (primary database, vector database, and file storage), Microsoft Azure (backend hosting), Vercel (frontend hosting), Stripe (PCI-DSS Level 1 payments), our AI provider (OpenAI), Resend (email), and — where enabled — channel and integration providers. Payment-card data is handled by Stripe and is not stored by Botvee. Under current provider terms, data sent to our AI provider's API is not used to train its models by default. The current list is at Sub-Processors.
Responsible Disclosure
Security researchers may report vulnerabilities to security@botvee.ai (subject: "Security Vulnerability Report"). We commit to acknowledge within a reasonable time, investigate and respond, and not pursue legal action against good-faith researchers who act responsibly and within the law.
Your Security Responsibilities
- Use a strong, unique password. If it is rejected at sign-up, it is because it appeared in a known breach corpus — choose another rather than a variation of it.
- Enable two-factor authentication and store recovery codes safely, or register a passkey, which is stronger still because it cannot be phished.
- Review your recognised devices from time to time, and use "sign out everywhere" if one looks unfamiliar.
- Keep credentials confidential.
- Report suspected issues to security@botvee.ai.
- Avoid accessing the Service on unsecured public Wi-Fi without a trusted VPN.
Applicable Standards and Laws
- Pakistan: PECA 2016, Constitution Art. 14, Personal Data Protection Bill principles (as/when enacted), National Cyber Security Policy, PKCERT guidance.
- EU/UK: GDPR Art. 32 (appropriate technical and organisational measures), UK GDPR.
- International: NIST CSF 2.0, CIS Controls v8, ISO/IEC 27001 principles (not certified).
- Payment: PCI-DSS (implemented via Stripe).
Contact
Security Reports
Legal
Support
Company
BOTVEE (PRIVATE) LIMITED