Security at Amomic-AI

01

Our approach

Businesses trust Amomic-AI with something sensitive: live conversations with their customers. We treat that trust as the product. Security is designed into the platform — tenant isolation, least-privilege access and encryption by default — rather than bolted on afterwards.

This page describes our current practices honestly. If you have a security questionnaire or need more depth for procurement, email support@amomic.in and we will answer it directly.

02

Infrastructure

• The platform runs on Google Cloud Platform — serverless compute (Cloud Run), managed databases (Firestore and Realtime Database) and Firebase Hosting — inheriting Google’s physical and network security controls.
• Environments are separated: development and production run in distinct projects with independent identities, data and access policies.
• Services run with dedicated, minimally-scoped service accounts — no shared credentials between components.

03

Encryption

• In transit: all traffic — browser to platform, service to service, platform to AI providers — is encrypted with TLS 1.2+.
• At rest: all stored data, including conversation transcripts and call recordings, is encrypted with AES-256 via Google Cloud’s default encryption.
• Secrets: API keys and credentials live in a managed secret store, never in source code, and are rotated when personnel or exposure risk changes.

04

Tenant isolation & access control

• Every record is scoped to an organisation, and every API request is authenticated and authorised against that organisation — enforced in the application layer and in database security rules.
• Console access uses Google Identity Platform with role-based access control (owner, admin, member) inside each organisation.
• Internal access to production data is restricted to a small number of engineers on a least-privilege, need-to-access basis, and is logged.

05

AI data handling

• Conversation content is sent to AI providers (speech-to-text, text-to-speech, language models) only to generate the response — our agreements prohibit them from training foundation models on it. Providers are listed on the Subprocessors page.
• Knowledge-base content is stored per organisation and used only to answer that organisation’s conversations.
• Customers control retention of their conversation data, as set out in the Data Processing Agreement.

06

Monitoring & reliability

• Centralised logging and alerting across services, with anomaly signals for abuse patterns such as unusual calling volume.
• Managed, replicated data stores with automated backups; deletion follows the schedule in the DPA.
• Deployments go through CI/CD with review no manual, untracked changes to production.

07

Secure development

• Code changes are peer-reviewed and pass automated checks before deployment.
• Secrets scanning and dependency updates are part of the development workflow.
• Security-relevant engineering rules (authentication on every endpoint, input validation, webhook verification) are codified in our internal standards and enforced in review.

08

Compliance posture

We align our data practices with India’s DPDP Act, 2023 and, for international customers, GDPR principles — see the Privacy Policy and DPA.

09

Responsible disclosure

If you believe you have found a vulnerability in Amomic-AI, we want to hear about it before anyone else does.

• Email support@amomic.in with the subject “Security disclosure”, including steps to reproduce.
• Give us reasonable time to fix the issue before public disclosure; do not access other users’ data or disrupt the service while testing.
• We acknowledge reports within 48 hours, keep you informed, and credit researchers who report in good faith.