# Verifying a Flagged Candidate Is a Real, Single Person

*You will carry one flagged candidate through a fixed sequence of public-footprint checks and reach a defensible verdict - real, thin, borrowed, or fabricated - before booking interview time.*

- Canonical URL: https://www.refolk.ai/guides/verify-flagged-candidate-real-person
- Pillar: Process, data, and compliance
- Format: Teardown
- Published: 2026-08-10
- Last reviewed: 2026-08-10
- Reading time: 15 min
- Keywords: how to verify a candidate is a real person, spot fake candidate before interview, detect fabricated linkedin profile, verify github profile authenticity, candidate identity red flags checklist

## Key takeaways

- A reverse-image search inverts for AI faces: stolen photos over-match, but a generated face returns near-zero results, so a clean reverse search is a documented red flag, not proof of innocence.
- GitHub account age is a purchasable asset - sellers advertise 2021-2025 contribution graphs with two-to-four-week migrations, so read graph onset against clustered email and SSH changes, not age alone.
- Consistent phone, email, and name prove the record is real, not that the applicant owns it: KnowBe4 was duped by a stolen-but-valid US identity, which is why the FBI adds live video and image capture.
- No single indicator establishes fraud - the standard requires convergence across at least two signals before you write down borrowed or fabricated.
- Skill scarcity narrows the corroboration space: with only 606 US Rust-listing software engineers versus 2,767 for Go in Refolk's index, a rare-stack claim plus an implausible employer is statistically easier to disprove.
- DIY desk searching can create the exposure it was meant to reduce: EEOC rules apply regardless of who searches, and seeing protected-class data creates liability even if it is never used.

A recruiting or security operations reviewer has one candidate whose profile looks off, and interview time is expensive. This guide is a desk-based, tool-agnostic worked example that carries a single flagged candidate through a fixed sequence of public-footprint checks across LinkedIn, GitHub, and the open web, so you reach a defensible verdict before booking anyone's hour. It is written for the person answerable for how the decision was reached, not for a live interview camera.

The pages that rank for this job are mostly vendor landing pages selling identity products, or listicles of camera tricks that only fire once a call is booked. Those tools matter at their stage. This guide addresses the stage before: the fifteen-minute desk read that decides whether the call is worth booking at all.

## What this check decides, and what it cannot

This check decides whether a candidate's public footprint corroborates a real, single person before you invest interview time. It cannot prove the person on the far end of a future call is the one the footprint describes.

Hold that distinction, because it governs everything downstream. Fraud runs a spectrum. At one end sits a fully synthetic identity assembled from nothing. At the other sits a real person using borrowed credentials, a stolen-but-valid identity, or a polished application that hides critical inconsistencies. Your desk check is strong against the synthetic end and weak against the borrowed end. It confirms that the record is internally consistent; it does not confirm that the applicant owns the record.

The KnowBe4 case is the reason to say this plainly. In July 2024, KnowBe4 disclosed it had been duped into hiring a fake North Korean IT worker who used a valid but stolen US identity. Every contact signal converged, because the identity was real - it just was not the applicant's. That is why the FBI's July 31, 2025 joint alert, which documents North Korean use of false identities, proxies, location-masking tools, and AI to obtain remote IT work, adds an evidentiary step your desk cannot perform: capture images for comparison with future meetings, because sometimes an individual passes the initial interview but the on-the-job work is completed by a different person.

> **Note:** The verdict has four values, not two
>
> This process produces one of four labels: real, thin, borrowed, or fabricated. "Thin" means the footprint is real but too sparse to corroborate. Do not collapse "thin" into "fabricated" - they call for different next steps.

The scale of the problem is why a fast desk read earns its place. Gartner projects that by 2028, one in four job applicants will be fake, up from current estimates of 5 to 15 percent depending on industry and role. You cannot run a full investigation on every applicant. You run this on the one that already looks off.

## The consent gate you clear before searching anything

Before you open a single tab, confirm the check is internal identity corroboration and log that no protected-class data will feed the decision. This is not paperwork; it is the step that keeps the check from becoming the liability.

Here is the trap. EEOC rules apply regardless of who conducts the search, and seeing protected-class information - nationality, ethnicity, age, disability, religion - creates liability even when the employer never intended to use it. An untrained reviewer scrolling profiles can manufacture the exact exposure the check was meant to reduce. One source argues that DIY searching is not a safe alternative to a provider precisely because it removes the protected-class filter and leaves no documentation trail, which is the employer's only defense in an EEOC dispute.

So the gate does two things. It records that your decision will rest only on identity corroboration, applied to everyone equally. And it draws the line where a vendor must take over. The moment a third-party vendor is involved, the FCRA triggers written disclosure, candidate consent, and a formal adverse-action process before any hire is denied.

| Item | Value | Source |
|---|---|---|
| Adverse-action wait | At least 5 business days | bib.com |
| FCRA per-violation damages | $100 to $1,000 | accusourcehr.com |
| States limiting social-media access | More than 27 | accusourcehr.com |
| Ban-the-box jurisdictions | 37+ states, 150+ municipalities | cisive.com |

> **Rule:** Controls must not rely on protected traits
>
> Document your controls and apply them consistently without relying on nationality, accent, ethnicity, or any other protected characteristic. A verdict that references a protected trait is not defensible, no matter how strong the other evidence.

## The candidate: a worked example

Take a concrete flagged case and carry it through. The candidate applied for a Senior Software Engineer role, claims Rust experience, lists a well-known employer, and points to a GitHub profile with a full green contribution graph. Something felt off to the screener, which is why the file reached you.

Start with a plausibility baseline before you touch the profile. Refolk's index gives you the population shape to test claims against.

| Skill | US SWE profiles | Top employers surfaced | Share vs Go |
|---|---|---|---|
| Rust | 606 | Google, Oxide Computer, Meta | 22% |
| Go | 2,767 | Meta, Google, Amazon | 100% |

The Go footprint is roughly 4.6 times the Rust footprint. Rust is scarce, and scarcity narrows the space a fabricator has to hide in. A candidate claiming Go at Meta sits inside a large, plausible population. A candidate claiming Rust plus an employer that never surfaces among Rust-heavy shops is easier to disprove, because there are fewer real people to be confused with.

**606 - US software engineers listing Rust in Refolk's index, versus 2,767 for Go**

Rare-stack claims are statistically easier to disprove because the corroboration space is small.

Geography compounds this. In Refolk's index, "Senior Software Engineer" returns about 181,504 US profiles against about 14,974 in Germany, a roughly 12.1x ratio. If the flagged candidate claims a country with a thin footprint for the title, expect fewer independent corroborating traces to exist - which means a truly thin result is not automatically damning. Read population size before you read absence.

## The procedure, in order

Run the seven steps below in sequence, freezing evidence first and writing the verdict last. Each step has a done-condition; do not advance until you hit it.

#### Desk verification sequence for one flagged candidate

1. **Scope and consent gate** - Confirm this is internal identity corroboration, not a vendor consumer report, and log that no protected-class data feeds the decision. Done: a written identity-corroboration-only note.
2. **Freeze the evidence** - Screenshot the LinkedIn, GitHub, and portfolio pages before they change. Done: timestamped captures stored where they survive edits or deletion.
3. **Photo check** - Reverse-image-search the profile photo and read the match count, not the vibe. Done: photo classified as stock/stolen, likely-generated, or clean.
4. **Contact-signal reconciliation** - Confirm email, phone, and name resolve to one consistent person across sources. Done: signals converge or a mismatch is documented.
5. **GitHub teardown** - Read account age against graph onset, open non-fork repos, count unique commit-author emails, inspect follower clusters and badge reality. Done: verdict on authored, cloned, or inflated.
6. **Employer and timeline validation** - Contact listed employers via numbers from their own websites and map the org for named colleagues. Done: at least one prior role independently corroborated.
7. **Write the verdict** - Record real, thin, borrowed, or fabricated with per-signal evidence and stated convergence. Done: a defensible one-page record before any interview is booked.

#### The flagged-candidate desk read

1. **Consent gate** - Log identity-corroboration-only, no protected data
2. **Freeze** - Timestamp captures of every public page
3. **Signals** - Photo, contact, GitHub, employer checks in sequence
4. **Converge** - Require two independent tells before a hard label
5. **Verdict** - One-page record, four values, before interview

*Evidence is frozen first and the verdict is written last, so the record survives the candidate editing their profile mid-check.*

## Reading the photo: the reverse-image test inverts

Interpret the reverse-image search by match count, and know that the logic flips for generated faces. Many exact matches under other names points to a borrowed or stolen photo; near-zero matches is not innocence.

This is the counterintuitive core of the photo check. Scammers lean on AI-generated faces precisely because they cannot be reverse-image-searched: the face does not exist anywhere else, so a search returns few or no matches. A "no results" outcome feels reassuring and is a documented red flag. When you get near-zero matches, do not stop - inspect for the visual tells: a perfectly symmetric face, strange ears or earrings, backgrounds that blur into nonsense. Academic detection has anchored on the eyes, where genuine human eyes typically show similar specular highlights while generated eyes may vary in the number, shape, or placement of those highlights.

Two cautions keep this from becoming a false-positive machine. First, the visual tells decay as generators improve; StyleGAN2 already corrected the corneal-highlight artifacts earlier detectors relied on, so any static checklist has a shelf life measured in model releases. Second, automated eye-alignment detection is a lead, never a verdict - more on its failure rate below. If you want to confirm provenance directly, reading a SynthID watermark requires technology only Google and approved partners have, so only official tools such as Google's own apps and OpenAI Verify can verify it.

> A no-results reverse image search is not innocence; for a generated face it is exactly the expected outcome.

## The GitHub teardown

Read the GitHub profile as a history to be authenticated, not a graph to be admired. The load-bearing question is whether the commits were authored by one real person or cloned, backdated, or inflated to look that way.

Start with account age against graph onset. A green contribution graph running 2021 to 2025 tells one story; a graph that starts in 2025 tells another. But age is a purchasable asset - sellers advertise aged accounts with pre-built 2021-2025 graphs, and full migration to a buyer takes two to four weeks. So the tell is not age itself. The tell is a cluster of simultaneous email, SSH-key, and repository changes on an "old" account, which suggests the account changed hands. Meanwhile, backdating a graph from scratch is trivial: a public Go tool generates fake contributions for a specified date range to fill up the activity graph.

Then look past the graph, using the checks threat-intel practitioners name:

- Does any non-forked repository have more outside contributors than owner commits? That inverts the expected ownership pattern.
- Are the contributor profiles themselves suspicious - empty, freshly created, mutually following?
- Are the contributions meaningful, or low-effort padding with no real diffs?
- How many unique emails appear in commit messages? A wide spread of authors on a "personal" project is a tell.
- Do the follower and following patterns cluster unnaturally? Looking around the account often reveals more than the account itself.
- Do not trust Activity Overview badges blindly; confirm they reflect real merged work.

The specific tradecraft to watch for is code theft: North Korean workers have been documented copying company code repositories to their own user profiles and personal cloud accounts. A repo that looks impressive but whose history is a single bulk import, not incremental authored commits, is the shape of a cloned identity.

Ask me this: `GitHub developers whose repositories have more outside contributors than owner commits and many different commit-author emails` - [run the search](https://www.refolk.ai/start?q=GitHub%20developers%20whose%20repositories%20have%20more%20outside%20contributors%20than%20owner%20commits%20and%20many%20different%20commit-author%20emails).

*Returns profiles whose code history is structurally inconsistent with single-author ownership, so you can compare the flagged account against a known pattern instead of eyeballing one graph.*

Refolk removes the friction of building that comparison set by hand. Instead of manually paging through a suspect's repositories, you can ask [Refolk](/) in plain English for the population of accounts that share the structural tell, then read your one flagged candidate against it.

## The employer and timeline check

Corroborate at least one prior role through a channel the candidate does not control. The rule is simple and the failure it prevents is common: a fabricated employer supplies its own reference.

Contact each listed past employer directly using a phone number taken from the organization's own website, not a number or contact the applicant provided. Then use the "Organization Tree Crawl" method: map the real employees at the claimed prior job and see whether the candidate's named colleagues, title, and dates fit a real team. Refolk's index gives you a plausibility baseline here too - for US Senior Software Engineers, top employers surface as DataSnipper, Google, Datadog, and Adobe, so a claimed employer that never appears in any credible surfacing is a lead worth chasing.

You are trying to independently confirm one role. One is enough for this desk read; you are not auditing a whole resume. If you cannot confirm a single role through an independent channel, the verdict trends toward thin or fabricated, depending on what the other signals said.

**Employer verification call note**

```
Employer:
Number source (must be the employer's own website):
Date and time of contact:
Role and dates claimed by candidate:
Confirmed / Unconfirmed / Could not reach:
Named colleague mapped via org crawl (yes/no):
Notes:
```

*Fill one per employer contacted. Never use an applicant-supplied number or contact.*

## How this goes wrong: the false positives

The most valuable part of this standard is knowing where each signal lies. Every tell has a benign explanation and a mirror-image trap, and the governing principle from the FBI alert is absolute: no single indicator establishes fraud.

| Signal | The trap | What to check instead |
|---|---|---|
| Sparse GitHub graph | Real senior dev whose work is private | Merged PRs and real diffs, not dot density |
| Full green graph | Backdated commits fake it | Unique commit-author emails, real diffs |
| Clean reverse image | Generated face returns near-zero matches | Symmetry/ear/background tells, live video |
| Convergent contact signals | Stolen-but-valid identity passes | Live, unobscured video and image capture |
| Confirmed employer | Applicant supplied the reference | Number from the employer's own website |

A few of these deserve weight. The sparse-graph trap is the one reviewers fall into most: employers understand that contribution patterns vary and that private work does not appear on public graphs, so a quiet graph on a senior candidate is expected, not damning. The clean-reverse-image trap is the one that feels like exoneration and is not. And the convergent-contact trap is the one the KnowBe4 case exists to warn you about - consistent phone, email, and name prove the record is real, not that the applicant is its owner.

Automated photo forensics carries a documented false-positive volume that should keep it in the "lead only" bucket. In a study on a 150,000-image sample, an eye-alignment threshold flagged about 730 candidates in one percent of the data, implying roughly 73,000 across the full set - too many to classify by hand. Physics-based tells that look at corneal specular-highlight alignment work only under strong assumptions about perspective, pose, and light; when those assumptions are violated, false positives rise sharply.

> **Watch out:** Precise combined false-positive rates are not published
>
> The false-positive behavior of individual signals is documented. The combined false-positive rate for a full footprint workflow is not publicly established. Treat any single-signal verdict as unsafe, and require convergence before writing a hard label.

The last failure mode is procedural. A single-signal verdict misfires because every tell has a benign explanation. Require two independent signals to converge before you write borrowed or fabricated, and record which two they were.

## Writing the verdict and keeping it current

Close the case with a one-page record that states the verdict, the evidence per signal, and the convergence explicitly. This is what makes the decision defensible if anyone asks how you reached it.

The four values map to four actions. Real means proceed to schedule. Thin means the footprint is genuine but too sparse to corroborate, so request one more independent data point before deciding. Borrowed means the record is real but may not belong to the applicant, so escalate to a live, unobscured video call with image capture before any hire. Fabricated means at least two signals converged against authenticity, so decline to book and route per policy. Sources disagree on whether a formal background check belongs at this stage or at offer stage; decide that as policy before you start, and remember the FCRA and adverse-action clock the moment a vendor enters.

#### Before you call the case closed

- [ ] A written note records this as identity-corroboration-only, no protected-class data used.
- [ ] Timestamped screenshots of every public page are stored.
- [ ] The profile photo is classified as stock/stolen, likely-generated, or clean by match count.
- [ ] Email, phone, and name are confirmed to converge, or the mismatch is documented.
- [ ] The GitHub history is labeled authored, cloned, or inflated with the specific tell named.
- [ ] At least one prior role is confirmed via a number from the employer's own website.
- [ ] At least two independent signals converge before any hard label of borrowed or fabricated.
- [ ] The one-page verdict is written and dated before any interview time is booked.

Keep the method current by treating its weakest parts as time-sensitive. The photo-forensic tells decay with each generator release, so do not hard-code a visual checklist; re-check which artifacts current tools flag before you rely on them. The compliance clocks in the table above change as states pass new laws - more than 27 already restrict employer access to candidate social media, and New York's took effect March 12, 2024 - so confirm your jurisdiction's current rules rather than trusting a static count. And re-read the federal advisory mechanism periodically: the tradecraft it documents, from laptop farms that make work appear to originate near the device while the worker is elsewhere, to code copied into personal profiles, is what the whole desk read is built to catch.

## Frequently asked questions

### Is it legal to search a candidate's social media myself before an interview?

It carries risk. EEOC rules apply regardless of who conducts the search, and seeing protected-class information creates liability even when you never intend to use it. Doing it yourself also removes the protected-class filter a vendor applies and leaves no documentation trail, which is the employer's only defense in a dispute. Document that your decision rests solely on identity corroboration, applied to everyone equally, and know that more than 27 states restrict how employers interact with candidate social media accounts.

### Does a near-empty GitHub contribution graph mean the candidate is fake?

No, and treating it that way is the most common false positive. Real senior engineers often do their work in private or enterprise repositories that never appear on public graphs. Employers understand that contribution patterns vary. Confirm authorship through merged pull requests and real diffs rather than dot density, and never let a sparse graph alone drive a verdict.

### A reverse-image search on the photo returned zero results. Is that good?

Not necessarily. The reverse-image test inverts for AI-generated faces: a stolen photo produces many matches, but a generated face produces few or none because the image corresponds to no real person online. A clean reverse search is a documented red flag when paired with symmetry, strange ears, or nonsense backgrounds. Escalate to a live, unobscured video call and image capture.

### If the phone, email, and name all match, is the candidate proven real?

Only the record is proven real, not that the applicant owns it. KnowBe4 was duped into hiring a fake worker who used a valid but stolen US identity that passed contact checks. Convergent contact signals rule out a stitched-together record; they do not confirm personhood. That gap is exactly why the FBI advisory adds live video and image capture for comparison in later meetings.

### When should a formal background check happen in this process?

Sources disagree, so decide it as policy before you start. Some practitioners hold formal background checks until just before onboarding to protect candidates; others push identity and background verification before interviews. Whichever you choose, the moment a third-party vendor is involved the FCRA triggers written disclosure, candidate consent, and a formal adverse-action process, with statutory damages of $100 to $1,000 per violation for skipping steps.

### How many red flags does it take to call a candidate fabricated?

More than one, always. The governing principle from the federal alert is that no single indicator establishes fraud. Any one tell misfires: sparse graphs, clean reverse searches, and backdated commits all have benign explanations. Write down borrowed or fabricated only when at least two independent signals converge, and record which signals they were.

---

*From the Refolk guide library. I revise these guides rather than replacing them, so the current version is always at https://www.refolk.ai/guides/verify-flagged-candidate-real-person*