Encrypting Meeting Transcripts and Media: In Transit and At Rest

Meeting transcripts and recordings are encrypted in transit using Transport Layer Security (TLS) and at rest using standards like AES-256. For an API platform, this means every webhook, media stream, and stored file is protected. In practice, data is secured as it travels from the meeting platform to the bot, from the bot to your application via API calls, and when it is stored on disk after a call.

This is especially important for platforms that deploy active AI voice agents, not just passive recorders. An agent that can listen, speak, and act in a meeting requires a higher standard of security because it has a two-way, interactive connection. At MeetStream, we built our voice infrastructure with this principle in mind. API calls go over HTTPS, real-time data streams go over secure WebSockets, and all data is encrypted in transit and at rest.

Meeting data is some of the most sensitive data an organization handles. A single transcript can contain strategic plans, customer details, or internal discussions. As we build more sophisticated AI agents that interact with this data, securing it at every point in its lifecycle is not just a feature, it is a requirement for building a trustworthy product.

How MeetStream Secures Meeting Data End-to-End

A reliable security model for meeting data must account for the entire data lifecycle. This starts the moment a bot joins a call and ends when the processed data is deleted according to your retention policy. Our architecture is designed to protect data at each of these stages: in transit, during processing, and at rest.

We have processed over 1,000,000 meeting minutes, and this experience has shown us that a layered approach is the only way to build a secure system. It combines network-level encryption, application-level access controls, and independently audited compliance standards.

This defense-in-depth model ensures there is no single point of failure. Even if one layer were compromised, others are in place to protect the underlying data. Let's walk through the specific controls at each stage.

Securing Data in Transit: From Meeting to API

Encryption in transit protects data as it moves across networks. For a meeting bot, this involves multiple paths: the connection from the meeting platform itself, API calls to and from your application, and real-time data streams for live agents.

All API communication with MeetStream, including the initial create_bot request and any subsequent webhooks sent to your callback_url, is sent over HTTPS, so it is encrypted in transit. This prevents eavesdropping or tampering with API requests and responses. The underlying media streams from Zoom, Google Meet, and Microsoft Teams are also encrypted using protocols like Secure Real-Time Transport Protocol (SRTP).

A specific example of this is how we handle Zoom authentication. To join a meeting programmatically, Zoom requires an On Behalf Of (OBF) token. Instead of asking you to pass sensitive, long-lived user credentials to us, our API uses a delegated model. You provide a secure obf_url in your API call, and our bot fetches the short-lived token from your server just in time to join the meeting. We never see or store your users' Zoom refresh tokens, which limits the security scope for both of us. You can read more about this in our guide to Zoom OAuth 2.0.

Securing Data at Rest: Storage and Processing

Encryption at rest protects data when it is stored on disk. This is critical for preventing unauthorized access to raw files in the event of a storage system breach. All meeting artifacts managed by MeetStream, including audio files, video recordings, and final transcripts, are encrypted at rest.

We give you control over your data. By default, recordings are stored securely in our environment for 30 days before being permanently deleted. You can configure custom retention policies or, for maximum control, have MeetStream write all media and transcripts directly to your own S3 bucket. This puts you in complete control of your at-rest encryption keys and access policies.

During processing, such as when a transcript is being generated from an audio file, data is decrypted only in memory within a secure, isolated compute environment. The decrypted data is never written to disk, and the memory is cleared after the job is complete. This practice of scoped decryption ensures that sensitive information is exposed for the minimum time necessary to perform a task.

Securing Agent Interactions: Real-Time Control and Audio

For active AI agents, security extends beyond simple recording. An agent needs a live, two-way communication channel to listen to the meeting and respond with voice or chat messages. This introduces a new surface area that must be secured.

MeetStream uses two primary mechanisms for real-time interaction, both of which operate over secure WebSockets (WSS), which is WebSocket communication encrypted with TLS.

1. Live Audio Streaming: When you need a real-time audio stream for your agent, you provide a WebSocket URL in the live_audio_required parameter. Our platform connects to your server as a client over WSS, ensuring the audio data is encrypted in transit.
2. Meeting Control: To send commands to the bot, like making it speak or send a chat message, you use the socket_connection_url. This creates a persistent, secure WebSocket connection over which you can send JSON commands.

Securing these channels is critical. An unencrypted control channel could allow an attacker to make your bot send arbitrary messages in a meeting. By using WSS for all real-time agent communication, we ensure that both the audio data your agent receives and the commands it executes are protected.

Compliance, Audits, and Data Residency

Technical controls like encryption are the foundation of security, but they must be verified by established compliance frameworks. These audits provide independent assurance that a platform is operating securely.

MeetStream is ISO 27001 certified, which validates our information security management system. We are also GDPR compliant and offer data processing agreements to all customers. For healthcare applications, MeetStream is HIPAA compliant and we will sign a Business Associate Agreement (BAA). Our SOC 2 Type 2 report is currently under audit.

We also recognize that data residency is a key compliance requirement for many businesses. We provide options for data processing and storage in both the United States and the European Union, allowing you to keep your data within your required geopolitical boundaries.

How MeetStream's Security Enables Agent-First Workflows

Building a simple meeting recorder is a solved problem. The next step is building active AI participants that can take action during a live call, from updating a CRM to answering a question. This shift from passive recording to active participation fundamentally changes the security requirements.

A passive recorder is primarily a data-out system. An active agent is data-in and data-out. It requires a secure, low-latency, bidirectional channel to be effective. The security measures we have discussed, from delegated Zoom authentication to encrypted WebSocket control channels, are not just features. They are the architectural foundation that makes it possible to safely deploy these more advanced meeting bot workflows.

By handling the complex security and infrastructure layer, we allow developers to focus on building their agent's logic, not on building the capture and storage layer. You can create your first bot and start receiving data over a secure webhook in minutes.

Conclusion

For any application that handles meeting data, encrypting transcripts and media is a baseline requirement. When building active AI agents, the security bar is even higher. You must protect not only the data coming out of a meeting but also the control channels going into it.

A complete security strategy combines strong encryption for data in transit (TLS, SRTP) and at rest (AES-256) with secure architectural patterns and third-party compliance audits. By building on a platform that provides this layered security by default, you can build powerful, interactive AI agents while ensuring the privacy and integrity of your users' most sensitive conversations. See the full API reference at docs.meetstream.ai.

Frequently Asked Questions

What encryption standard should I use for stored meeting recordings?

Use AES-256-GCM for at-rest encryption of audio and video files. Store encryption keys in a managed key service like AWS KMS or Google Cloud KMS, never alongside the encrypted data. For multi-tenant applications, use a separate key per customer to ensure strict data isolation.

How do I encrypt transcript data in a database?

Use field-level encryption for sensitive columns like transcript text and speaker names. Most cloud database services, like Amazon RDS, offer Transparent Data Encryption (TDE) which handles the underlying storage encryption automatically. Combining both provides strong, layered protection.

What TLS version should meeting bot WebSocket connections use?

Require TLS 1.2 at a minimum and prefer TLS 1.3 for all WebSocket connections. TLS 1.3 offers a faster, more secure handshake. You should configure your server or load balancer to disable older, vulnerable protocols like TLS 1.0 and 1.1.

How should I handle encryption key rotation for long-term transcript archives?

Implement envelope encryption. Encrypt each file with a unique Data Encryption Key (DEK), and then encrypt that DEK with a master Key Encryption Key (KEK) stored in a KMS. To rotate keys, you only need to re-encrypt the small DEKs with a new KEK, which is much faster than re-encrypting terabytes of media files.