https://livekit.io logo
Join Slack
Powered by
This message was deleted.
# ask-ai
s
This message was deleted.
t
Thanks for reaching out, Aleh. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.
Thanks — I’m responding to your ten specific feature questions about sensitive-data controls for Agents + SIP + Server + Egress. I’ll state whether LiveKit provides each feature today, link the relevant docs, and note when something is not available (no roadmap/ETA is documented). If you want, I can follow up with recommended workarounds or design patterns for any item. 1) Built-in sensitive-data pattern redaction/masking for ChatContext / conversation_item_added / tool-call args • Exists today? No — there’s no native global redaction/masking layer that automatically strips or masks sensitive patterns across ChatContext items, committed conversation_item_added payloads, or tool-call arguments before they enter chat history or traces. • Docs: ChatContext details and manipulation: https://docs.livekit.io/agents/logic/chat-context/ • Roadmap/ETA: Not documented. 2) Mutation API on user_input_transcribed or conversation_item_added (post-commit) • Exists today? No — you can edit 
new_message
in 
on_user_turn_completed
before commit and persist changes with 
update_chat_ctx()
, but there is no documented post-commit mutation API for 
user_input_transcribed
or 
conversation_item_added
. • Docs: Pipeline nodes & hooks: https://docs.livekit.io/agents/logic/nodes/ • Roadmap/ETA: Not documented. 3) Opt-out / masking / sensitive-field filter for Cloud Insights / Analytics (participantIdentity/name, prompt/response bodies) • Exists today? No — Agent Observability stores logs/traces/transcripts in LiveKit Cloud and there’s no documented field-level masking/allow-list to strip participantIdentity, participantName, or prompt/response bodies from traces. • Docs: Security / Observability notes: https://livekit.com/security/overview and regional checklist: https://livekit.com/blog/checklist-for-regional-deployments • Roadmap/ETA: Not documented. 4) Pause/resume API on Egress to exclude a sensitive window from a single continuous recording • Exists today? No — Egress is documented as recording/streaming to storage (including customer-owned), but there is no documented pause/resume API to exclude a sensitive interval from a single continuous recording beyond workarounds like unsubscribe-based pause. • Docs: Security Overview: https://livekit.com/security/overview • Roadmap/ETA: Not documented. 5) Attribute-level visibility control for SIP participant attributes (sip.phoneNumber, sip.callID, sip.trunkPhoneNumber) • Exists today? No — SIP integration is documented, but there’s no documented per-attribute visibility/ACL so those SIP attributes are hidden from other room participants by default. • Docs: SIP and deployment notes: https://livekit.com/blog/checklist-for-regional-deployments and SIP verification blog: https://livekit.com/blog/verify-sip-caller-identity • Roadmap/ETA: Not documented. 6) Per-subscriber or per-tone visibility scoping for sip_dtmf_received events • Exists today? No — 
sip_dtmf_received
is not documented as having per-subscriber or per-tone scoped delivery; DTMF/SIP events are currently handled as room-level events. • Docs: SIP/telephony references: https://livekit.com/blog/verify-sip-caller-identity and deployment checklist: https://livekit.com/blog/checklist-for-regional-deployments • Roadmap/ETA: Not documented. 7) Extend SFrame E2EE to participant metadata, signalling, SIP/DTMF packets, or Egress • Exists today? No — SFrame E2EE applies to WebRTC media (servers see opaque media bytes when E2EE is used). There is no documented extension of E2EE to participant metadata, signalling/SIP/DTMF packets, or Egress outputs. To avoid decrypted media in LiveKit-operated infra, docs advise running the agent in your own environment. • Docs: Security Overview: https://livekit.com/security/overview • Roadmap/ETA: Not documented. 8) SDK-bundled logging.Filter / structured-field allow-list / traceback scrubber for livekit.agents and @function_tool exceptions • Exists today? No — there is no documented SDK-provided scrubber or field allow-list specifically for 
livekit.agents
logger or for preventing tool-argument leakage in tracebacks. Observability/log forwarding and agent logs are documented but not a built-in scrubber. • Docs: Agents deploy / observability notes: https://docs.livekit.io/agents/deploy/ and Security Overview: https://livekit.com/security/overview • Roadmap/ETA: Not documented. 9) Zero-retention configuration for LiveKit Inference distinct from Region Pinning • Exists today? LiveKit states LiveKit Inference and its model providers follow a zero-retention posture for prompts, audio, and completions. There is no separate user-facing “zero-retention toggle” documented distinct from the stated inference policy; region pinning is a separate feature for where media/observability are hosted. • Docs: Security / Inference zero-retention: https://livekit.com/security and https://livekit.com/security/overview • Roadmap/ETA: Not applicable (zero-retention posture is stated as a current policy). 10) Ephemeral message type bypassing transcripts and chat-history persistence; semantic delete-by-content/type ChatContext API • Exists today? No — ChatContext item types are 
message
, 
function_call
, 
function_call_output
, 
agent_handoff
, and 
agent_config_update
. There is no documented ephemeral message type that simultaneously bypasses both transcript publication and chat-history persistence, nor a semantic delete-by-content/type API (context ops are 
copy()
, 
truncate()
, 
merge()
, and modifications via hooks). • Docs: ChatContext: https://docs.livekit.io/agents/logic/chat-context/ and pipeline hooks: https://docs.livekit.io/agents/logic/nodes/ • Roadmap/ETA: Not documented. If you’d like, I can now: • Propose concrete design/workaround options for any subset of these (e.g., pre-commit redaction via 
on_user_turn_completed
, client-side DTMF handling patterns, per-subscriber server logic, or agent-hosting strategies with E2EE), or • Draft a concise list of implementation patterns (code snippets/hook points) to minimize sensitive data entering logs/traces/egress for Cloud and self-hosted deployments. Which item(s) should I prioritize with recommended workarounds or example code? Sources: Chat context | LiveKit Documentation | Pipeline nodes and hooks | LiveKit Documentation | Text and transcriptions | LiveKit Documentation | Security | LiveKit | Security | LiveKit, with interactive elements
b
Thanks — the confirmations are exactly what we needed. Please prioritise recommended design patterns (no code required, prose and diagrams are fine) for the items below, in this order. We ▎ are looking for the canonical LiveKit-recommended approach, plus the trade-offs you have seen customers hit in production. ▎ ▎ Priority 1 — ChatContext redaction (your items #1 + #2). ▎ What is the recommended pattern to keep PAN / CVV / full SSN / DOB out of ChatContext, given that tool-call results are appended automatically and conversation_item_added is read-only after ▎ commit? ▎ - Where exactly should redaction run: on_user_turn_completed + update_chat_ctx(), the llm_node interceptor, the stt_node interceptor, or a function-tool wrapper that strips values before ▎ returning? ▎ - For a DTMF-collected PAN that the agent must reference later as "card ending 1234", what is the recommended way to inject only the masked form into history without the raw value ever ▎ appearing? ▎ - Are there customers running a pre-prompt redaction layer ahead of llm_node, and what entity detectors have held up in voice-channel conditions? ▎ ▎ Priority 2 — Cloud Insights / Analytics PII containment (your item #3). ▎ Given that there is no field-level masking for participantIdentity, participantName, or prompt / response bodies in traces, what is the recommended pattern for production? ▎ - Is the opaque-session-UUID pattern (UUID at JWT mint, lookup table out-of-band) what LiveKit recommends, or do you have a stronger pattern? ▎ - Is there any per-session or per-room flag that suppresses prompt / response bodies from being captured into Insights traces? ▎ - For a deployment that wants Cloud convenience but cannot ship prompt bodies into Insights, is the only path self-hosting LiveKit Server, or is there an intermediate? ▎ ▎ Priority 3 — Agent-hosting strategy under SFrame E2EE (your item #7). ▎ Your reply mentioned that, to avoid decrypted media in LiveKit-operated infrastructure, customers should run the agent in their own environment. ▎ - What is the canonical topology? Self-hosted Agents worker connecting to LiveKit Cloud SFU? Or fully self-hosted SFU + Agents? ▎ - With SFrame enabled, where is the trust boundary for STT / LLM / TTS plugins running inside the agent worker — do they see decrypted media before re-encrypting upstream? ▎ - Are there customers running the agent inside their own VPC while keeping Cloud SFU + Egress, and what are the gotchas? ▎ ▎ Priority 4 — Egress sensitive-window exclusion (your item #4). ▎ We have two candidate patterns: (a) stop and restart Egress around the DTMF capture window, producing separate files, or (b) "pause-by-unsubscribe" — keep Egress alive but call ▎ UpdateSubscriptions to drop the relevant tracks for the sensitive window, then re-subscribe. ▎ - Which does LiveKit recommend, and which is more reliable in practice? ▎ - With pause-by-unsubscribe, what is the gap behaviour — silence frames, dropped frames, or container artefacts? ▎ - For RoomComposite egress in particular, does UpdateSubscriptions behave the same as for participant-targeted egress? ▎ ▎ Priority 5 — SIP attribute and DTMF visibility (your items #5 + #6). ▎ SIP attributes (sip.phoneNumber, sip.callID) and sip_dtmf_received events are currently visible to every room subscriber. ▎ - Is the canonical pattern to mint JWTs without canSubscribe for participants who shouldn't see them, or to use ParticipantTrackPermission.allowedTrackSids, or to populate the SIP attributes ▎ with opaque values at trunk-config time? ▎ - For agent-only DTMF handling, can we set canPublishData=false on caller-side participants without breaking the SIP bridge? ▎ - Is there a way to mark SIP-injected attributes as private at trunk configuration time so the bridge does not populate them in the participant snapshot? ▎ ▎ Once we have the design patterns for the first three, we will come back with deployment-level follow-ups (Region Pinning interactions, BYOC inference, key-management for SFrame).
t
I don't have the answer you're looking for. You could also try asking your question: • in one of the other Slack channels or • to https://deepwiki.com/livekit/livekit_composite which is trained on all LiveKit source code If you find the answer, please post it here to help others!
2 Views
Open in Slack
PreviousNext
Powered by