Documentation Index

Fetch the complete documentation index at: https://docs.kaanha.ai/llms.txt

Use this file to discover all available pages before exploring further.

​

Security & Compliance

​

Compliance Posture

Be precise about what we are and what we aren’t. This page does not market certifications we have not earned.

​

What we are

• GDPR-compliant — Articles 6, 13/14, 15–22, 28, 33, and 35 controls implemented; DPA available
• CCPA / CPRA-compliant — full California consumer rights with 45-day response window
• TCPA-compliant — prior-express-consent, STOP/HELP, quiet-hours, and DNC enforcement at the platform layer (cannot be overridden by tenants)
• Meta WhatsApp Business Policy-enforced — opt-in, opt-out, AI disclosure, and human escalation gated at the API layer
• CTIA Messaging Principles aligned for SMS
• Australian Privacy Act 1988 + Australian Privacy Principles (APP 1–13) aligned
• SOC 2-mapped — controls aligned to Trust Service Criteria CC6, CC7, CC8, A1, PI1

​

What we aren’t (yet)

• NOT SOC 2 Type II certified — full Type II audit is planned (target H2 2026)
• NOT ISO 27001 certified — under evaluation
• NOT HIPAA-compliant — Kaanha AI is not in scope for healthcare (PHI) workloads. Do not use the platform to transmit Protected Health Information
• PCI DSS is not directly handled — Stripe (PCI Level 1) processes all card data; Kaanha AI never sees card numbers

​

Legal Entity & Contacts

​

Authentication & Access Control

​

Login security

• NextAuth.js v4 session layer with JWT, 24-hour absolute maximum session age
• Sessions are immediately invalidated when a user changes their password (passwordChangedAt check)
• Passwords are hashed with bcrypt at cost factor 12
• Password policy: minimum 8 characters, must contain uppercase, lowercase, and a digit; cannot reuse any of the last 5 passwords
• Account lockout: 5 consecutive failed login attempts trigger a 30-minute lock; the counter resets on successful login or password reset
• All failed-login attempts are written to the audit trail with email, IP, and attempt count

​

Multi-factor authentication (MFA)

• Backup codes: 10 single-use codes are generated at setup. Use one to regain access if you lose your authenticator, then reconfigure MFA immediately
• Brute-force protection: 5 verification attempts per 15-minute window per userId (keyed on the server-resolved user ID, not IP or email — defeats NAT-rotation and email-spoofing bypasses)
• On exceedance the platform returns HTTP 429 with Retry-After: 900 and writes MFA_RATE_LIMITED to the audit log
• The 5-attempts-per-15-minutes ceiling caps the searchable 6-digit TOTP space at 0.014% per window — well below brute-force feasibility

We strongly recommend all team members enable MFA, especially OWNER and ADMIN roles.

​

API keys

• Bearer-token authentication
• Optional expiry per key
• Last-used timestamp tracked
• Rotatable without service disruption
• Each key is scoped to a single organization — cross-tenant access is denied at the auth layer
• Key creation, rotation, and revocation events are written to the audit log

​

Data Encryption

​

At rest

• WhatsApp Cloud API access tokens
• Stripe / Razorpay / PayPal secret keys
• Slack bot/user tokens
• Voice provider keys (Sarvam, Deepgram, ElevenLabs, Twilio)
• Connect bridge credentials
• AI provider keys (OpenAI, Anthropic, Google)
• CRM and webhook secrets

​

In transit

• TLS 1.2+ enforced on every connection
• HSTS with max-age=31536000; includeSubDomains advertised on every response
• HTTP requests are redirected to HTTPS at the edge

​

Key management & rotation

• ENCRYPTION_KEY — current key
• ENCRYPTION_KEY_PREV — previous key

​

Password & token hashing

• User passwords: bcrypt at cost factor 12 — never stored or logged in plaintext
• Password reset tokens: stored as SHA-256 hashes — the raw token is sent only via email and is never retrievable after generation
• Email verification tokens: same SHA-256 hash treatment
• Plaintext credentials are never returned in any API response — they are masked

​

Multi-Tenant Isolation

• Query scoping: every database read and write is scoped to organizationId from the authenticated session. Cross-tenant queries are rejected at the API layer
• Composite unique constraints prevent ID collisions across organizations
• Webhook handlers verify HMAC signatures and map the inbound payload to the correct organization before any data is read or written
• API keys carry organization scope; an API key issued to Org A cannot read or write Org B
• Audit logs are partitioned by organizationId — admins of Org A cannot see Org B’s events
• Voice agents sync to the engine with organizationId baked into the agent ID space — call routing is unambiguous

​

Account Security & Hardening

​

Cross-site request forgery (CSRF)

​

Server-side request forgery (SSRF)

• Private IP ranges (RFC 1918, link-local, loopback)
• Cloud metadata endpoints (169.254.169.254, fd00:ec2::, etc.)
• localhost / 127.0.0.0/8 / ::1

​

Webhook signature verification

• Twilio — X-Twilio-Signature validated against full request URL + body
• Meta WhatsApp — X-Hub-Signature-256 validated against payload
• Stripe — Stripe signature verified before any payload action
• Voice engine callbacks — HMAC on /api/voice-agents/tool-call and /api/voice-agents/webhook with fail-closed behaviour (a missing or invalid signature returns 401 — there is no bypass for missing secrets)

​

Rate limiting

​

Account enumeration resistance

• Signup: when an email is already registered, the route returns a generic 200 success identical in shape to a brand-new signup. Timing is equalized via a constant-time bcrypt.hash (cost 12, ~200ms). Unique-constraint failures are mapped to the same generic 200
• Forgot-password: always returns the same success message regardless of registration status. The not-found branch performs a dummy bcrypt.hash (~80ms) to match the bcrypt-class work performed in the exists branch
• Result: no error message, status code, response shape, or response timing can be used to determine whether an email is registered

​

Security Headers

Strict-Transport-Security: max-age=31536000; includeSubDomains
Content-Security-Policy: frame-ancestors 'none'; base-uri 'self'
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin

​

Audit Logging

​

Data Retention

​

GDPR Compliance

​

Legal bases (Article 6)

• Contract — providing the platform you’ve subscribed to
• Legitimate interest — service security, fraud prevention, billing
• Consent — AI processing of message content (granular, revocable)
• Legal obligation — tax records, lawful access requests

​

Notice (Articles 13/14)

​

Data subject rights (Articles 15–22)

​

Data Processing Agreement (Article 28)

​

Breach notification (Article 33)

​

DPIA assistance (Article 35)

​

CCPA / CPRA Compliance

• Right to know — categories of personal information collected, sources, purposes, and recipients
• Right to delete — self-service via Profile → Privacy & Data
• Right to correct — edit profile and organization data in-product
• Right to opt out — Kaanha AI does not sell or share personal information for cross-context behavioral advertising; no opt-out is required because no sale occurs
• Right to non-discrimination — exercising rights does not affect service quality or pricing

​

Australian Privacy Act 1988 (APP)

​

WhatsApp Compliance (Meta Business Policy)

​

Opt-in enforcement

​

Opt-out automation

​

AI transparency (mandatory disclosure)

“You are chatting with an AI assistant. Reply HUMAN at any time to speak with a person.”

​

Human escalation guarantee

​

Marketing frequency cap

​

SMS Compliance (TCPA, CTIA, Twilio AUP)

• Prior express consent — opt-in is required before any SMS is sent
• STOP / HELP keywords processed automatically — STOP unsubscribes immediately, HELP returns brand and contact info
• CTIA Messaging Principles — content categories, frequency disclosures, registered short-code/10DLC compliance via Twilio
• Twilio Acceptable Use Policy — prohibited content (SHAFT, fraud, etc.) blocked at template approval
• Quiet hours — 8 PM – 8 AM recipient-local time honored on marketing campaigns

​

Voice Compliance (Rolling Out)

• TCPA — voice campaigns require prior express written consent; recorded-message restrictions enforced
• 2-party consent recording — call recording is opt-in for the contact; the AI agent announces recording at call start
• DNC (Do Not Call) — automated DNC list scrubbing before outbound dial
• AI disclosure — voice agent identifies itself as AI within the first 5 seconds (per California SB-1001 and platform policy)
• HMAC verification — engine callbacks (/api/voice-agents/tool-call, /api/voice-agents/webhook) require HMAC-SHA256; missing or invalid signatures return 401 with no bypass
• ENGINE_WS_SECRET fail-closed — the WebSocket bridge refuses connections without a valid secret; there is no missing-secret development bypass
• Twilio signature verification on the inbound voice webhook
• Per-call audit log with start, end, duration, agent, contact, outcome
• Real-time stream is TLS-encrypted between Twilio, the engine, and the AI providers
• Sub-processor disclosure — voice routes data through Sarvam, Deepgram, and Google (Gemini); fully disclosed at /sub-processors

​

AI Compliance

• Meta Business Platform — Task-Specific AI Policy (effective Jan 2026): AI models on the platform are restricted to task-specific assistance (customer service, knowledge retrieval, scheduling). General-purpose chat is not enabled by default. Prohibited categories (medical, legal, financial advice without disclaimer) are filtered
• EU AI Act: Kaanha AI’s AI features fall under the limited-risk classification — transparency obligation is satisfied by the mandatory AI disclosure described above
• California SB-1001 (Bot Disclosure Act): AI agents identify themselves as automated to California recipients
• Content safety filtering — provider-side moderation (OpenAI, Anthropic, Google) and platform-side keyword filters block prohibited content categories
• Customer control — every AI behavior knob (model, temperature, system prompt, allowed tools, knowledge sources) is UI-controllable per organization. There are no backend hardcoded overrides

​

Mobile App Security

• Authentication — bearer-token fallback for native clients; full session-equivalent protections
• Biometric login — Face ID / Touch ID. The biometric template is stored on-device only in the Apple Secure Enclave or Android Trusted Execution Environment; it is never transmitted to Kaanha AI servers
• Push notifications — delivered via Expo Push Service to Apple APNs and Google FCM. Push payloads do not contain message bodies — they trigger an authenticated fetch
• Offline mode — local cache is encrypted at rest using OS-provided storage (iOS Keychain / Android Keystore)
• App Store distribution — submitted and verified through Apple App Store Connect and Google Play Console with full Data Safety / Privacy disclosures

​

Sub-Processors

Notice & objection: customers receive at least 30 days’ notice before any new sub-processor is added or replaced, with the right to object. Email privacy@kaanha.ai.

​

Vulnerability Management & Penetration Testing

• Dependency scanning: npm audit --audit-level=high runs in CI on every pull request and weekly via GitHub Actions
• Code review: required for every change merged to the main branch
• Static analysis: linting and type-check gates on CI
• Penetration testing: annual third-party penetration test (planned / in progress)
• Bug bounty: responsible disclosure at security@kaanha.ai; see Responsible Disclosure below

​

Incident Response

• Acknowledgement of disclosed vulnerabilities within 48 hours
• Critical fixes targeted within 7 days of confirmation
• Customer breach notification within 72 hours of becoming aware of a personal-data breach (per GDPR Art. 33)
• Internal incident runbook documented at docs/incident-response.md
• Post-incident reports delivered to affected customers, including: scope, root cause, remediation, and preventive measures
• Status page: status.kaanha.ai for real-time service updates

​

Backup & Recovery

​

File Upload Security

• MIME whitelist — only allowed content types accepted
• Magic-byte verification — file content is sniffed and matched against the declared MIME (a .png with executable bytes is rejected)
• Size limits per file type (image, audio, video, document) tuned to channel constraints
• Virus scanning where enabled per deployment
• Origin validation — files served from media routes carry strict CSP and content-type headers

​

Compliance Roadmap

​

Responsible Disclosure

• Email: security@kaanha.ai
• Do not open a public GitHub issue or post on social media before we’ve had a chance to investigate and remediate

• Description of the vulnerability
• Steps to reproduce
• Impact assessment
• Suggested fix (if any)

• Acknowledge your report within 48 hours
• Provide a resolution timeline within 5 business days for critical issues
• Target 7 days for critical fixes
• Credit researchers who responsibly disclose (if desired)

​

Customer’s Compliance Responsibilities

• Maintaining opt-in records for every contact you message via WhatsApp, SMS, or voice. Kaanha AI’s opt-in field reflects your record-keeping; the burden of proof is yours
• Adhering to the Acceptable Use Policy (/aup) — no SHAFT content, fraud, scams, or harassment
• Configuring AI agents responsibly — system prompts, allowed tools, knowledge-base scope. AI hallucinations or off-policy outputs caused by misconfiguration are your responsibility
• Passing through data subject rights — when your end-users invoke GDPR / CCPA rights against you, you must propagate the action via Kaanha AI’s tools (or via privacy@kaanha.ai for assisted handling)
• Configuring data retention to match your jurisdiction’s requirements (some jurisdictions require longer or shorter retention than our defaults)
• Securing your team’s accounts — enabling MFA, rotating API keys, removing departed users
• Disclosure to your end-users — your privacy notice must accurately describe your use of Kaanha AI

​

Cross-References