The SAME credential under a NON-secret variable name, passed alongside the
one above and read from an X-Pouchy-Voice-Token header.
WHY A TWIN, 2026-08-12, from four field readings. ElevenLabs invoked the
tool and the Authorization header arrived carrying the literal
{{secret__pouchy_voice_token}} — 30 characters, unsubstituted — even
though the client sent the variable in conversation_initiation_client_data
and the agent carried a placeholder default. The most economical
explanation is that the secret__ class exists precisely to stop a CLIENT
from setting it: a browser able to inject arbitrary secret__* values would
make the class worthless, so EL ignores client-supplied ones. Our design was
doing the exact thing that class is built to prevent.
Sending both makes the next call decide it: if the plain twin arrives and
the secret one does not, the hypothesis is confirmed AND recall works in the
same deploy; if neither arrives, the hypothesis is refuted and the prefix was
never the issue. The endpoint records WHICH one authenticated.
The security delta is small and worth stating plainly: the browser already
holds this credential (it is what passes it), it is call-scoped, read-only,
TTL-bounded and rate-limited per call, and it is referenced ONLY in a tool
header — never in the prompt — so it does not enter the model's context
either way. What secret__ would have bought is protection against a prompt
reference we do not make.
The SAME credential under a NON-secret variable name, passed alongside the one above and read from an
X-Pouchy-Voice-Tokenheader.WHY A TWIN, 2026-08-12, from four field readings. ElevenLabs invoked the tool and the Authorization header arrived carrying the literal
{{secret__pouchy_voice_token}}— 30 characters, unsubstituted — even though the client sent the variable inconversation_initiation_client_dataand the agent carried a placeholder default. The most economical explanation is that thesecret__class exists precisely to stop a CLIENT from setting it: a browser able to inject arbitrarysecret__*values would make the class worthless, so EL ignores client-supplied ones. Our design was doing the exact thing that class is built to prevent.Sending both makes the next call decide it: if the plain twin arrives and the secret one does not, the hypothesis is confirmed AND recall works in the same deploy; if neither arrives, the hypothesis is refuted and the prefix was never the issue. The endpoint records WHICH one authenticated.
The security delta is small and worth stating plainly: the browser already holds this credential (it is what passes it), it is call-scoped, read-only, TTL-bounded and rate-limited per call, and it is referenced ONLY in a tool header — never in the prompt — so it does not enter the model's context either way. What
secret__would have bought is protection against a prompt reference we do not make.