Bayer LiveKit SDK¶
- Version: 1.4.4
- LiveKit Agents SDK Version: ~=1.4.4
- Python: >=3.10 (tested on 3.10, 3.11, 3.12, 3.13, 3.14)
- Last Updated: April 2026
- Maintained by: Bayer LiveKit Platform Team ⧉
- Audience: Bayer internal developers — agent development teams
- Status: Active
Table of Contents¶
- Overview
- Why This SDK Exists
- System Architecture
- Authentication Flow
- Authentication Modes
- Security Model
- Migration from Standard LiveKit SDK
- Plugin Ecosystem
- What You Can Build
- Token Lifecycle
- Related Resources
Overview¶
The Bayer LiveKit SDK is a thin, security-focused wrapper around the open-source LiveKit Agents SDK ⧉. It lets you build real-time AI agents — voice assistants, video analysis bots, multi-modal agents — that run on Bayer's shared LiveKit infrastructure.
The primary difference from the upstream SDK is authentication. Bayer's platform does not expose raw LiveKit credentials to developers. Instead, this SDK handles the full auth flow automatically:
- Your agent proves its identity to Microsoft Entra ID.
- The LiveKit Platform Service validates that identity and issues a scoped, time-limited LiveKit JWT token.
- Your agent uses that token to connect — no LiveKit API keys or secrets required.
Your agent code is nearly identical to standard LiveKit Agents code. In most cases, the changes are the import path, dropping the LiveKit credential env vars, and using the Bayer JobContext wrapper that blocks direct ctx.api access.
Why This SDK Exists¶
Standard LiveKit workflows require static credentials:
# Standard LiveKit setup — every developer has this
LIVEKIT_API_KEY=devkey
LIVEKIT_API_SECRET=devsecret
These credentials grant unrestricted access to the LiveKit server — any room, any operation, forever. In a shared production platform, this creates serious problems:
| Problem | Why it matters |
|---|---|
| Unlimited access scope | A developer can create or delete any room, kick any participant |
| Static credentials never expire | A leaked secret remains valid until manually rotated across all consumers |
| No audit trail | You cannot trace which developer or agent performed an action |
| Unrevocable per-identity | If a developer leaves, you must rotate the shared secret for everyone |
| Compliance failure | Violates principle of least privilege required by Bayer's security standards |
The Bayer SDK replaces this with identity-based, platform-mediated authentication.
System Architecture¶
Authentication Flow¶
The SDK handles the following flow automatically — you only write your agent logic:
sequenceDiagram
participant Agent as AI Agent (SDK)
participant Entra as Entra ID
participant Ocelot as Ocelot
participant LKPS as LKPS
participant LK as LiveKit Server
Agent->>Entra: 1. Acquire access token (ClientSecretCredential)
Entra-->>Agent: Entra JWT
Agent->>Ocelot: 2. POST /api/agent/register (Bearer token)
Note over Ocelot: 3. Validate JWT
Note over Ocelot: 4. Inject identity headers
Ocelot->>LKPS: Forward with validated headers
Note over LKPS: 5. Generate scoped LiveKit JWT
Note over LKPS: 6. Audit log (PostgreSQL)
LKPS-->>Agent: { token, livekit_url }
Agent->>LK: 7. Connect via WebSocket (scoped JWT)
Note over Agent: 8. Token renewal loop (every expiry − 5 min)
loop Token Renewal
Agent->>Ocelot: Re-register before expiry
Ocelot->>LKPS: Forward with validated headers
LKPS-->>Agent: Fresh scoped JWT
Agent->>LK: Hot-swap token
endWhat this means in practice:
- You never hold LiveKit credentials. The platform holds them. You hold an Entra identity.
- Every connection is time-bound. Tokens expire (default 1 hour). The SDK renews them automatically.
- Access is scoped per registration. Your token grants only what your role permits.
- Every registration is audited. Who registered, when, with what identity — all logged.
- Revocation is instant. Remove the Entra app role → the agent can no longer register. No secret rotation required.
Authentication Modes¶
The SDK supports three authentication modes. The appropriate mode is selected automatically based on available credentials:
| Mode | When to use | How it works |
|---|---|---|
| Service Principal | CI/CD pipelines, production deployments | Set AZURE_CLIENT_ID + AZURE_CLIENT_SECRET + AZURE_TENANT_ID. The SDK uses ClientSecretCredential. |
| Azure CLI | Local development | Run az login — the SDK detects your session via DefaultAzureCredential. No env vars needed. |
| Managed Identity | Azure-hosted workloads (AKS, Container Apps) | Auto-detected by DefaultAzureCredential. No credentials to manage. |
Note
The SDK tries ClientSecretCredential first (if env vars are present), then falls back to DefaultAzureCredential which covers Azure CLI, Managed Identity, and other Azure credential chains.
Security Model¶
| Aspect | Standard LiveKit SDK | Bayer LiveKit SDK |
|---|---|---|
| Developer-held credentials | LIVEKIT_API_KEY + LIVEKIT_API_SECRET (static, full admin) |
Entra identity only (scoped, revocable) |
| Token generation | In developer code | LiveKit Platform Service (secrets never exposed) |
| Access scope | Unlimited — any operation | Time-bound, role-checked, per-registration |
REST API access (ctx.api) |
Available — full server control | Blocked — raises RuntimeError |
| Token renewal | Manual or none | Automatic (background task, 5 min before expiry) |
| Audit trail | None | Every registration logged with identity + timestamp |
| Revocation | Rotate shared secret for everyone | Remove Entra app registration → instant block |
Important
The ctx.api property is intentionally blocked to prevent unauthorized REST API access to the LiveKit server. This is a security restriction — agents interact only through the scoped token and room events.
Migration from Standard LiveKit SDK¶
For teams already using the open-source LiveKit Agents SDK, migration is minimal:
| What changes | Standard LiveKit SDK | Bayer LiveKit SDK |
|---|---|---|
| Import path | from livekit.agents import Agent |
from bayer_livekit_sdk.agents import Agent |
| Plugins import | from livekit.plugins import openai |
from bayer_livekit_sdk.plugins import openai |
| Credentials | LIVEKIT_API_KEY + LIVEKIT_API_SECRET |
AZURE_CLIENT_ID + AZURE_CLIENT_SECRET |
| Worker setup | WorkerOptions(entrypoint_fnc=...) |
Worker() + worker.rtc_session(entrypoint) |
| Agent logic | No change | No change |
| Plugin usage | No change | No change |
ctx.api |
Available | Blocked (raises RuntimeError) |
What stays the same: - Agent class definitions, function tools, and decorators - STT / LLM / TTS plugin configuration - Room events and participant handling - All 60+ LiveKit plugins
Plugin Ecosystem¶
The SDK provides access to the full LiveKit plugin ecosystem through bayer_livekit_sdk.plugins. Plugins are installed as extras:
pip install "bayer-livekit-sdk[openai,aws,silero]"
Available Plugin Categories¶
| Category | Plugins | Count |
|---|---|---|
| Speech-to-Text (STT) | AssemblyAI, AWS Transcribe, Azure, Deepgram, Google, Groq, OpenAI | 7 |
| Text-to-Speech (TTS) | AWS Polly, Azure, Cartesia, Deepgram, ElevenLabs, Google, OpenAI | 7 |
| Large Language Models (LLM) | Anthropic, Google, Groq, OpenAI, Ollama, Mistral, DeepSeek, and more | 10+ |
| Avatar / Video | Anam, Avatario, Bithuman, Hedra, LiveAvatar, Simli, Tavus, and more | 9 |
| Audio Processing | Silero (VAD), Noise Cancellation, Turn Detector | 3 |
| Other | LangChain, Browser, NVIDIA, and more | 20+ |
| Total | 60+ |
Category extras for convenience:
pip install "bayer-livekit-sdk[stt]" # All STT plugins
pip install "bayer-livekit-sdk[tts]" # All TTS plugins
pip install "bayer-livekit-sdk[llm]" # All LLM plugins
Note
Uninstalled plugins fail gracefully — they are falsy and raise a helpful error message on use.
What You Can Build¶
The SDK supports the same agent types as the upstream LiveKit Agents SDK:
| Agent Type | Description |
|---|---|
| Voice Assistants | Real-time voice conversation agents with STT, LLM, and TTS pipelines |
| Video-Aware Agents | Agents that capture and analyze video frames (e.g., GPT-4 Vision) |
| Multi-Modal Copilots | Agents combining voice, video, text, and data channels |
| Multi-Agent Systems | Domain-specific agents with handoff between specialized sub-agents |
Token Lifecycle¶
The SDK manages the full token lifecycle automatically:
- Acquisition — On startup, the SDK acquires an Entra ID token and exchanges it for a LiveKit JWT via
POST /api/agent/register. - Connection — The SDK connects to the LiveKit Server using the LiveKit JWT over WebSocket.
- Renewal — A background task wakes 5 minutes before expiry and fetches a new token. The worker picks up the refreshed token on the next reconnect cycle.
- Revocation — If the Entra app registration is removed or the client secret is rotated, the next renewal attempt fails and the agent disconnects.
Token Lifetime
Tokens have a default lifetime of 1 hour. The renewal loop runs indefinitely until the worker is shut down.
Related Resources¶
| Resource | Description |
|---|---|
| Agent Developer Guide | Step-by-step guide to building and deploying an agent with this SDK |
| LiveKit Platform Service | The backend service that issues tokens for the SDK |
| Bayer LiveKit Infra | The real-time media infrastructure agents connect to |
| LiveKit Agents Documentation ⧉ | Upstream LiveKit Agents SDK concepts and API reference |
| Environments & URLs | Non-production and production endpoints |