TRUST_BRIDGE

Don't trust the message. Verify the request. TrustBridge analyzes suspicious requests, explains the warning signs, and guides you to verify safely through a trusted channel

Comment

Inspiration

AI-generated voices, messages and impersonation are making it harder to tell whether a request really comes from the person it claims to be from. A message like "Hi, I'm your manager, I'm on a new number, send ₹25,000 now, don't call me" can look completely convincing. Most tools try to answer "is this fake?", and nobody can answer that with certainty. We asked a different question:

You don't need to know whether the person is real. You need to know how to safely verify the request.

What it does

TrustBridge helps people respond safely to suspicious requests in four steps:

  1. Analyze: the user pastes a suspicious message and optionally says who it claims to be from and how it arrived.
  2. Understand: TrustBridge gives a LOW / MEDIUM / HIGH risk level (no made-up percentages) with concrete warning signs such as urgency, identity uncertainty, financial requests, credential requests, and discouraged verification.
  3. Verify safely: a step-by-step plan to confirm the request through a channel the user already trusts, plus clear DO and DON'T lists.
  4. Practice: a short decision challenge where the user picks the safest response and gets immediate feedback.

TrustBridge is not a deepfake detector and never claims to know whether a sender is genuine. It is decision support. For vague requests it is designed to say there isn't enough evidence, while still recommending independent verification.

How I built it

  • Frontend: React + Vite (JavaScript, CSS) with small reusable components for the risk badge, risk factors, verification steps and decision options.
  • Backend: Node.js + Express with one endpoint, POST /api/analyze.
  • AI: Google Gemini, called from the server only through its OpenAI-compatible endpoint. One model call per analysis.
  • Structured output: the model must reply in a fixed JSON format. The server validates it (allowed risk levels, required fields, limits), retries once if it is malformed, and otherwise returns a safe error.
  • Decision challenge: deliberately not AI-generated. It is a fixed scenario graded locally, so feedback is predictable.

Security choices: the API key lives only on the server in a git-ignored .env; input is length-limited and validated; requests are rate-limited; the pasted message is treated as untrusted data in the prompt; error messages are generic; and user messages are not logged.

Challenges we ran into

  • Provider and model issues: we moved from one AI provider to Gemini and hit 404 errors (model names that don't exist for our key), 503 errors (an overloaded model) and a timeout from a "thinking" model. We fixed these by testing models directly, switching to a lighter one, adding retries, and raising the timeout.
  • Reliable structured output: language models sometimes return malformed or incomplete JSON, so we built server-side validation instead of trusting the output.
  • Avoiding overclaiming: we kept the product honest, with no fake probabilities, no "verified" labels and no deepfake claims, and wrote the prompt so ambiguous requests aren't automatically labeled HIGH risk.
  • Project structure: splitting a single frontend into client/ and server/ and wiring them together with a dev proxy taught us a lot about how the pieces connect.

What we learned

  • Why the API key must stay on the server, and how a backend sits between the browser and the AI.
  • How to validate AI output and handle failures gracefully.
  • That a good safety product is about guiding the next safe action, not just classifying content.
  • How much prompt wording shapes honesty: telling the model not to invent facts and to admit missing information.

What's next

Ideas we have not built: a browser extension, email integration, and organization-specific verification workflows. We also want more decision-challenge scenarios based on different kinds of requests.

Limitations

TrustBridge is not a guarantee of fraud detection. AI analysis can be imperfect, and the challenge currently uses one fixed scenario. Always verify important requests through a channel you already trust.## Inspiration

Accomplishments that we're proud of

  • We built a complete working product from end to end: landing page, request input, AI risk analysis, verification plan, decision challenge and feedback, all connected to a real backend and the Gemini API.
  • We avoided the common trap of overclaiming. TrustBridge gives LOW, MEDIUM or HIGH with concrete reasons, never made-up percentages, and never claims to know whether a sender is real.
  • We made the AI output trustworthy: the server validates every response against a fixed structure, retries once, and shows a safe fallback instead of broken data.
  • We kept security serious: the API key stays on the server, input is validated and rate-limited, and user messages are not logged.
  • We kept the decision challenge deterministic on purpose, so the learning moment is reliable and doesn't depend on the AI.
  • We worked through real provider problems (wrong model names, overloaded models, timeouts) by testing directly and fixing each cause instead of guessing

What's next for TRUST_BRIDGE

  • More decision-challenge scenarios covering different kinds of requests, such as OTP, links and family emergencies.
  • A browser extension and email integration, so people can check a request where it arrives.
  • Organization-specific verification workflows, for example a company's own approval process for payments.
  • Broader testing with real, anonymized examples to improve how well the analysis handles unclear requests.

These are ideas, not features that exist today

Built With

Share this project:

Updates

Submission history