Legal
Security
Document version 1.0 · June 2026
1.System Overview
The Malakai platform is a voice-enabled AI system that processes incoming and outgoing calls, converts speech to text, retrieves relevant context, generates intelligent responses, and synthesizes responses back to audio format. All data flowing through these services originates from the Malakai Backend and is routed through secure channels with encryption and hashing mechanisms at rest and in transit.
The Malakai system processes voice interactions through a sophisticated pipeline involving call ingestion, speech recognition, contextual retrieval, AI-powered response generation, and voice synthesis, with every stage implementing encryption and hashing protocols to ensure data confidentiality and integrity.
2.Primary Data Flow
The primary data flow in the Malakai system proceeds as follows:
- Inbound/Outbound Call — Twilio receives the call initiated from the Malakai Backend, establishing voice connection with the caller.
- Speech-to-Text Conversion — The audio stream is transmitted from Twilio to Deepgram for STT processing.
- Context Retrieval — Transcribed text is sent to VoyageAI (RAG) to retrieve relevant context from the knowledge base.
- LLM Response Generation — The combined user query and retrieved context is sent to Claude, OpenAI, or Gemini for intelligent response generation.
- Text-to-Speech Synthesis — The generated response is sent to ElevenLabs for TTS conversion.
- Call Response Delivery — The synthesized audio is transmitted back through Twilio to the caller.
3.Detailed Service Breakdown
Twilio — Voice Communication Gateway
| Aspect | Details |
|---|---|
| Function | Handles incoming and outgoing voice calls, acts as primary gateway for audio transmission |
| Data Received | Audio streams from Malakai Backend; call metadata (caller ID, timestamp, duration) |
| Data Sent | Audio streams to Deepgram and ElevenLabs; synthesis completion status |
| Data Storage | Call records stored with Twilio; call recordings optionally transferred to S3 (encrypted) |
Deepgram — Speech-to-Text
| Aspect | Details |
|---|---|
| Function | Converts audio stream to text via advanced speech recognition |
| Data Received | Real-time audio stream |
| Data Sent | Transcribed text, confidence scores |
| Data Storage | Deepgram maintains temporary cache; user must configure retention policies |
VoyageAI — RAG & Context Retrieval
| Aspect | Details |
|---|---|
| Function | Retrieves relevant context from knowledge base using semantic search |
| Data Received | User query (transcribed text), embedding vectors |
| Data Sent | Relevant context documents, relevance scores |
| Data Storage | Vector embeddings stored in VoyageAI infrastructure (encrypted at rest) |
Claude / OpenAI / Gemini — LLM Response Generation
| Aspect | Details |
|---|---|
| Function | Generates intelligent responses based on user query and retrieved context |
| Data Received | User query, context documents, conversation history |
| Data Sent | Generated response text |
| Data Storage | Minimal logging per API provider policies; interaction logs stored in Malakai Backend (encrypted) |
ElevenLabs — Text-to-Speech
| Aspect | Details |
|---|---|
| Function | Converts generated text response to natural-sounding audio |
| Data Received | Response text, voice parameters (voice ID, speed, pitch) |
| Data Sent | Audio stream (synthesized speech) |
| Data Storage | Minimal caching; synthesis results not stored long-term per ElevenLabs policy |
4.Side Channels & Supporting Infrastructure
Amazon S3 — Cloud Storage
Data stored:
- Call recordings (encrypted with AES-256)
- System configurations (encrypted with AES-256)
- Vector embeddings backup (encrypted with AES-256)
- Analytics and audit logs (hashed with SHA-256)
Security measures:
- Server-Side Encryption (SSE-S3): All objects encrypted at rest
- Encryption in Transit: TLS 1.2+ for all data transfers
- Access Control: IAM policies restrict access to authorized services only
- Versioning Enabled: Maintains object history for recovery
- Bucket Policies: Public access disabled; bucket-level encryption enforced
- CloudTrail Logging: All API calls logged for audit purposes
DynamoDB — Call History & Authentication
Data stored:
- Call history (transcripts, timestamps, duration, participants)
- User authentication records
- Session tokens
- User metadata and preferences
- Rate limiting and usage analytics
Security measures:
- Encryption at Rest: All data encrypted using AWS-managed keys (AES-256)
- Encryption in Transit: TLS for all data transmission
- Sensitive Data Hashing: Passwords and tokens stored as SHA-256 hashes, never in plaintext
- Fine-Grained Access Control: IAM policies enforce principle of least privilege
- Point-in-Time Recovery: Enabled for data restoration
- DynamoDB Streams: Audit trail of all modifications
- CloudWatch Monitoring: Real-time alerts for suspicious activity
Malakai Backend — Workspace Configuration & Central Control
The Malakai Backend serves as the central orchestrator and data originator for all system operations. It sources all data flowing through the primary data pipeline and side channels, manages workspace configuration, and coordinates between integrated services.
Data stored:
- Workspace configurations
- API credentials for integrated services
- User profiles and roles
- Integration settings and mappings
- Interaction logs and call metadata
- System audit trails
- Analytics and performance metrics
Security measures:
- End-to-End Encryption: All data encrypted during storage and transmission
- Hashing of Sensitive Data: Passwords, API keys, and tokens stored as SHA-256 or bcrypt hashes
- Role-Based Access Control (RBAC): Granular permissions based on user roles
- Encryption Key Management: Keys stored in secure vaults; rotation policy enforced
- Audit Logging: All data access and modifications logged with immutable audit trails
- Regular Security Assessments: Penetration testing and vulnerability scanning
5.Data Security & Encryption Standards
Encryption Standards
| Data Type | At Rest | In Transit |
|---|---|---|
| S3 Recordings | AES-256 | TLS 1.2+ |
| S3 Configs | AES-256 | TLS 1.2+ |
| DynamoDB Records | AES-256 (AWS-Managed) | TLS 1.2+ |
| Malakai Backend | AES-256 | TLS 1.2+ |
Hashing Standards
| Data Element | Hashing Algorithm & Usage |
|---|---|
| User Passwords | bcrypt with salt; never stored in plaintext |
| API Keys & Tokens | SHA-256; stored hashed in database |
| Audit Logs | SHA-256; ensures integrity and immutability |
| Call Metadata | SHA-256; for validation and change detection |
| Session Tokens | SHA-256 with time-based expiration |
6.Data Origin & Flow Summary
All data flowing through the Malakai platform originates from the Malakai Backend, which acts as the centralized data source and control point. This data is then routed through the following channels and services:
- Inbound call from caller → Twilio receives and forwards to Malakai Backend
- Malakai Backend retrieves workspace configuration from DynamoDB
- Audio stream forwarded to Deepgram (STT) with encryption
- Deepgram returns transcribed text to Malakai Backend
- Malakai Backend sends query to VoyageAI for context retrieval
- Combined query and context sent to Claude/OpenAI/Gemini
- Generated response received and forwarded to ElevenLabs (TTS)
- Synthesized audio returned to Malakai Backend
- Audio forwarded to Twilio for delivery to caller
Throughout this entire flow, call records are stored in DynamoDB (encrypted), recordings are stored in S3 (encrypted and/or hashed), and all data is transmitted using TLS encryption. The Malakai Backend maintains encrypted audit logs of all operations.
7.Compliance & Data Protection Standards
The Malakai platform adheres to the following standards and regulations:
- GDPR (General Data Protection Regulation): Data handling complies with EU privacy regulations; user consent obtained for processing
- CCPA (California Consumer Privacy Act): California residents have rights to data access, deletion, and opt-out
- HIPAA (Health Insurance Portability and Accountability Act): If handling healthcare data, encryption and audit logging enforced
- SOC 2 Type II: Cloud infrastructure providers (AWS, Anthropic, OpenAI) maintain compliance
- ISO/IEC 27001: Information security management system certification pursued
- PCI DSS (Payment Card Industry Data Security Standard): If processing payment data, compliance enforced
8.Encryption Key Management
Key generation & storage:
- Master encryption keys generated using cryptographically secure random generators
- Keys stored in AWS Secrets Manager or HashiCorp Vault with access control
- Hardware Security Modules (HSMs) used for high-security environments
- Key rotation policy enforced every 90 days
Key access & rotation:
- Only authorized services granted access via IAM policies
- Key rotation does not require data re-encryption; new keys used for new data
- Old keys retained for decryption of historical data
- Key usage logged and audited for compliance
9.Security Incident Response & Data Breach Protocol
In the event of a security incident or suspected data breach, the following protocol is activated:
- Detection: CloudWatch, CloudTrail, and intrusion detection systems monitor for anomalies
- Isolation: Affected systems are immediately isolated to prevent further compromise
- Investigation: Forensic analysis performed; audit logs reviewed for scope determination
- Notification: Users and relevant authorities notified per regulatory requirements (GDPR, CCPA, etc.)
- Remediation: Security fixes deployed; systems restored from clean backups
- Post-Incident: Root cause analysis; preventive measures implemented
10.Data Retention & Deletion Policies
| Data Type | Retention Period | Deletion Method |
|---|---|---|
| Call Recordings | Per company policy (default: 90 days) | Secure delete; multi-pass overwrite |
| Call History | Per company policy (default: 1 year) | DynamoDB purge; point-in-time recovery disabled |
| Audit Logs | Per compliance requirement (min: 7 years) | Archived to cold storage; secure deletion |
| User Accounts (Deleted) | Immediately upon request | Full deletion from all systems and backups |
11.Third-Party Data Visibility and Access
Important disclosure: The Malakai platform integrates with multiple third-party services to provide voice AI functionality. This section explicitly states what data is visible to each third-party service, what they can and cannot access, and what usage limitations apply.
Third-Party Services and Their Data Access
Twilio — Voice Communication
What Twilio can see:
- Incoming/outgoing phone numbers (caller ID and recipient)
- Call duration and timestamps
- Audio stream content (during active call transmission)
- Call completion status and metadata
- Billing information tied to call usage
What Twilio cannot see:
- Transcribed text content (STT output is not sent back to Twilio)
- AI-generated responses
- Context data retrieved from VoyageAI
- User workspace configurations
- System audit logs
- Encrypted recordings stored in S3
- Any backend data or user preferences
Data usage by Twilio:
- May use call metadata for service optimization per their Terms of Service
- Provides analytics on call volume and quality
- Does NOT use audio content for training or secondary purposes beyond service delivery
Deepgram — Speech-to-Text
What Deepgram can see:
- Real-time audio stream during active speech recognition
- Confidence scores and transcription metadata
- Basic call/session identifiers
What Deepgram cannot see:
- User identity or workspace information
- Response text or AI-generated output
- Retrieved context from knowledge base
- Previous conversation history
- Call metadata from Twilio
- Encrypted recordings
- User credentials or system configuration
Data usage by Deepgram:
- Uses audio and transcriptions for improving STT model accuracy (unless opted out)
- Does NOT retain audio longer than processing time without explicit user request
- Per Deepgram Privacy Policy: May use transcription data for model improvement with explicit opt-out available
VoyageAI — Context Retrieval & RAG
What VoyageAI can see:
- User query text (the transcribed question)
- Embedding vectors for semantic search
- Context document metadata returned from knowledge base
What VoyageAI cannot see:
- Original audio stream
- User identity or workspace ID (queries anonymized)
- Full conversation history (only current query)
- AI-generated responses
- Call metadata from Twilio
- User credentials or backend configuration
- Encrypted storage data
- Call recordings or raw audio
Data usage by VoyageAI:
- Uses embeddings and queries for RAG optimization
- Does NOT store queries permanently
- Does NOT use query data for external model training without explicit consent
Claude / OpenAI / Gemini — LLM Response Generation
What LLMs can see:
- User query text (transcribed from audio)
- Retrieved context documents relevant to the query
- Conversation history (limited to current session)
- Specific parameters: temperature, max tokens, model selection
What LLMs cannot see:
- Original audio files
- User identity (queries processed anonymously by default)
- Caller information or phone numbers
- Call metadata from Twilio
- System configuration or workspace settings
- Encrypted data from backend storage
- Audit logs or administrative records
- Other users’ data or conversations
Data usage by LLMs:
- Claude (Anthropic): Does NOT retain queries or responses for training without explicit consent; privacy-focused
- OpenAI (ChatGPT/GPT models): May use API calls for service improvement unless “data retention” is disabled
- Gemini (Google): May use queries for model improvement per Google’s Privacy Policy
- CRITICAL: For all providers, the Malakai Backend can be configured to disable data retention and prevent external use
ElevenLabs — Text-to-Speech
What ElevenLabs can see:
- Generated response text (the text being converted to speech)
- Voice selection parameters (which voice model is used)
- Speech parameters (speed, pitch, style)
What ElevenLabs cannot see:
- Original user audio or voice
- User identity (requests are session-based)
- Transcribed user query
- Context or knowledge base information
- Call metadata from Twilio
- System configuration or credentials
- User workspace data
- Encrypted backend data
Data usage by ElevenLabs:
- Uses text and parameters for voice synthesis optimization
- Does NOT retain synthesized audio after delivery
- Per ElevenLabs Terms: May analyze text for quality improvement but does NOT use for external purposes
Data NOT Sent to Third Parties
The following sensitive data is NEVER transmitted to third-party services:
- User Credentials — Passwords (stored as bcrypt hashes in Malakai Backend only); API keys (stored as SHA-256 hashes in Malakai Backend only); session tokens (secured in DynamoDB, encrypted)
- System Configuration — Workspace settings; integration mappings; system architecture details; database credentials
- Audit Logs — Complete audit trail; access logs; system modification records; security events
- Encrypted Data — S3-stored recordings (remain encrypted and inaccessible to third parties); Malakai Backend encrypted data (never decrypted for external services); DynamoDB records (remain in AWS infrastructure only)
- Other User Data — User profiles and preferences (except as necessary for call handling); contact lists or relationships; historical call data (beyond current session); billing information (retained only by Twilio and Malakai Backend)
Third-Party Visibility of Complete Data Flow
Can third parties see the complete system? NO. Each third-party service operates in isolation and can ONLY see:
- Their specific input data (what they need to perform their function)
- Their specific output data (their result)
- They CANNOT see how their output is used downstream
Example: Deepgram transcribes audio and sends text to Malakai Backend. Deepgram does NOT see that the text is sent to VoyageAI, does NOT see the retrieved context, does NOT see the final AI response, and does NOT see the synthesized audio output.
This compartmentalization ensures that no single third-party service can reconstruct the complete conversation or understand the full business logic.
Data Minimization Practices
The Malakai platform implements strict data minimization:
- Only necessary data is shared: Each service receives only the data required for its function
- No redundant transmissions: Data is not unnecessarily duplicated across services
- Session-based processing: Most queries are anonymized at the session level
- No long-term storage by third parties: Third-party services do not retain data after processing
- Optional data retention: Malakai customers can disable third-party data retention features (e.g., OpenAI model improvement)
Third-Party Access to User Information
User identity privacy — third-party visibility:
| Third Party | Can See User Name? | Can See Phone Number? | Can See Workspace? | Can See User History? |
|---|---|---|---|---|
| Twilio | No | Yes (caller ID) | No | No |
| Deepgram | No | No | No | No |
| VoyageAI | No | No | No | No |
| Claude/OpenAI/Gemini | No | No | No | No |
| ElevenLabs | No | No | No | No |
None of the third-party services can identify individual users or access their historical data.
Compliance and Contractual Safeguards
All third-party integrations are protected by:
- Data Processing Agreements (DPAs): Formal contracts restricting how third parties can use data
- GDPR Compliance: Third parties act as Data Processors, not Data Controllers
- Encryption Requirements: Data in transit is protected with TLS 1.2+
- Access Restrictions: IP whitelisting and API key authentication limit access
- Audit Rights: Malakai maintains audit trails of all data sent to third parties
- Deletion Clauses: Third parties are contractually required to delete data upon service termination
- No Sublicensing: Third parties cannot share data with other vendors
- Incident Notification: Third parties must report data breaches within 24-48 hours
Opt-Out and Data Minimization Options
Customers can configure the following to minimize third-party visibility:
- Disable STT Retention: Deepgram does not retain transcripts
- Disable LLM Training: OpenAI model improvement disabled
- Disable Voice Caching: ElevenLabs does not cache synthesized audio
- Proxy Mode: All third-party communications routed through Malakai Backend proxy (additional encryption layer)
- Selective Integration: Disable specific third-party services if not needed
12.Conclusion
The Malakai platform implements a comprehensive data security architecture that ensures all data originating from the Malakai Backend is protected throughout its lifecycle. Every integration point uses end-to-end encryption, sensitive data is hashed using industry-standard algorithms, and all systems maintain detailed audit logs for compliance and accountability.
Third-party services have strictly limited visibility into the platform’s data and operations. Each external service operates in isolation, seeing only the specific data necessary for their function. User credentials, system configuration, audit logs, and encrypted data remain completely hidden from third parties.
By leveraging AWS’s managed security services (S3, DynamoDB), implementing TLS 1.2+ for all network transmission, maintaining strict access controls via IAM policies, and enforcing data compartmentalization, the Malakai platform provides a secure, scalable, and compliant solution for voice AI interactions.
All data handling practices comply with global privacy regulations including GDPR, CCPA, and HIPAA, ensuring users’ data rights and privacy are protected at the highest standards.
For questions or security concerns, please contact the Malakai Security Team.