calle-ai/awesome-phone-call-agents/call-attest-challenge-auth

call-attest-challenge-auth

An offline spoken-code coordination experiment.

This companion to dialtone-handshake generates an illustrative short code derived from a pre-shared secret and checks a supplied transcript for a fuzzy match. A matching code is only a text-level coordination signal; recorded nonce reuse may indicate replay or an operator error. Neither result authenticates a counterparty or authorizes sensitive disclosure.

When To Use

• to rehearse a coordination exchange between consenting test participants
• to flag a challenge recorded in the optional local nonce ledger
• to generate the challenge goal for plan_call and the expected code to

verify against

When Not To Use

• to recognize whether the other end is AI at all; use

dialtone-handshake

• to authenticate humans; spoken codes leak through the audio channel to

anyone listening

• against a determined man-in-the-middle who can hear and relay the code;

this protocol does not defend against that (see safety.md)

• to authorize sensitive disclosure or any financial, medical, employment,

safety or other consequential operation, even when the label is VERIFIED

Workflow

Craft the challenge

CALL_ATTEST_SECRET=<shared secret> python3 scripts/attest_auth.py craft --scenario attestation-call --language en

Reads the secret from the environment (never the command line), generates a nonce, derives the 4-token code (2 colors + 1 number word + 2 digits) from HMAC-SHA256(secret, nonce), and emits the plan_call goal that speaks the nonce. The expected code travels in the craft output only - keep it local.

Verify a finished call

python3 scripts/attest_auth.py verify --transcript path/to/call-result.json --nonce <nonce> --expected-code "BLUE ORANGE SEVEN 42" --ledger nonce-ledger.jsonl

Checks that an agent turn spoke the nonce and a callee turn replied; normalizes tokens (digit strings expand to digit words, FOR/TO/WON confusables fold) and fuzzy-matches with edit distance <= 1 per token in order. Emits a card:

• attestation: VERIFIED / FAILED_NO_RESPONSE (reason

challenge_not_spoken or no_response_after_challenge) / FAILED_MISMATCH / REPLAY_SUSPECTED

• evidence: masked spans with kinds challenge_spoken and response_heard
• recommended_action: accept_and_continue / reject_caller /

investigate_replay

• With --ledger: a verified nonce is appended to the JSONL ledger; a

nonce already present yields REPLAY_SUSPECTED.

VERIFIED and accept_and_continue are legacy output labels for an advisory fuzzy match, not authentication decisions. Without a ledger reuse is not checked. The local ledger is sequential-only, not a durable or concurrent replay defense. Inputs must come from a trusted operator; empty values and altered transcripts are not a security boundary.

Why a spoken code and not an audio watermark

This example uses text-level spoken-code matching because it needs no audio model. It does not benchmark watermarking or spoken codes over telephone networks, and makes no claim that AudioSeal or SilentCipher necessarily fails on the PSTN. Audio quality and transcription errors remain limitations.

Scientific Foundation

Neither watermarking scheme is used here. These references do not validate this short-code design or establish telephone-band performance.

Differences from sibling skills

• dialtone-handshake proposes an agent-to-agent handshake; this skill

illustrates a separate offline spoken-code check without switching modes.

• call-fraud-shield detects scam patterns in conversations; this skill

provides an advisory coordination signal, not counterparty authentication.