Security Overview

LiveKit is the real-time infrastructure behind voice, video, and AI agent applications used by enterprises in healthcare, financial services, customer support, and consumer technology. The data flowing through LiveKit — live conversations, video streams, recordings, transcripts, model prompts, and synthesized voices — is among the most sensitive data our customers handle. This document describes the controls, processes, and architectural choices we use to protect it.

For formal contractual terms, see our Data Processing Addendum. For audit reports, certificates, and real-time compliance status, visit the LiveKit Trust Center.

---

1. Compliance and certifications

LiveKit maintains an ongoing security and compliance program against widely recognized frameworks. The current status is:

We publish post-incident reports and meaningful sub-processor changes proactively. To be notified of sub-processor updates, subscribe here.

---

2. How customer data flows through LiveKit

Because LiveKit handles several distinct categories of data, it is worth being precise about each one. The diagram below describes the lifecycle of every data type we touch.

Real-time media (audio, video, data channels). Generated by participants and routed through LiveKit's Selective Forwarding Units (SFUs). Media is not persisted on LiveKit servers; it is decrypted in memory to perform forwarding and any opt-in server-side processing (recording, transcription) and then discarded.

Recordings (Egress). Created on demand by customers. By default, recordings are written directly to a customer-owned storage bucket (S3, GCS, or Azure Blob). Encryption-at-rest is configured by the customer at their storage provider.

Transcripts, logs, and traces (Agent Observability). Produced by agents — whether running on LiveKit-hosted infrastructure or self-hosted by the customer — and sent to LiveKit's observability service. Encrypted in transit and at rest. Retention follows the terms of service.

AI inference data (LiveKit Inference). Audio, text, prompts, and model completions that pass through LiveKit Inference are never logged or retained by LiveKit, and each third-party inference provider we use is contractually bound to zero retention as well.

Voice samples (for voice cloning). Stored only when a customer explicitly uploads a sample to create a synthetic voice. Deleted when the cloned voice is deleted from the dashboard. All inference providers we engage for voice cloning have been opted out, on the customer's behalf, of using these samples for training or model improvement.

Account, billing, and dashboard data. Stored in our production database in encrypted form, with logical isolation per customer.

Sections 3 through 5 describe the controls applied to each of these data types in more detail.

---

3. Real-time media security

LiveKit's media plane carries the most sensitive payload our customers entrust to us: live conversations and video. We treat it accordingly.

WebRTC media

All WebRTC media is transported using SRTP with keys negotiated via DTLS-SRTP, exactly as the WebRTC specification requires. Signaling between clients and LiveKit Cloud uses TLS 1.2 or higher. Because LiveKit operates as a Selective Forwarding Unit, the server decrypts media in memory to route packets between participants and to perform any opt-in server-side processing (recording, real-time transcription, mixing). Media is never persisted in this path.

For applications where even our servers should not have access to media content, end-to-end encryption is available. With E2EE enabled, the LiveKit SDK encrypts media frames with a key known only to participants before SRTP is applied. LiveKit servers see only opaque bytes and cannot decode the underlying audio or video.

One case to be explicit about: if your application uses LiveKit Agent hosting and the agent needs to participate in an E2EE session (for example, to transcribe or respond to encrypted audio), you provide the agent with the participant key as part of its configuration. In that path the agent process — which runs your code in a per-instance sandbox on LiveKit-hosted infrastructure — decrypts the stream in order to operate. If your requirement is that decrypted media must never exist inside LiveKit-operated infrastructure, run the agent yourself in your own environment instead.

SIP

For voice traffic that arrives over SIP, LiveKit can be configured to terminate SIP over TLS for signaling and SRTP for media — the state-of-the-art combination for telephony interconnect. Encryption is not required by default; whether it is available in practice depends on the capabilities and configuration of the upstream trunk provider. End-to-end encryption is not available for SIP traffic; this is a limitation of the broader SIP ecosystem, not LiveKit specifically. Inbound and outbound trunk credentials are stored encrypted in our database.

We support IP allowlisting for SIP trunks so customers can constrain which networks may initiate connections.

---

4. Recordings, transcripts, and observability data

Egress (recordings)

Recording is implemented by LiveKit's Egress service. When a customer enables a recording, the resulting media is written directly to the customer's own object storage — S3, GCS, or Azure Blob — using credentials the customer provides and rotates. Encryption-at-rest, lifecycle policies, and access control are configured by the customer at their storage provider. LiveKit only buffers media transiently during the recording window; nothing is persisted on LiveKit infrastructure once the recording completes successfully.

An optional backup destination can be enabled at the project level. When opted in, if a recording fails to upload to your primary destination, Egress falls back to LiveKit-managed object storage so the recording is not lost. Backed-up recordings are encrypted at rest and retained for up to 7 days, after which they are automatically deleted.

Agent Observability

Agents — whether running on LiveKit's hosted Agent platform or self-hosted by the customer — emit transcripts, logs, traces, and (when configured) recordings to LiveKit's observability service. This data is encrypted in transit and at rest. Each customer's observability data is logically isolated, tagged with a unique tenant identifier, and access controls enforce per-tenant separation across the storage and query path. Retention windows are defined in our Terms of Service. Observability data can be deleted on request.

---

5. AI inference and agent data handling

LiveKit's Agent platform integrates with a broad ecosystem of speech-to-text, text-to-speech, and large language model providers, accessible directly or through LiveKit Inference. Because this surface area is new for many customers' security teams, we are explicit about how data is handled.

Zero retention by LiveKit

LiveKit operates both as a proxy in front of third-party model providers and as a host for our own models. In neither case do we log or retain customer prompts, audio, completions, or any other inference payload. Requests pass through, results return, and nothing is kept.

Zero retention by sub-processors

For every third-party inference sub-processor listed at livekit.com/legal/sub-processors, we have negotiated a contractual zero-retention posture for customer data. Sub-processors do not retain, log, or use customer inference traffic for training or model improvement.

Voice cloning

When a customer uploads a voice sample to create a synthetic voice, that sample is stored encrypted for as long as the cloned voice exists in the customer's dashboard. Deleting the cloned voice deletes the underlying sample. All inference providers used in our voice cloning pipeline have been opted out, on the customer's behalf, of using voice samples for training, fine-tuning, or other model improvement.

BYOK for model providers

Bring-your-own-key for third-party model providers (e.g., routing your OpenAI, Anthropic, or Google traffic with your own API key and contractual relationship) is not currently supported. We will note this on this page when the capability ships.

Agent isolation

Agents running on LiveKit's hosted Agent platform execute in per-instance sandboxes, isolated from one another. Secrets that agents need at runtime are stored in and served from an internal vault service. Customers who need their agents to reach private services inside their own VPC can configure a private link so traffic between LiveKit-hosted agents and the customer's network does not traverse the public internet.

---

6. Encryption

In transit. Web and API endpoints use TLS 1.2 or higher. WebRTC media uses SRTP with DTLS-SRTP key exchange. SIP supports TLS for signaling and SRTP for media.

At rest. All persistent stores — including the account database, observability store, and the optional Egress backup bucket — use AES-256 at rest. Encryption keys are managed by our key management service and rotated according to industry best practices.

Secrets. Application secrets (including agent runtime secrets, integration credentials) are stored in an internal vault service. Secrets are never written to logs, build artifacts, or source control.

End-to-end media encryption. Available for WebRTC clients, as described in §3.

---

7. Infrastructure, regions, and isolation

LiveKit Cloud runs on a multi-cloud production environment hosted across Google Cloud Platform, Oracle Cloud, and DigitalOcean. The full and current list of infrastructure sub-processors is maintained at livekit.com/legal/sub-processors.

Multi-tenant by design. LiveKit Cloud is a multi-tenant service. Customer data and traffic are logically isolated by unique tenant identifiers, and all public facing APIs enforce per-tenant access. Single-tenant deployments are not offered today.

Data residency. Customers can pin media routing, observability data, agent hosting, and stored data to a region. Today, supported regions include the United States, the European Union, and India. Residency can be configured per project.

Network isolation. The production environment is fully isolated from corporate networks. External access to production services is gated through authenticated entry points; downstream services trust requests that have passed authentication at the gate.

Physical security. Data center physical security is provided by our infrastructure sub-processors. All providers we use maintain SOC 2 Type II (or equivalent) attestations and operate facilities with 24/7 staffed security, biometric and multi-factor access, video surveillance, environmental controls, and redundant power.

---

8. Identity, access, and customer-configurable controls

LiveKit provides several controls customers can use to harden their own deployments.

Single sign-on. SAML-based SSO is available on the Enterprise tier and supports common identity providers including Okta, Microsoft Entra ID, and Google Workspace. For lower tiers, dashboard authentication is handled via Google, GitHub OAuth, and email.

Role-based access control. LiveKit's dashboard currently supports admin, write, and read roles. We are actively expanding RBAC; finer-grained roles will be documented here as they ship.

Audit logging. Access to observability data and modifications to project configuration are logged. Audit log export to external SIEMs (Splunk, Datadog, etc.) is on our roadmap; reach out to your account team if this is required.

Access tokens (JWT). All client and agent access to LiveKit rooms is mediated by signed JWTs that your application issues using your API key. Tokens carry granular grants — room membership, publish/subscribe rights, recording permissions, metadata — and a TTL your application sets. Short token lifetimes are strongly recommended, though the TTL is determined by your application rather than enforced by LiveKit.

API keys. Project API keys can be rotated at any time from the dashboard. Secrets are shown once at creation and never recoverable thereafter.

SIP IP allowlisting. Customers operating their own SIP trunks can restrict which source networks are permitted.

SCIM provisioning. Not currently supported. On the roadmap.

---

9. Application and product security

Open source and public auditability. LiveKit's core media server, SIP service, Egress and Ingress services, agent framework, and client SDKs are open source under the Apache 2.0 license. The full source code is published on GitHub and is available for any customer or third party to audit. This is a deliberate posture: many of the world's largest companies depend on this code in their own infrastructure, and their security teams audit it. Issues identified in the open by researchers or customer security teams flow back into the codebase and into LiveKit Cloud. Customers do not have to take our word for how LiveKit handles media — they can read the code that does it.

Penetration testing. LiveKit engages an independent third-party security firm to perform full-coverage penetration tests every six months. Executive summaries are shareable under NDA via the Trust Center.

Bug bounty and responsible disclosure. We run an ongoing responsible-disclosure program documented at livekit.com/security/policy, with a public Hall of Fame recognizing researchers who report valid issues. To report a vulnerability, see §13 below.

Vulnerability management. Vulnerabilities surfaced by scanners or researchers are triaged for confirmed impact. When impact is confirmed, we target the following remediation SLAs:

Low-severity findings are tracked and resolved as part of regular maintenance. Findings that are not exploitable in our environment are documented and closed without rework.

Change management. Production changes are deployed through automated pipelines with required reviews and pre-deployment checks. High-risk changes — those affecting authentication, authorization, encryption, or the media path — require additional review from security stakeholders and have documented rollback procedures.

---

10. Operational security

Internal access. Production access is granted on a least-privilege, role-based basis and requires approval. All operators authenticate with multi-factor authentication. Access is reviewed periodically and revoked promptly on role change or departure.

Endpoint security. All corporate devices are enrolled in our Mobile Device Management (MDM) program, which enforces full-disk encryption, OS-level security baselines, password requirements, and screen-lock policies. Endpoint health is monitored continuously.

People security. All employees pass background checks at hire (where permitted by local law), sign confidentiality agreements, and complete annual security and privacy training covering acceptable use, data handling, phishing awareness, and incident reporting. Access is revoked immediately upon termination.

Sub-processor management. We perform a security risk assessment of every prospective sub-processor before onboarding, contractually require commensurate data protection, and review the relationship periodically. The current list is published at livekit.com/legal/sub-processors.

---

11. Incident response

LiveKit operates a 24/7 on-call rotation and a documented incident response procedure. When an incident occurs:

1. Detection and triage. Alerts from our monitoring stack and customer reports both feed an internal incident tracker. The on-call engineer assesses severity and assembles the response team.
2. Customer notification. Production incidents are posted to status.livekit.io immediately. Customers can subscribe to receive notifications by email, SMS, or webhook.
3. Resolution. The response team executes mitigation and remediation. Any data-handling implications are reviewed by our privacy lead and, where applicable, customer notification follows the timelines specified in our Data Processing Addendum.
4. Post-incident review. We publish public post-mortems within 48 hours of significant incidents. These describe the timeline, root cause, customer impact, and the concrete changes we will make to prevent recurrence.

For security incidents specifically — including any confirmed unauthorized access to customer data — affected customers are notified in accordance with our DPA and applicable law.

---

12. Business continuity and resilience

LiveKit Cloud is architected for redundancy at every layer. SFU and Egress workers run in multiple availability zones across multiple regions; the control plane is replicated; account and observability data are replicated and backed up. Traffic is routed around failed hosts, zones, and regions automatically. We continuously exercise failover paths as part of normal operations.

---

13. Reporting a security issue

If you discover a security vulnerability in LiveKit Cloud, our SDKs, or our open-source projects:

• Do not disclose publicly. Please report it privately first.
• Submit through our responsible disclosure program: livekit.com/security/policy
• Include reproduction steps, affected component, and any supporting material.
• We commit to acknowledging valid reports promptly and coordinating disclosure with the reporter.

For general security questions or to request audit artifacts, contact your account team or visit the LiveKit Trust Center.

---

A note on self-hosted LiveKit

The controls in this document describe LiveKit Cloud. The core LiveKit Server, SDKs, and supporting services are also available as Apache 2.0 open source for self-hosting. Self-hosted operators are responsible for their own security posture — infrastructure hardening, encryption-at-rest configuration, secrets management, monitoring, and patching. We do not publish a formal hardening guide and do not recommend self-hosting for production workloads with significant security or compliance requirements. Customers with such requirements are best served by LiveKit Cloud, where the controls described above apply.

End-to-end encryption, JWT-based access tokens, and SRTP/DTLS are available on both Cloud and self-hosted.