HR, recruiting & people operations
Guardrails for AI that reads CVs and employee records
HR teams and recruiting software putting CVs and employee records through a model.
The CV that went out in full
A screening assistant sends a candidate’s CV – name, home address, phone number, date of birth – to a model provider to be summarised. The summary comes back neat and readable, and states the candidate holds a certification they never listed. A recruiter forwards it to the hiring manager, who reads it as fact.
in/guard/out replaces personal details with placeholders before the CV leaves and restores them only inside your own app, so the provider never sees them. Claims the CV does not support are flagged before a recruiter reads them as fact.
A CV is a dense block of personal data – name, address, phone, dates, sometimes health or immigration detail – and screening AI sends the whole thing to a model provider by default. Employee records are worse. The exposure is the input, before any answer is generated.
in/guard/out screens those values into reversible placeholders before the request leaves your infrastructure, and puts the real ones back only in the response your own application receives. The provider sees a readable document with the identifying parts removed; your logs store the screened form by default.
The second failure is quieter. A summary that adds a qualification, shifts an employment date, or turns a claim into a certainty is indistinguishable from a good summary to the person reading it. Grounding matches figures and dates back to the document that was actually supplied, and a fact-check pass flags statements the CV does not support – so the recruiter sees the flag, not just the prose.
Where it breaks
- ✕Candidate and employee personal data sent to the provider
- ✕Invented qualifications, dates and job titles in summaries
- ✕Personal data leaving through tool calls and outbound email
- ✕No record of what the AI was asked, or what it answered
What answers it
- →Personal data screened out, restored in your app
- →Every claim matched back to the source document
- →Egress blocking on tool arguments and email sends
- →Per-request log of which checks ran and what they found
The qualification nobody claimed
A screening summary states the candidate is “AWS certified since 2021.” The CV mentions AWS experience and no certification. Grounding finds no source for the date; the fact-check pass flags the claim as unsupported by the material. In fix mode the finding is attached to the exact sentence; in prevent mode the summary does not ship. The candidate’s name and address never reached the provider either way.
Frequently asked questions
Does candidate data reach the model provider?
No. Names, addresses, phone numbers, and other identifiers are replaced with placeholders before the request leaves, and restored only in the response your application receives. Taint tracking also blocks screened values from leaving through tool arguments or an email send.
How would we catch an invented qualification?
Claims in the summary are matched against the document supplied. Figures and dates are checked deterministically; broader statements go to a fact-check pass that flags what the source cannot support – attached to the exact sentence, so a reviewer can see it.
Does this audit our hiring model for bias?
No – and nothing here should be read as doing so. Bias auditing is a separate discipline with its own methods and, in some US jurisdictions, its own legal requirements. in/guard/out covers data exposure, unsupported claims, and an audit trail of what ran; it does not assess fairness of outcomes.
What do we have in writing afterwards?
Every request records which checks ran, what they found, and what was done about it. Transcripts are stored in their screened form by default, with raw storage available as a deliberate, audited opt-in.
Other clients
See it on your own traffic.
We’re running a limited demo – sign up and we’ll get you in as soon as we can.