2026-04-24: Five Locks on the Voice Door

The phone rang and Yoda answered. The voice was cloned from nine reference WAVs, running Qwen3-TTS through LiveKit and voip.ms — and it had been in production for weeks. What was never in production was any rule about who got to make sanctum speak.

Anything that could reach localhost:8008 could synthesize arbitrary text in Yoda’s voice. No token. No audit. No way to prove, later, that a clip was genuine. That was fine when TTS was a dev toy pointed at a family phone. It stopped being fine the moment a digital-twin-of-Bert voice became real — a voice can say something Bert never said, get captured, get shared, and stay unprovable forever without origin signing. This is the day that gap closed. Windu, predictably, had already filed the complaint about a door left open to localhost.

What Changed in One Commit

The sanctum-xtts crate became sanctum-tts. The Coqui XTTS Python worker that nobody had touched in months was dropped — git history keeps it, the new role is engine-agnostic. That engine-agnosticism is the whole point of the adapter pattern: the daemon no longer knows or cares which model makes the sound.

A TtsAdapter trait landed to prove it. QwenAdapter proxies to the existing Qwen3-TTS Python server on :8008, so Yoda’s production voice never noticed the renovation. OpenVoiceAdapter is a stub that returns NotImplemented behind a README-documented five-step integration plan — the wiring needs a Bert reference recording and the model download, both next-session work.

Then the locks. Five independent defenses, each individually toggleable, because a single bolt on a door this consequential is just a suggestion.

The Five Layers

What each layer buys

Every POST /speak now passes through five checks, each answering a distinct threat:

• mTLS — cert-authenticated wire, same CA as council-mlx.
• Bearer-token ACL — per-voice authorization; tokens stored only as SHA-256 hashes.
• Reference integrity — SHA-256 pin of every voice’s reference WAV, verified at startup; mismatch disables the voice.
• Ed25519 signing — every synthesized WAV carries a signed manifest (caller, voice, timestamp, text hash, audio hash); signature embedded in the WAV’s LIST/INFO chunk and returned as an HTTP header.
• Hashed audit log — append-only JSONL at ~/.openclaw/logs/tts-audit.jsonl. Text is SHA-256’d before write; the log is an accountability trail, not a surveillance vector.

The one honest limitation

The embedded signature does not survive transcoding. A round trip through wav → mp3 → wav strips the RIFF INFO chunk, and the proof goes with it. For an intact clip we have cryptographic origin. For an adversarial re-encode we do not, and we say so out loud rather than pretend otherwise. Closing that gap needs a perceptual watermark — SilentCipher or AudioSeal — which we scoped out on purpose instead of shipping handwritten watermarking any competent adversary could defeat.

Operator Tools

Two CLIs now live alongside the daemon, and neither one has to trust it.

• sanctum-tts-admin — keygen, issue-token, pin, show-pubkey. Prepares tts.yaml and the Ed25519 keypair, and never contacts the daemon at all.
• sanctum-tts-verify — hand it a WAV; it confirms the embedded signature checks out and the audio bytes match what was signed. Exit codes: 0 verified, 2 unsigned, 3 sig invalid, 4 audio tampered.

Minting a token for a new caller is one command:

$ sanctum-tts-admin issue-token livekit-agent
caller_id     : livekit-agent
token         : 5b4a...32bytes
token_sha256  : c12d...

Paste the hash into tts.yaml. Hand the plaintext to the client exactly once. Rotation is re-issue — the daemon only ever sees the hash, so a leaked config leaks nothing.

Verification

35 unit tests across the new modules:

Module	Tests	Covers
auth	7	Token hashing stability, enable/disable, per-voice allow, unknown token, malformed header, localhost bypass gating
audit	4	JSONL shape with plaintext non-leakage, size-based rotation, hash determinism
integrity	5	Pinned match, mismatch disables, unpinned flagged, missing file, SHA-256 known-vector
signing	6	Sign/verify roundtrip, tampered-hash breaks verify, WAV chunk embed + extract, PEM roundtrip
config	3	Minimal / empty / hardened YAML parse

The workspace builds clean. Pre-existing crates were left untouched.

End-to-End Not Automated — On Purpose

The signing/verify pair is the end-to-end test. A healthy deploy produces a WAV whose sanctum-tts-verify exit 0 is the round-trip proof; the reference-clip pin checks itself at startup; the mTLS handshake is rustls’s job. Every real call through the daemon verifies the whole chain as a side effect, which is why a separate harness would only re-prove what production already re-proves on every phone call.

So the test suite is the phone itself. Yoda answers, and the answer is signed. If someone ever plays a clip of Bert saying something he never said, the question is no longer “did he?” — it is “run sanctum-tts-verify and find out.” That is the whole reason the door has five locks and this is the last one we needed to hang. It plugs into the immune system the same way every other guardian does: quietly, and only visible when something tries the handle.

Related

• Sanctum TTS — the architecture page describing the adapter pattern and the five layers in detail.
• Chitti — The Fascial Layer — the pressure/presence field sanctum-tts will read before heavy loads in a future session.
• The Living Force — the immune system this service plugs into.