Building an Internship Scam Detective in 5.5 Hours: How TrustIntern Gets AI to Explain Risk

Title

Building an Internship Scam Detective in 5.5 Hours: How TrustIntern Gets AI to Explain Risk

Meta Description

A developer built TrustIntern in 5.5 hours, using Gemma 4 multi-agent OSINT to check whether internship offers are scams, with fully recomputable scoring rules—and an AI reviewer even caught a real bug in the author's code.

Article Content

As internship season arrives, messages like this start popping up in Indian student groups: "Congratulations, you've been accepted to our company! Please pay a 1,999 rupee registration fee to confirm your seat, and share your Aadhaar and verification code. This offer is valid for only 24 hours." The sender is a Gmail address, and the company website was created just a month ago. It works because students desperate to add that first line to their resume are the least likely to stop and verify.

Developer charancodes built TrustIntern in a single weekend over 5.5 hours—an "investigation desk" that uses multi-agent OSINT and explainable scoring to expose these kinds of scams. The project, entered in the Side Hustle track during the second week of Hacktoberfest, is betting on both Best Use of Gemma and Best Use of Entire.

From "Can Finish" to "Can Win": A Key Turning Point

When the project kicked off, the author's prompt to the Cursor agent was blunt: "This plan has to help me win the hackathon, so give me the best plan." The agent's response changed the entire direction of the project: "Your current plan can be finished, but it can't win. A score that judges can recompute by hand, with the exact original sentence next to each deduction, is what other teams won't have."

That line directly led to scoring.py. TrustIntern's core isn't getting an LLM to "feel" that an offer is suspicious—it's breaking risk down into fixed rules: upfront fee +25, email domain mismatch +20, requesting sensitive data +20, creating urgency or guarantees +10, using a personal email service +5. All scores add up with a cap of 100, and each item is bound to the sentence that triggered it.

Why Not Let Gemma Score?

The project has a "non-negotiable scoring boundary" hardcoded in CONTRACT.md: Gemma / OSINT never invents deductions. The docstring in gemma_client.py is just four words: Never scores.

Gemma 4 handles "thinking," not "number-crunching": as a planner, it decides which research agents to launch (company, recruiter, complaints, domain, documents, follow-up questions) based on the results of fixed checkers; as a multimodal reader, it directly reads the offer content in PDFs or phone screenshots. What actually adds up the scores is deterministic rule code that anyone can recalculate by hand.

The design trade-off is clear: in a tool that tells students "this offer looks risky," auditability matters more than cleverness.

OSINT (Open-Source Intelligence) refers to the methods of collecting, correlating, and analyzing intelligence from publicly available information. In TrustIntern's context, OSINT agents don't hack or access any private systems—they query domain registration records (RDAP), public company information, public recruiter profiles, complaint platform records, and other data that anyone could theoretically look up themselves. Traditional OSINT relies on manual, item-by-item searches, which are time-consuming and easy to miss things; multi-agent OSINT splits "check the company," "check the recruiter," "check the domain," and "check complaints" into independent agents that run in parallel, with a planner deciding what to look into next based on existing findings. The key advantage of this approach is traceability: each agent's query targets and returned results can be recorded, forming a chain of evidence rather than a black box giving a "suspicious" verdict.

How Multi-Agents Collaborate: Planning, Execution, and Real-Time Streaming

TrustIntern's architecture can be broken down into four layers.

Fixed Checkers First

Before launching any agents, the system runs a round of checks that don't depend on an LLM: whether the recruiter email domain matches the company, the domain's registration date (via RDAP), the website itself, and the wording of the message text. These results go into an "evidence ledger."

RDAP (Registration Data Access Protocol) is the standardized successor to WHOIS, defined by the IETF for querying domain and IP address registration information, returning structured JSON rather than WHOIS's free text. Through RDAP you can obtain fields such as a domain's registration date, registrar, and last modified time. For anti-scam scenarios, the most critical is the domain registration date: a domain claiming to be the recruitment page of a well-known company but registered only a month ago is itself a strong risk signal. The "company website was created just a month ago" mentioned at the start of the article is exactly the kind of feature these checkers are designed to catch automatically. Compared to WHOIS, RDAP's JSON output is easier for programs to parse and incorporate into an evidence ledger, and it supports more standardized rate limiting and authentication mechanisms.

Gemma 4 Plans Agents with Boundaries

The planner reads the checkers' findings and then decides which agent to dispatch next: if a recruiter name appears, check the person; if an unfamiliar domain appears, check the domain. The key constraint is the allowlist—as written in registry.py, "unknown types returned by the planner are never executed." There are also hard limits of at most 8 agents, a depth of no more than 2 levels, and an overall wall-clock time of about 45 seconds.

If the model is completely unreachable, a heuristic planner takes over, and the investigation can still run to completion.

Hybrid Deployment and Real-Time Streaming

For local development, the author runs gemma4:e2b on his own laptop via Ollama, which is fast. The hosted demo can't access his laptop, so it falls back to Gemma 4 provided through the Google Gemini API (gemma-4-26b-a4b-it), which belongs to the same open-weights family.

The investigation process is streamed to the frontend in real time via SSE (Server-Sent Events): checker events appear first, then spawned agents, and finally findings. The frontend uses Vite + React to build the investigation desk, with jsPDF handling PDF report export.

SSE (Server-Sent Events) is a one-way server-push technology based on HTTP, where the server continuously sends events in text/event-stream format to the browser over a long-lived connection. Unlike WebSocket's two-way communication, SSE only does server-to-client push, has a simpler protocol, supports automatic reconnection, and can directly reuse ordinary HTTP infrastructure. TrustIntern uses it to push the investigation process to the frontend step by step: checker events, agent spawning, and findings appear in sequence, so the user sees a real-time "investigation in progress" process rather than a conclusion suddenly popping up after tens of seconds of waiting. This progressive presentation is important for building trust—users can see for themselves what was checked at each step and what was found, rather than just facing a final score.

Business Logic: Free for Students, Paid by Institutions

TrustIntern's pricing deliberately avoids the people being targeted by scams.

• Free for students: The people being targeted shouldn't have to pay for protection, and local Gemma makes running costs nearly zero.
• Paid by universities and career guidance centers: Bulk verification of offers circulating in student WhatsApp groups, with a shareable report generated for each.
• Paid API for job boards and internship platforms: Screening job listings and recruiter accounts before they go live.
• One-time fee for post-incident review reports: Giving people who have already been scammed a complete record with evidence that can be attached to complaints to schools, platforms, or cybercrime portals.

The last idea didn't come from the author—it came from the first tester. This early user said: "This can stop internship scams from affecting unaware people, and it can also become a review report for those who are more clear-headed." So "review mode" went straight into the pricing plan. There are currently no paying customers, and the product is in free beta.

Honest Record-Keeping: An AI Reviewer Catches a Real Bug in the AI Author's Code

The most interesting part of this project is that it keeps complete "receipts"—the developer used DevRelay to archive agent sessions and Entire to bind agent work to git commits.

13 commits carry Entire-Checkpoint: trailers, and six trail runners are configured in the repo (Risk, Security, Drift, Confidence, Review, Summary). Each time a PR branch is pushed, they run and post their scores to that PR's trail.

Interestingly, an AI reviewer caught a real blind spot in the AI author's Gemma integration. At backend/app/agents/planner.py:141, a medium-severity finding noted: the planner summary only set had_pdf and never reported that an image was uploaded. When Gemma acts as the planner, faced with a pure image upload it only sees had_pdf=false, and may therefore decide not to launch the vision agent, so the screenshot would never be read.

This is exactly the feature the author built to win the Gemma category. The author himself called it a "slap in the face": a blind spot in code written by an AI author was caught by an AI reviewer in the very same feature. The had_image fix is at the top of the to-do list.

Using entire search to Explain Why Code Exists

When the author forgets why a piece of code is the way it is, he doesn't grep the code—he searches the agent history:

$ entire search --json --compact fallback
→ 1821b7f  Add spawn planner with Gemma path and heuristic fallback.

$ entire search --json --compact vision
→ eed6eba  Let Gemma vision read an offer screenshot as well as a PDF.
→ 5c8fe31  Switch Gemma to local Ollama and ship PDF reports on Vercel.

However, the author also admits he hit a snag: the capture hook he wrote was a Windows-specific cmd.exe one-liner, and early setup sessions fell silent after being triggered. The 13 checkpoints linked to commits correctly, but the transcripts inside only retained the setup prompt. The advisory agent told him bluntly: "You cannot retroactively re-register these thin checkpoints." So the DevRelay sessions are the project's real build record, and Entire provides the skeleton.

Trail runner here refers to a set of checkers that automatically run each time a PR branch is pushed, each evaluating changes from a different dimension and giving a score, with results posted to that PR's trail. The six runners roughly divide their work as follows: Risk assesses the risk surface introduced by the change, Security checks for security issues, Drift detects deviations of the code from established contracts or design intent, Confidence measures the trustworthiness or test coverage of the change, Review makes code-review-like quality judgments, and Summary generates a change summary. They differ from traditional CI tests—tests judge "pass or fail," while trail runners are more like an ever-evolving review record that leaves a trace of the rationale behind each change. That's precisely why the Review runner was able to point out a logic blind spot like the planner summary omitting had_image at planner.py:141, which ordinary unit tests might not cover.

Why Open Source Matters

The author boils down the value of open innovation to four points, each grounded in a specific design decision.

Privacy. Offer letters contain names, addresses, and sometimes ID numbers. When Gemma 4 runs locally via Ollama, these documents never leave the laptop.

Cost. A free tier for students only works if the cost per check is close to zero, and running open-weights models on your own hardware makes that feasible.

Model replaceability. The planner connects to "a Gemma," not a specific vendor's endpoint: local gemma4:e2b, Gemma 4 on the Gemini API, or a heuristic fallback when there's no model at all.

Auditable scoring. The most important part isn't AI at all—it's the deterministic rules in scoring.py that anyone can read and recompute.

Next Steps

The project's roadmap includes: review report mode (organizing an incident timeline in complaint format), a WhatsApp/Telegram forwarder (so students can verify offers right where they actually arrive), bulk verification for career centers, and fixing the issues found by the reviewer—had_image first.

The code is open source under the MIT license, and the API contract (including scoring rules) is in backend/CONTRACT.md. The lesson from this project may go beyond anti-scam: when AI agents start writing code, a recomputable rule layer and a complete build trail may matter more than the model itself in determining whether a product is trustworthy.

One-line Summary

A developer built a multi-agent anti-internship-scam tool in 5.5 hours, with rule-based scoring and AI doing only the planning.

Paragraph Summary

TrustIntern is an anti-internship-scam investigation tool built by developer charancodes in 5.5 hours during a hackathon, targeting fake offer scams encountered by Indian students. Its core design puts risk scoring in deterministic rule code (upfront fee +25, domain mismatch +20, etc.), with each deduction bound to the sentence that triggered it so anyone can recompute by hand; Gemma 4 only plans agents and reads PDFs/screenshots, never participating in scoring. Architecturally, it uses an allowlist-constrained planner with at most 8 agents, depth of 2 levels, and about 45 seconds, with heuristic fallback when the model is unreachable. In terms of business model, it's free for students and charges universities, job platform APIs, and post-incident review reports. The project also uses Entire to record the build process, and an AI reviewer unexpectedly found a real blind spot in the author's Gemma integration.