STT-agnostic PII redaction for transcripts before they hit logs/storage

[kamil-bidus]

Feature Type

Would make my life easier

Feature Description

Right now there's no STT-agnostic way to redact PII from transcripts before they get logged or archived. The only native option is the Deepgram redact param (#5692), which runs at the vendor and only helps if you're on Deepgram. Switch STT and raw PII lands in your logs and storage again.

For anyone under GDPR/HIPAA/PCI that means writing your own redaction pass on every project. Would the team consider a documented redaction point - even just a recommended pattern on the end-of-call transcript callback - so this isn't tied to one provider?

Workarounds / Alternatives

We ended up building this ourselves: livekit-plugins-piiguard. Runs locally over the transcript, STT-agnostic, regex by default with an optional Presidio backend, and hands back a RedactedTranscript with per-entity counts for audit. Happy to upstream the pattern via the livekit-plugins-minimal template if that's a direction you'd want.

Additional Context

Cleanest hook I found is the end-of-call transcript callback: redact there, before anything gets persisted or forwarded downstream. Even if the answer is "keep it in userland," a documented pattern (and a pointer to community plugins that do it) would help anyone running voice agents on personal data.

[mcdgavin]

This one caught my interest and I ended up digging into it. Wanted to share one thing that reframed it for me, in case it's useful to whoever picks it up.

The leak isn't at a single point. PII can cross the process boundary in at least three places: the chat_ctx sent to a third-party LLM, chat content written into OTel spans/logs, and the transcript at persistence time. This issue is the third; #6204 is the first. They're worth solving together, because the natural home is a single redaction pass at the boundary rather than three ad-hoc hooks people re-wire per project.

The non-obvious constraint: it only works for the STT→LLM pipeline. There, text exists before egress, and the real chokepoint is the LLM-send boundary (where the default llm_node calls llm.chat(chat_ctx=...)) — that sees the whole context, including history and tool output, which on_user_turn_completed does not. For realtime / speech-to-speech models the user's raw audio is the egress, so in-flight redaction is structurally impossible — the only levers there are provider zero-retention and post-hoc transcript redaction (i.e. exactly this issue).

The shape that seems right to me: a small provider-agnostic Redactor protocol plus one opt-in knob on AgentSession, defaulting to a no-op so there's zero behavior change. Core owns where redaction happens (the boundary points); detection stays pluggable, so piiguard / Presidio / Deepgram's redact all become backends rather than one blessed dependency. I'd ship a regex reference impl in core for structured PII (Luhn/IBAN/SSN-validated) but document it loudly as best-effort, not a compliance guarantee. Fuller write-up here: https://gist.github.com/mcdgavin/91313d364c5eeb466f63f3c824ab89de

Before building anything: would the team be open to a small Phase-1 PR — the contract plus the LLM-egress seam, behind a no-op default?

[mcdgavin]

Update: the Phase-1 PR is up — #6342 adds the redaction contract (Redactor protocol + opt-in redaction= knob on AgentSession) and wires the LLM egress sink.

For this issue specifically: the transcript sink is Phase 2, already implemented and tested on a stacked branch (gmcd/pii-redaction-phase2); I'll PR it once Phase 1 lands. One finding worth noting from verifying the design against the codebase: transcript persistence isn't userland-only today — core uploads chat_history.json to LiveKit Cloud at session end whenever server-side recording is enabled, so the sink hooks that path in core (JobContext._on_session_end), covering the cloud upload, the per-item transcript log records, and the console dump, while session.history keeps raw values.

The RFC has been revised with everything learned from the implementation (corrected seams, threat-model updates, changelog in §13): https://gist.github.com/mcdgavin/91313d364c5eeb466f63f3c824ab89de