Trust

Security

Security is a feature, not a footnote. Here's how Saaya is built and operated to keep your data and your end users' conversations safe.

Security is built into how we ship Saaya, not bolted on afterwards. The trust required to process voice, video, and chat for production AI agents is the foundation of the product — if we get this wrong, nothing else matters.

Saaya is an Indian startup, governed by Indian law. Our security posture is calibrated to the Information Technology Act, 2000, the IT (Reasonable Security Practices and Procedures and Sensitive Personal Data or Information) Rules, 2011, the Digital Personal Data Protection Act, 2023 (DPDP Act), and the CERT-In Directions, April 2022. This page is honest about where we are. We are an early-stage company. Some controls are in place today, some are in active rollout, and some recognised international audits are explicitly on a 2026 roadmap. We tell you which is which.

Our approach

  • Security is a feature. Engineering ships features and security improvements through the same code-review and testing pipeline. There is no "security backlog" that we ignore.
  • Customer data is held in trust. We do not train Saaya's own models on Customer Data. We do not sell or repurpose it. We use it to run the agents you build, support you, and keep the Service safe.
  • Be honest about what we have. We name the controls we operate today and flag the ones we are working toward. We do not claim certifications we haven't earned.

Infrastructure

Saaya runs on managed cloud infrastructure with isolated production and development environments:

  • The marketing site (saaya.ai) is statically rendered and served via a global CDN.
  • The dashboard (app.saaya.ai) is a single-page application served via the same CDN, with strict transport-security and content-security headers.
  • The FastAPI backend, the LiveKit-based real-time worker fleet, and the data stores run inside a private network with restricted ingress.
  • Production and non-production environments are isolated from each other.

Encryption

  • In transit. All traffic between your browser, the dashboard, our APIs, and our backend services is protected by TLS 1.2 or higher. We enforce HSTS on the dashboard so browsers refuse to downgrade to plaintext. Internal service-to-service traffic stays inside the hosting provider's private network.
  • At rest. Production databases (Postgres, MongoDB, Redis, Qdrant) and object storage are hosted on managed infrastructure that provides AES-256-class encryption at rest at the volume level. Backups inherit the same protection.
  • Voice and video media. Real-time media streams are protected with DTLS-SRTP through LiveKit. Session recordings, where you choose to retain them, are encrypted at rest along with the rest of the data plane.

Authentication

The dashboard authenticates with email and password against our FastAPI backend, which issues short-lived JWT access tokens and longer-lived refresh tokens. Passwords are hashed with a modern algorithm (bcrypt or Argon2 family, configurable) — we never store them in plaintext.

Optional two-factor authentication (TOTP) is available to customer accounts. For internal team access, multi-factor authentication is required on every system that touches production.

Access control

Authorisation is enforced server-side with a two-level role-based access control model:

  • System roles — SUPER_ADMIN and USER — gate platform-wide capabilities.
  • Organisation roles — OWNER, ADMIN, MEMBER, VIEWER — gate workspace-level capabilities. Every authenticated request is scoped by an X-Organization-Id header so a workspace cannot read or write across another workspace's data, ever.

We expose 23 fine-grained permissions on top of those roles so customers can model real-world separations of duty (for example, who can edit prompts versus who can review session recordings). Workspace owners can invite, suspend, and revoke Users from the team-management view in the dashboard.

Internal team access to production follows the principle of least privilege: engineers do not have standing access to customer data; access is granted just-in-time for incidents and is logged and reviewed.

Audit logging

Sensitive actions — sign-in, agent creation and edits, knowledge-base writes, permission changes, exports — are written to an append-only audit log keyed by user, organisation, action, and timestamp. Audit logs are retained for the period stated in the Data Processing Agreement.

Monitoring & incident response

  • Application errors are monitored with Sentry; production incidents page the on-call engineer.
  • Request latency, availability, and saturation are tracked via Loki and Grafana with alerting on critical metrics.
  • We run synthetic end-to-end checks against the dashboard and the API.
  • Our incident-response process covers triage, containment, eradication, recovery, and a post-incident review.

If a security incident affects your Customer Data, we will:

  • notify you without undue delay;
  • where the CERT-In Directions, April 2022 require it, report the incident to CERT-In within 6 hours of becoming aware (categories include data breaches, unauthorised access to IT systems, identity theft, attacks on critical infrastructure, and others enumerated in the directions);
  • where the DPDP Act and the rules under it require it, notify the Data Protection Board of India and affected Data Principals in the form and within the timelines prescribed.

The notification process is documented in the DPA.

Data segregation

The Service is multi-tenant. Workspace data is segregated logically by organization_id in every storage layer (Postgres, MongoDB, Redis, Qdrant) and enforced at the application layer through the request-context middleware. Cross-workspace reads or writes are blocked by default; the test suite covers the boundary.

Backups & recovery

Production data stores are backed up on a recurring schedule. Backup restoration is exercised periodically. The Service is designed so that a worker-fleet failure does not lose Customer Data — agent configuration is sourced from durable stores, and session telemetry is captured before being summarised. Backups are retained for 30 days on a rolling basis.

Vulnerability management

  • Dependencies are tracked and patched on a routine schedule, with critical advisories addressed out of cycle.
  • Static analysis and linting run on every CI build.
  • Pull-request review is required for all production code changes.
  • Secrets are managed through the hosting provider's secret store; they are never committed to source control or logged.

A first-time third-party penetration test is on our 2026 roadmap; results will be shared with customers under NDA when complete.

Compliance — Indian rules & certifications

We are an early-stage Indian company, accountable to Indian regulators. What we operate today and what we are working toward:

  • DPDP Act, 2023. Aligned. We act as Data Fiduciary for our own account data and as Data Processor for Customer Data your agents process; the DPA reflects this. We will adapt as the rules and notifications under the Act take effect (Significant Data Fiduciary designations, transfer-restricted countries, and so on).
  • IT Act, 2000 + IT Rules, 2011. We follow the "Reasonable Security Practices and Procedures" standard prescribed for the handling of Sensitive Personal Data or Information.
  • CERT-In Directions, April 2022. We log time, retain logs in India to the extent required, and report reportable incidents within the 6-hour window. Our infrastructure synchronises clocks against NPL India / NIC NTP where applicable.
  • IT (Intermediary Guidelines and Digital Media Ethics Code) Rules, 2021. Where Saaya is treated as an intermediary, we publish grievance contact details (see the Privacy Policy) and follow the takedown timelines prescribed by the Rules.
  • Telecommunications Act, 2023 + TRAI TCCCPR, 2018. Customers using voice/SMS features are responsible for compliance; the AUP enforces this.
  • GST Act, 2017 & Income Tax Act, 1961. Compliance for billing and tax retention.
  • Companies Act, 2013. Corporate compliance.
  • Bharat Information Security & ISO/IEC 27001. Not currently certified. Under evaluation alongside SOC 2 (see below).
  • SOC 2 Type II. Not currently certified. On our 2026 roadmap as a customer-trust signal for Indian and international enterprise procurement; we will pursue an independent audit once the control set has been in steady state for the required observation window.
  • HIPAA / BAAs. Not in scope. We do not sign Business Associate Agreements at this stage. Until an HIPAA-eligible enterprise option is available, do not use the Service to process US Protected Health Information.
  • PCI DSS. Not in scope. We do not store cardholder data; payments are handled by PCI-compliant payment processors (Razorpay, Stripe).

When customers ask for a certification we don't have, we say so. If we ever decide to publicise a certification, the certificate or report will be the source of truth, not this page.

Sub-processors

The current list of sub-processors that operate any part of the Service is maintained at /legal/subprocessors. We notify customers of changes (including new additions) at least 30 days before they take effect.

Customer responsibilities

Security is a shared responsibility. Customers are responsible for:

  • the confidentiality of their account credentials and any API keys issued to them;
  • the prompts, instructions, and content they upload — including ensuring those have the rights and consents required under the DPDP Act and any other Indian law that applies to them;
  • the notices and consents they owe to their end users (for example, telling callers a conversation is being recorded, where the law requires it);
  • their use of the Service in compliance with applicable Indian law (telecom rules under the Telecommunications Act, 2023 and TRAI TCCCPR; sectoral rules in healthcare, finance, or employment; and any AI-related advisories from MeitY);
  • restricting workspace access to people who need it.

Reporting a vulnerability

If you find a security issue, please report it to info@illusionart.ai with the subject "[Security disclosure]". Include enough detail to reproduce and a way to reach you.

We commit to:

  • acknowledging your report within two business days;
  • not pursuing legal action against good-faith researchers acting in compliance with these guidelines and Indian law;
  • giving you credit for the report when you wish, after a fix is deployed.

Please do not access or modify other customers' data, perform denial-of-service testing, or publish details of an unpatched vulnerability before we have had a reasonable opportunity to remediate. We do not currently run a paid bug-bounty program; that is on the roadmap.

Contact

For security questions, vulnerability reports, or to request the current sub-processor list under NDA, write to info@illusionart.ai. Use the subject "[Security disclosure]" for vulnerability reports.

Version history
  1. v1.0 · Initial publication.