Do we ever need access to the real repo?

Sometimes, but treat it as an exception. If the job truly requires navigating internal integration points, use Limited real repo access with explicit Security approval, a shorter access window, and stricter evidence capture. For most roles, a sanitized mirror produces the same signal with far less risk.

Will this slow down hiring?

If you standardize modes and automate the gate, it usually speeds things up by removing back-and-forth. The slowdown comes from improvisation: waiting for approvals that were never defined, or re-running tests because evidence was not captured cleanly.

What if a candidate refuses identity verification before the work sample?

Offer an alternative assessment path that does not require repo access (sandbox or standard coding assessment). Make the policy consistent across candidates to avoid bias and to keep exception handling from becoming a backdoor that fraud can exploit.

How do we handle candidate appeals on repo-based tests?

Use an Evidence Pack: the exact prompt, repo state, access window, PR thread, and rubric output. Appeals should focus on the submitted artifacts, not recollections. If needed, use code playback to validate approach and timing signals.

Industry-insights · Dec 20, 2025 · 10 minute read

Repo Access: Temporary, Audited Work-Samples Without Leaks

A hiring-safe way to let candidates touch real code without handing them your crown jewels.

James Kim

Staff Engineer, Assessments

James builds automated grading pipelines and cheat-detection telemetry.

Repo access is a privileged action in a hiring funnel. Treat it like one: time-bound, least-privilege, logged, and dispute-ready.

Back to all posts

The day a repo invite turns into an incident

At 9:12am, a recruiter forwards a candidate an org invite so they can "just open a PR" against a real service. At 11:40am, a staff engineer notices the candidate is browsing unrelated directories. At 3:05pm, Security asks for a list of repositories the candidate accessed, what they downloaded, and whether the invite was time-bound. This pattern repeats because most teams treat work-sample access as a one-off favor, not as a controlled step in the hiring pipeline. The blast radius is not theoretical: your codebase, internal docs, and secrets hygiene all get stress-tested by a person you have not hired yet.

What you will be able to operate by end of day

You will have a documented "Repo Access for Work Samples" flow that answers four questions in under five minutes during an audit or incident review: who approved access, what the candidate could see, what they actually did, and when access was revoked. You will also have a standard decision rule for when to use a sandbox, a sanitized mirror, or limited real repo access, so teams stop improvising under schedule pressure.

Ownership, automation, and sources of truth

If you do not assign ownership, you will get funnel leakage and reviewer fatigue: candidates wait, managers improvise, and Security escalations spike. Recommended ownership model for COOs to enforce:

Recruiting Ops owns the workflow and SLA: when access is requested, when it is granted, when it expires, and what evidence is attached to the req.
Security owns the policy guardrails: what scopes are allowed, approved repo patterns, retention rules, and break-glass escalation.
Hiring Manager owns the test design and scoring rubric: what tasks are allowed, what "good" looks like, and what signals are disqualifying.

Automated: identity verification gate, repo invite issuance, time-bound expiration, and event logging to an Evidence Pack.
Manual review: exceptions (expanded scope, longer windows), and any fraud signals that require step-up verification.

ATS is the source of truth for candidate identity, req, stage, and decision.
Verification service is the source of truth for identity checks and risk tier.
Repo host (GitHub, GitLab) is the source of truth for access grants, audit logs, and code artifacts (commits, PRs).

Why repo access fails in hiring, even with good intentions

Repo-based work samples are attractive because they test the exact skills you need: reading existing code, navigating architecture, and making a change with constraints. But the hiring context is adversarial by default. You have motivated candidates, time pressure, and uneven operator discipline across teams. Directional risk reality check: 31% of hiring managers reported interviewing someone who later turned out to be using a false identity. That implies identity risk is common enough that "we will notice" is not a control. It does not prove your company will see the same rate, and it is not specific to repo tests, but it is a strong signal that pre-hire access should be treated as privileged access. Another data point: 1 in 6 applicants to remote roles showed signs of fraud in one real-world pipeline. That suggests remote funnels are higher-noise and need earlier integrity controls. It does not prove intent or guilt per candidate, and the definition of "signs" can vary by pipeline, but it supports risk-tiered gating before any high-trust step like codebase access.

Pick an access model that matches risk and role

You need three standardized modes. If you only have "full repo" and "no repo", teams will choose full repo under pressure. Use this decision rule:

Candidate works in an isolated environment with a seeded snapshot and no network egress to your internal systems.
Best for early stages, high-volume roles, or when verification is incomplete.
Outputs: patch file or PR against a sandbox mirror, plus code playback evidence.

A curated subset of the codebase with secrets removed, history minimized, and only the directories needed for the task.
Read-only for most of the repo, write access only via PR to a controlled branch.
This gives realism without exposing the full monorepo.

Only for senior roles where debugging integration points matters and the candidate is verified.
Access is time-bound, directory-scoped where possible, and permissioned to the minimum role (no admin, no secrets, no CI settings).
Requires explicit approval and stronger evidence capture.

Step-by-step runbook for temporary, audited repo access

This is the minimum viable runbook that keeps speed while making access defensible. Follow these steps in order; do not reorder to "save time".

Write a one-page test spec: task, expected artifacts (PR, commit), time window, and what is out of bounds.
Create a scoring rubric with reproducible criteria to reduce bias claims and reviewer debates.
Decide what evidence you will keep: PR thread, timestamps, and assessment snapshots.

Before any invite is issued, run identity verification and assign a risk tier.
Low risk: allow Mode B by default. Elevated risk: Mode A only, or require step-up before Mode B/C.
High risk or failed verification: do not grant repo access. Use an alternative assessment path.

Grant access for a fixed window aligned to the test (for example, 4 hours). Treat longer windows as exceptions.
Use a dedicated hiring org or repo namespace when possible.
Restrict to PR-only workflow. Avoid direct pushes to main branches.

Attach access grant record (who approved, when issued, when expires) to the candidate record.
Store repo audit events relevant to the test window (invite accepted, clone events if available, PR created, commits).
Keep a dispute-ready snapshot: what prompt was given, what code was submitted, and how it was scored.

Auto-expire access at the end of the window. Manual revocation is a backstop, not the plan.
Run a post-test checklist: ensure access removed, branch cleaned, and evidence attached.
If anything looks off (unusual access patterns, mismatched identity signals), route to Security review with a single ticket containing the Evidence Pack link.

Repo access policy you can actually enforce

Use a policy file like this to standardize access across teams. The goal is operational clarity: what gets approved automatically, what requires human review, and what must be logged. Adapt the repo host integration to your environment.

Anti-patterns that make fraud worse

Sharing a reusable org invite link in email or chat with no expiry. Letting hiring managers improvise permissions because "it is just one candidate". Running repo tests without an Evidence Pack, then trying to reconstruct what happened after a dispute.

Reviewer ergonomics and dispute resolution

Repo access increases signal quality only if reviewers can adjudicate quickly and defensibly. Otherwise you create reviewer fatigue and inconsistent decisions. Operationally, optimize for two outcomes: fast scoring and clean appeals.

Use a rubric with 4-6 criteria tied to the job: correctness, test coverage, readability, and tradeoff reasoning.
Require a short PR description that explains approach and constraints.
Prefer async review to reduce scheduling thrash and let candidates perform at their best time.

Keep code playback or equivalent trace so you can validate authorship signals without guessing.
Store the exact prompt and repo state hash for the test window.
Use an escalation path: Recruiting Ops triage, Security review only when signals cross a threshold.

Where IntegrityLens fits

IntegrityLens AI is the hiring pipeline that combines a full ATS with advanced biometric identity verification, fraud detection, AI screening interviews, and technical assessments. For repo-based work samples, IntegrityLens helps teams gate access with Risk-Tiered Verification, keep the candidate experience fast, and produce defensible Evidence Packs for audits and disputes. TA leaders and recruiting ops teams use it to standardize workflows and reduce funnel chaos. CISOs use it to ensure access is time-bound, logged, and privacy-first, including Zero-Retention Biometrics and encrypted handling (256-bit AES baseline) on SOC 2 Type II and ISO 27001-certified infrastructure. Practical tie-in to this playbook:

Trigger verification before any repo invite is issued, typically completing in 2-3 minutes (document + voice + face).
Run 24/7 AI screening interviews to reduce scheduling delays before higher-trust steps.
Attach verification results, assessment artifacts, and decision rationale into a single candidate record for auditability.
Use idempotent webhooks to sync stages and evidence between IntegrityLens and your existing systems when needed.
Run coding assessments across 40+ programming languages when Mode A or B is more appropriate than real repo access.

Operational outcomes you can expect

You are not trying to create perfect security. You are trying to prevent preventable incidents and keep hiring moving under audit scrutiny. Realistic before and after state:

Sources

Checkr, "Hiring Hoax" manager survey (2025): https://checkr.com/resources/articles/hiring-hoax-manager-survey-2025 Pindrop, hiring process as a cybersecurity vulnerability: https://www.pindrop.com/article/why-your-hiring-process-now-cybersecurity-vulnerability/

Related Resources

Key takeaways

Treat repo access like production access: time-bound, least-privilege, logged, and revocable.
Standardize ownership and sources of truth so access can be proven after the fact (audit, dispute, or incident).
Use Risk-Tiered Verification to decide who gets real repo access, who gets a sanitized mirror, and who gets a sandbox only.
Design the work sample so you can adjudicate with evidence: commit history, PR comments, and code playback artifacts.

Repo-based work-sample access policy (ops-enforceable)yaml

Drop this into your internal hiring controls repo. It defines access modes, approvals, expiry, logging requirements, and exception handling so teams stop freelancing under time pressure.

version: "1.2"
policyName: "work-sample-repo-access"
owner:
  primary: "recruiting-ops"
  securityApproverGroup: "sec-eng-oncall"
  hiringManagerRole: "hm"

sourcesOfTruth:
  ats: "IntegrityLens-ATS"
  verification: "IntegrityLens-Verify"
  repoAudit: "GitHub-AuditLog"

defaults:
  evidencePackRequired: true
  retentionDays: 180
  encryptAtRest: "AES-256"
  webhookMode: "idempotent"

riskTierRules:
  low:
    allowedModes: ["SANITIZED_MIRROR", "SANDBOX"]
    stepUpRequired: false
  elevated:
    allowedModes: ["SANDBOX"]
    stepUpRequired: true
    stepUpTypes: ["liveness", "voice-match"]
  high:
    allowedModes: []
    stepUpRequired: true
    blockReason: "do-not-grant-prehire-repo-access"

accessModes:
  SANDBOX:
    accessWindowMinutes: 240
    repoScope: "isolated"
    permissions:
      read: ["sandbox-repo"]
      write: ["sandbox-repo:pr-branch"]
    controls:
      networkEgress: "blocked"
      secretsScan: "on-submit"
  SANITIZED_MIRROR:
    accessWindowMinutes: 240
    repoScope: "mirror"
    permissions:
      read: ["mirror-repo"]
      write: ["mirror-repo:pr-branch"]
    controls:
      allowForks: false
      allowActionsWrite: false
      requiredReviewers: ["hm", "recruiting-ops"]
  LIMITED_REAL_REPO:
    accessWindowMinutes: 120
    requiresSecurityApproval: true
    repoScope: "real"
    permissions:
      read: ["target-repo:/service", "target-repo:/lib"]
      write: ["target-repo:pr-branch"]
    controls:
      blockAdmin: true
      blockSettingsWrite: true
      blockSecretsPaths: ["/.github/", "/infra/", "/secrets/"]

workflow:
  - step: "verify-identity"
    system: "IntegrityLens-Verify"
    requiredBefore: "issue-repo-invite"
  - step: "issue-repo-invite"
    system: "GitHub"
    inviteType: "user-invite"
    mustExpire: true
  - step: "capture-evidence-pack"
    system: "IntegrityLens-ATS"
    evidence:
      - "verification-result"
      - "access-grant-record"
      - "repo-audit-events:test-window"
      - "pr-url-and-commit-sha"
      - "scoring-rubric-output"
  - step: "auto-revoke-access"
    system: "GitHub"
    on: "invite-expiry"
  - step: "exception-review"
    when:
      - "mode == LIMITED_REAL_REPO"
      - "accessWindowMinutes > 240"
      - "riskTier in [elevated, high]"
    approvers: ["sec-eng-oncall", "recruiting-ops"]

alerts:
  - name: "out-of-scope-browse"
    condition: "repo_audit.path NOT IN allowed_paths"
    routeTo: "sec-eng-oncall"
  - name: "invite-not-revoked"
    condition: "now > expiry AND access_still_active"
    routeTo: "recruiting-ops"

Outcome proof: What changes

Before

Repo-based work samples were ad hoc. Hiring managers issued invites manually, access windows were inconsistent, and when candidates disputed results or teams asked "who had access to what," Ops had to reconstruct events across email, Slack, and GitHub.

After

Repo access became a standardized stage in the hiring pipeline: identity verification gates access, modes are selected by risk tier, invites are time-bound by default, and every test produces an Evidence Pack attached to the req and candidate record.

Governance Notes: Legal and Security signed off because access is least-privilege and time-bound, audit logs are retained for a defined period, and evidence is collected for appeals without storing unnecessary biometric data (Zero-Retention Biometrics). Access to Evidence Packs is role-based, changes are logged, and exceptions require documented approvals, reducing audit findings and making candidate disputes resolvable with objective artifacts.

Implementation checklist

Define the work-sample scope: which repo, which branch, which directories are in-scope.
Pick an access mode per role level: sandbox only vs sanitized mirror vs limited real repo.
Require identity verification before issuing any repo credential or invite.
Issue time-bound access and enforce least-privilege permissions.
Log every access event and link it to the candidate and req in the ATS.
Capture an Evidence Pack: access grant, commits, PR thread, and assessment result snapshot.

Questions we hear from teams

Do we ever need access to the real repo?: Sometimes, but treat it as an exception. If the job truly requires navigating internal integration points, use Limited real repo access with explicit Security approval, a shorter access window, and stricter evidence capture. For most roles, a sanitized mirror produces the same signal with far less risk.
Will this slow down hiring?: If you standardize modes and automate the gate, it usually speeds things up by removing back-and-forth. The slowdown comes from improvisation: waiting for approvals that were never defined, or re-running tests because evidence was not captured cleanly.
What if a candidate refuses identity verification before the work sample?: Offer an alternative assessment path that does not require repo access (sandbox or standard coding assessment). Make the policy consistent across candidates to avoid bias and to keep exception handling from becoming a backdoor that fraud can exploit.
How do we handle candidate appeals on repo-based tests?: Use an Evidence Pack: the exact prompt, repo state, access window, PR thread, and rubric output. Appeals should focus on the submitted artifacts, not recollections. If needed, use code playback to validate approach and timing signals.

Ready to secure your hiring pipeline?

Let IntegrityLens help you verify identity, stop proxy interviews, and standardize screening from first touch to final offer.

Try it free Book a demo

Watch IntegrityLens in action

See how IntegrityLens verifies identity, detects proxy interviewing, and standardizes screening with AI interviews and coding assessments.