Inspiration

Scam calls often succeed by creating urgency before people have time to think. We built CallShield to provide a calm, immediate warning when a caller asks for sensitive information such as verification codes, passwords, payments, or remote computer access.

What it does

CallShield is a consent-first, local voice-safety assistant. During a synthetic demonstration call, it:

  1. Uses Cartesia Ink 2 to transcribe the caller.
  2. Applies deterministic security rules for dangerous requests.
  3. Displays and speaks an immediate warning using Cartesia Sonic 3.5.
  4. Uses Claude Sonnet 5.5 to explain the warning using specific transcript evidence.
  5. Retrieves an allowlisted official support source through our Apify Actor.
  6. Creates a redacted incident summary that can be exported or deleted.

CallShield evaluates behavior—not identity. It never claims that a caller has been authenticated or that a call is completely safe.

How we built it

The interface is a static-friendly Next.js and TypeScript application running locally. A FastAPI backend manages short-lived sessions entirely in memory.

Audio is streamed to Cartesia in approximately 100 ms frames. Final transcript segments enter a deterministic rules engine before any language-model response is considered. This ensures that a verification-code or remote-access request immediately establishes a warning that Claude or external evidence cannot lower.

API credentials remain server-side, raw audio is never persisted, and sensitive values are redacted before being sent to Claude.

Challenges we faced

The largest challenge was combining low-latency audio, asynchronous provider responses, and strict safety behavior without creating misleading certainty.

We also had to handle changing realtime API contracts. Cartesia's current Auto STT endpoint requires a separate API version from TTS, so we validated both interfaces directly against the live service.

Another challenge was designing failure behavior. If Claude, Cartesia, or Apify becomes unavailable, the deterministic local rules must continue working and the interface must clearly label the degraded provider.

What we learned

We learned that AI security products should separate immediate policy decisions from probabilistic explanations. Deterministic rules are effective for urgent safety boundaries, while Claude is valuable for explaining evidence in language users can understand.

We also learned that an official webpage can provide a safe contact path, but it cannot prove the identity of the person calling.

What's next

Future work could include additional scam scenarios, more allowlisted organizations, accessibility testing, and carefully reviewed telephony support. Persistent storage, automatic account actions, and cloud deployment remain intentionally outside the current privacy-first prototype.

Built With

Share this project:

Updates

Submission history