How Scam AI and TinyFish vet candidates and claims

By Xingyu (Alex) Shen, Founding Engineer, Scam AI

Scam AI and TinyFish have combined two checks into one review for hiring and insurance claims. TinyFish finds and reads the public web pages behind a candidate or a claim. Scam AI checks the submitted file, ties each page to the case and writes down what remains unverified. Reality, our review workspace, puts all of it in front of the person who decides.

Both decisions need both checks. Before a job offer goes out, a recruiter wants to know that the candidate's background holds up and that the interview video is genuine. Before an adjuster approves a payout, they want to know that the repair estimate came from the business named on it and that nobody changed the amount.

A web search can find a candidate's projects or a repair business's website; a file detector can find signs that a video or a PDF was altered. Neither answers the whole question alone. The two scenarios below are the ones we are filming; the recorded runs after them are the evidence so far.

At a glance

• Who: Scam AI detects altered and AI-generated video, images and documents; TinyFish builds web infrastructure for AI agents.
• What: a review workflow for two decisions: send the offer, pay the claim.
• The split: TinyFish retrieves and reads public pages. Scam AI checks the file and organizes the evidence. A named reviewer decides.
• Proof: two recorded runs with public receipts: seven pages bound and five résumé statements supported for my own résumé; three official sources answering for a sample vehicle claim.
• The principle: every finding shows its source, every gap stays visible, and the next check is named.

Before the offer: the candidate and the interview

A hiring team is ready to make an offer to a remote engineering candidate. The recruiter has the résumé, the candidate's links, and an interview recording the candidate agreed to have checked.

TinyFish starts from those links. Its web search API returns results, each with a URL, a title and a snippet. Its web fetch API loads the pages our selection policy picks in a real browser and returns their text. The selection policy is a versioned rule for which kinds of source may answer which statement.

TinyFish retrieves the page; whether it belongs to this candidate, and what it supports, is our question. A namesake's page stays separate, and a page that cannot be found does not count against the candidate.

The interview recording gets its own check. The video file goes to the Eva V1.6 Detection Model, which reports whether the footage shows signs of a face swap or other manipulation. That result is about the file: it cannot say who the speaker is, just as the web results cannot say whether the video was altered.

The recruiter sees both sets of findings and the one open question: the candidate's identity. Next comes a live call with an independent identity check; the recruiter, not a score, decides whether the offer goes out. That is the hiring fraud review we built this for.

Before the payout: the repair business and the estimate

An adjuster has a repair estimate for $40,180.00 and is about to approve it. In our sample, the original total was $4,180.00. We added one digit and left every line item in place.

TinyFish's part is the issuer. From the approved business details, Search and Fetch find its website or public records, which show that it exists and what it says about itself. They cannot prove that this PDF came from it.

Scam AI's part is the file. The document detector examines the exact bytes submitted, including the PDF's structure, metadata and revision history, for signs of editing after issue.

The adjuster sees the public context, the file result and the missing verification. The next action is to request the original from the issuer through an approved channel: a concrete step for an insurance claims reviewer before deciding on payment. Both sample PDFs are here: original and altered.

What we have run so far

The runs below are different cases from the two scenarios; every number links to its receipt. Both exercise the web half of the review; a public file-check receipt is still to come.

A public-context review of my own résumé

I authorized a review of my own résumé, starting from two anchors I supplied: my GitHub handle and my personal domain. Seven Search calls returned 46 results; our policy picked seven pages and Fetch read them all: my GitHub profile and a repository, my portfolio, an arXiv paper, Duke and DKU pages and my Google Scholar profile (search receipt).

Each page earned its place through a route it can show, never through my name. The GitHub profile links back to my domain and lists the same Scholar ID; the portfolio links the same projects; the Duke, DKU and arXiv pages carry the same project titles. MiniMax-M3 wrote that linkage down with citations, and Reality passed all seven sources on provenance and attachment (packet). The same rule kept out directory pages listing more than 100 other people named "Xingyu Shen" and a name-only Scholar result.

The result: five résumé statements checked, five supported by cited sources, each with its limit stated: an author listing shows association, not the scope of a contribution (report). No image, video or PDF detector ran here. Its conclusion, as printed:

Enough to choose an interview; not enough to choose an offer.

Public vehicle context for a sample claim

A sample claim supplied a 2011 BMW X3's year, make, model and a partial VIN pattern from training material, never a complete VIN. Three Search calls returned 20 results and Fetch read three official sources. NHTSA's vehicle decoder identified the model as an X3 xDrive35i and flagged the incomplete VIN; NHTSA's recall list for the model year returned four records; a BMW page gave the 300 hp specification.

That is what the public web can say about a model, and no more. The readiness record binds it to the case with its limits. With a complete VIN, the vehicle's own records arrive through the carrier's first-party lane, where the VIN never touches a public route. The sample had neither. The record marked the claim ready for triage but not for payment or denial, and listed the six evidence groups still needed, the full VIN and the carrier's history first. The report ended:

NOT PAYMENT-READY. Continue intake.

The adjuster gets a precise request list rather than a guess.

Two held-out runs, a second résumé and a Kia claim, behaved the same way; those receipts are internal.

What the reviewer receives

The output is a readable report and a structured record with the same findings; the hiring packet above shows the format. A reviewer can answer four questions without redoing the run:

• What supports this statement? The source, its URL, when we read it and what it actually says.
• Is it about the right person or case? How we matched the source, with namesakes and conflicting information left visible.
• What happened when the file was checked? The exact file, the detector version, the result and its limits, or an explicit note that the check did not run.
• What is still needed? A live identity check, an issuer original, another document, or a look at conflicting evidence.

How the Scam AI and TinyFish integration works

Six stages, one owner each:

1. Open the packet. Customer. The packet is the case as submitted: the authorized files, the permitted sources and a named reviewer.
2. Compile claims. Parser and policy. Each statement to check becomes its own row, with the supplied links and identifiers extracted. Nothing private, a file's contents or a full VIN, goes into a public query.
3. Acquire. TinyFish. Search finds candidate sources; our selection policy decides which ones Fetch reads.
4. Verify. Reality. Each source is bound to the case by its hash and tested for whether it belongs to this person or vehicle and what it supports.
5. Check the file, organize. Reality and MiniMax. Authorized files go to the detector. When the MiniMax-M3 language-model step runs, it organizes rows that already carry a citation and cannot add facts.
6. Review. Customer. The reviewer reads the evidence and its limits, then requests what is missing or decides.

Six stages, one owner each; orange marks TinyFish's step, teal a Reality check, white a human step.

Why does a run stop instead of scoring?

The résumé run shows how a page earns its place: through an anchor the candidate supplied or a link from one, never through a name alone. The vehicle run shows how a gap is handled: model-level facts are labelled, and the missing VIN becomes a named request. When a source is unavailable, an identity is ambiguous or a detector cannot run, the report keeps that gap visible.

The system contract has one success state, EVIDENCE_PACKET_READY. It means the material is ready for human review, not that the candidate passed or the claim should be paid. It also names 15 reasons a run can stop:

AUTHORIZATION_REQUIRED · INTAKE_INCOMPLETE · POLICY_OR_JURISDICTION_REQUIRED · CLAIM_TOO_BROAD · AMBIGUOUS_ENTITY · NO_TEXT_BRIDGE · SOURCE_UNAVAILABLE · SOURCE_VERSION_CHANGED · RIGHTS_BLOCKED · INSUFFICIENT_PUBLIC_EVIDENCE · CONFLICTING_EVIDENCE · MEDIA_UNRESOLVED · MODEL_SCHEMA_REJECTED · SELECTION_AUDIT_REJECTED · FIRST_PARTY_VERIFICATION_REQUIRED

A named stop makes an unfinished check explicit and never turns missing evidence into a finding about the person or the claim. The contract also forbids outputting a hire, a rejection, a ranking or a payment decision.

For engineers: how the evidence stays checkable

We call the saved record of each search or file check a receipt: what we sent, what came back and the status. A SHA-256 hash, a fingerprint of the saved bytes, pins down which exact response or file a result refers to. It does not make the contents true.

The first query in my hiring run was "shenxingy" "alexshen.dev" "Scam AI": the handle and domain I supplied, plus my employer. The saved Search response keeps its positions and hash; each page selected for Fetch records why the policy chose it and whether retrieval succeeded.

Every source row carries nine required fields: source_id, url, source_class, capture_time, selection_audit_id, selection_route, selection_reason, fetch_status and text_sha256. A failed retrieval is still a row, with its status. The reviewer's decision sits in its own record and cannot change the evidence or its hashes.

What's next for the Scam AI and TinyFish integration

Two short films will show the hiring and claims scenarios end to end; their detector and search captures are still to come. Sources behind a login, such as a carrier portal, can enter the packet through a separately authorized lane. That lane is TinyFish's web agent for multi-step web tasks or its browser sessions for agents, under the same provenance rules; neither recorded run needed it.

If you review candidates or claims, talk to us about running this on your own material.

Read the other side of this story: How scam.ai verifies hiring candidates and insurance claims with TinyFish.

FAQ

Does the Scam AI and TinyFish integration decide whom to hire or which claim to pay? No. It assembles evidence and names the open questions; the authorized reviewer decides.

Does finding a profile verify a candidate's identity? No. A matching name never connects a page to a person, and public context cannot replace an independent identity check.

What happens when there is no public information? The report records the gap and names the next step, a direct question or a first-party check; a limited web presence is not a negative finding.

What happens to private data? Full VINs, identity-document numbers and file contents stay out of public queries; the system contract bars a complete VIN, owner identifiers, a policyholder's name and credentials from any public packet.

Learn more about TinyFish: web search API · web fetch API · multi-step web tasks · browser sessions for agents

Scam AI × TinyFish · 2026