Capture and privacy

Voice agents handle some of the most sensitive data a company holds: recorded speech, transcripts of that speech, and the prompts built from it. Vaanieval captures only what your settings and integration supply. The core SDK and LiveKit integration have different defaults; review both before recording.

Defaults

VaaniObserver(
    capture={
        "audio": True,
        "http_bodies": False,
        "websocket_text_frames": False,
        "stt_content": False,
        "payload_max_bytes": 16384,
    },
)

Instrumentation boundaries

The built-in transport observers are not general-purpose packet capture:

• Authentication headers are not collected by the built-in HTTP and websocket observers. This is not a credential-redaction guarantee: URLs, metadata, manually supplied payloads and enabled body capture can contain secrets or identifying information.
• Streaming response bodies are not drained for capture. Doing so would hold back your first token.
• Frame-by-frame websocket contents are not recorded by socket observation. It records byte counts, frame counts and timings.
• Automatic provider capture requires a matching endpoint rule and ambient session (or an explicitly forced endpoint). Manually recorded operations and integration hooks can still write data independently of those rules.

Size bounding

Every captured payload — request, response and sample data — passes through a bound of payload_max_bytes (16 KiB by default). Oversized values are replaced:

{ "_truncated": true, "_original_bytes": 184320, "_preview": "{\"messages\":[{\"role\"…" }

Values that cannot be serialised become {"_capture_error": "…"}. Bounding is not redaction: a retained preview can still contain sensitive content.

Turning capture up

Debugging a specific problem usually justifies temporarily capturing more. Do it narrowly:

vaani = VaaniObserver(
    capture={
        "http_bodies": True,       # see the exact prompt sent
        "stt_content": True,       # see the transcript the model received
        "payload_max_bytes": 65536,
    },
)

Note that STT evaluation requires transcript content. You cannot compute an estimated WER against a challenger model without the production transcript to compare. If you want the STT evaluation workspace, stt_content must be on for the calls you intend to review.

Where the data goes

Failure behaviour, and why it matters here

By default strict is False. Instrumentation errors are swallowed so that these failures usually degrade capture rather than propagate.

VaaniObserver(strict=True)   # raise instead of degrading, for staging

The cost is that capture can silently degrade. Two things make that visible:

capture_status in the manifest:

{
  "capture_status": {
    "events_complete": true,
    "audio_complete": false,
    "http_instrumentation": "active",
    "websocket_instrumentation": "active",
    "dropped_event_count": 0,
    "dropped_audio_chunk_count": 37
  }
}

The unverifiable class in the dashboard. A call whose capture is incomplete is ranked separately from failed and slow calls, because "we do not know what the caller heard" is a different statement from "the caller heard an error". It is never quietly folded into the healthy bucket.

Retention and deletion

Stated plainly, because the gap matters:

Spool directories are also not cleaned up automatically after a successful upload. On a busy agent host this is a disk-space concern; add a sweep of .vaani-spool for completed sessions to your deployment.

Capture choices and tradeoffs

Less capture reduces data exposure and disk use but also reduces review coverage. More calls increase spool, dashboard and backup storage; optional evaluation adds external processing, provider charges and in-process queue contention. These settings do not turn the local dashboard into a hosted production service.

Next