Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Is It Safe to Let an AI Agent Run KYC Checks?
No, not while the KYC case renders the identity record: Persona returns an inquiry that can "contain results for you to use", Stripe exposes the verified name and address on a verified session, and Jumio's notice lists passport numbers and document images. Ask for values replaced before the model reads the screen, a named approver and a record.
A KYC check is two things at once: a verification pipeline that inspects a document, and the case record that a person or an agent reads around it. The pipeline can decide that a passport is genuine without any model seeing it. The case is where the exposure sits. An onboarding team that lets an agent open inquiries or work review cases is asking a model to read the fields the check exists to protect: the name, the date of birth, the address, the document number, the images and the selfie. The agent needs a status and a reason code to move the application; it receives whatever the case renders. GDPR requires that personal data be "adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed" (Regulation 2016/679, 2016), and a screen built to show a reviewer everything is not limited by that standard. The answer turns on what the model receives from the rendered case, who approves the decision it prepares and what record remains. Getting it wrong puts a passport number, a home address and a facial image into a model's context, where a later summary or an injected instruction can carry them somewhere the KYC file never reached.
Key findings
- For an agent to run KYC checks safely, the values on the case screen would have to be replaced with consistent tokens such as APPLICANT_014 before any model reads it, with real values resolving only at the destination an approver names (What Is Render-Layer Tokenization?).
- It would also require a named person approving each approval, decline and escalation, and a record of every screen, action and approval (What Is Supervised Delegation?).
- The vendor controls govern who retrieves a result: Stripe's restricted keys cover sensitive results "for verifications processed in the last 48 hours", and FileLinks "must expire within 30 seconds", which does not limit what a model read from the case screen (Stripe, Access, 2026).
- Persona's documentation states that an inquiry is "a single instance of a Persona identity verification flow" and that approved, declined and needs_review inquiries "contain results for you to use", so the result is tied to a person, not a verdict in the abstract (Persona, Inquiries, 2026).
- Stripe's Verification Sessions page states that you can "expand the verified_outputs field to see the verified data", while redaction leaves "placeholder values" and "Redaction can take up to 4 days" (Stripe, Verification Sessions, 2026).
- Jumio's privacy notice lists "driver's license numbers, passport numbers, etc." and "Images of identification documents" among the data it processes, and says it will "permanently destroy" biometric data from those images "within three years", a retention ceiling, not a read limit (Jumio, Online Services, 2026).
What does an agent read when it opens a KYC case?
The record is a KYC verdict without the passport. An agent has triggered a check, the vendor has returned a decision, and the agent opens the case to close it. In Persona's flow that case is an inquiry, "a single instance of a Persona identity verification flow", and the details "are wrapped in an inquiry object" readable from the Persona Dashboard, the Retrieve an Inquiry API or webhooks, with approved, declined and needs_review states that "contain results for you to use" (Persona, Inquiries, 2026).
Persona's KYC Solution documentation collects "both the front and back of ID" with a barcode check, runs "a selfie liveness check", and can open a case whose template "Includes tags or comments indicating why the Case was created" (Persona, KYC Solution, 2026). An agent that opens that case to write a note reads the name, the document number, the date of birth, the address returned by verification, the images and the tags, and nothing says which of those fields the decision needs.
A computer-use agent takes in the rendered page as a person would, and the pages that describe what agents read on screens with personal data describe the same pattern (Which Enterprise AI Agents Can Work on Screens With PII Today, and What Does Each One Read?). The verdict is one field of thirty; the other twenty-nine are identity data a later summary or injected instruction can carry out.
Can an agent run the check without seeing the document?
The document does not have to reach the model for the check to run. An integration can create a verification session, send the applicant to the vendor's own flow, and receive a status and a result, so the document is captured on the vendor's page, not in the agent's. Stripe's session types make the split explicit: the session is either "document - Verify the authenticity and ownership of government-issued identity documents", with an optional selfie, or "id_number", which verifies "a user's name, date of birth and national ID number" (Stripe, Verification Sessions, 2026).
What it cannot do is read the verdict without reading the person. The result carries the name, the date of birth, the address or the document number, depending on the vendor and the key. Stripe puts the more sensitive fields behind restricted keys, and the key still returns values to whatever retrieves them, including an agent (Stripe, Access, 2026). Browser Use draws the distinction for form filling: the model works with a placeholder while the real value is injected after the model's call (Can a Browser Agent Fill In a Form Without Seeing the Values?), which covers a value the agent types, not a value the vendor returns.
A workflow can look safe in the narrow sense and fail in the sense that matters: the check ran, the agent never opened the passport image, and the model still holds the applicant's date of birth and address in a result it read to decide what to write next.
What do the vendors themselves say?
Each KYC vendor documents its own split between the check and the record. Persona's inquiry carries the status and the results, readable from the dashboard, the API or webhooks (Persona, Inquiries, 2026). Stripe's session is either "document - Verify the authenticity and ownership of government-issued identity documents", with an optional selfie, or "id_number", which verifies "a user's name, date of birth and national ID number" (Stripe, Verification Sessions, 2026). Jumio documents a Delete Transaction API that "permanently removes all the personally identifiable information (PII) associated with the transaction" (Jumio, Delete Transactions, 2026).
| Dimension | Persona, Stripe Identity and Jumio, per their documentation | What a buyer should verify |
|---|---|---|
| What the check collects | Persona: front and back of a government ID with a barcode check, plus a selfie liveness check | Whether the agent's task needs the images or only the result |
| What the caller receives | An inquiry with approved, declined and needs_review states; a Stripe session with verified outputs | Which fields the integration retrieves, and whether it can retrieve fewer |
| Sensitive results | Stripe: more sensitive fields require restricted API keys, with a 48-hour window unless the key is IP-restricted | Whether the key in the agent's environment is restricted, and to which window |
| Document and selfie files | Stripe: FileLinks for document and selfie files "must expire within 30 seconds" | Whether the agent downloads an image or passes a link |
| Retention and deletion | Jumio: biometric data destroyed within three years, with a shorter period where law requires; a deletion API for transaction data | What the vendor keeps, and what the organization's own copy keeps |
| Record of what the agent read | Not described in the pages reviewed | What the model received, screen by screen, and who approved the decision |
Read together, the vendor pages settle the check and leave the case open. A buyer can confirm how a result is produced, who can retrieve it and how long a file link lives. None of those answers says what the model receives when the case is on screen.
Who approves the decision, and what goes wrong when the agent can?
An agent that can move a case to approved, declined or needs_review is making a compliance decision, and a role is not a person. Zendesk's help page says that on eligible plans "you can define your own agent roles and assign agents to those roles", and the role scopes what the holder can see and do without naming who approved a decision (Zendesk, 2026). Gusto's help center makes the limit concrete on a payroll record: "Your employer must update these details for you" for fields including "Your legal name" and "Social Security Number (SSN)" (Gusto, 2026), so even the employee cannot change the data an agent might be asked to edit.
The second problem is injection through the case material. A KYC case holds documents and notes written by the applicant, and a study of task-executing agents found that injections asking an agent to leak personal data it saw during the task reached "average attack success rates (ASR) around 20 percent" (Alizadeh et al., 2025). An agent holding the passport number, the address and the selfie is a productive target at that rate, and a hijacked agent holding placeholders has far less to send (What Can a Hijacked Agent Leak If It Only Has Placeholders?). The decision still needs a named approver, because an agent that can decline an application without one has been given the vendor's authority and the organization's liability at once.
What does a governed environment change?
A governed environment changes what the model receives from the case, and the decision, the record and the approvals follow from that change. The values a policy names on the rendered case, the applicant's name, date of birth, address and document number, are replaced with consistent tokens before any model reads the screen, so the same applicant appears as APPLICANT_014 on the dashboard, in the inquiry object and in the note the agent writes. The real values resolve only at the approved destination, at the moment of an approved action: the decision posts to the vendor with the real identifiers when a named person approves it.
The vendor's controls keep their place: the restricted key still limits which results can be retrieved, the file link still expires, and a case in needs_review still needs a person. What the governed environment adds is the layer those controls do not cover, what the model reads while the case is open. Every screen the model received as tokens, every action and every approval is written to a record the organization exports to its own logging.
Applied to the verdict without the passport, the status and the reason code reach the model, the identity fields reach it as tokens, and the approval moves from whoever holds the account to a named person (What Is Render-Layer Tokenization?).
What the record shows
The control that decides this sits before the model, not inside the verification pipeline: what the model receives from the rendered case, who approves the decision the agent prepares, and what record the organization keeps. On the records reviewed here, the vendors document a clean split between the check and the caller, and none of the pages reviewed describes values being replaced on the case screen before a model reads it, so an agent that opens the case reads the identity fields as the vendor renders them (What Is the PII Wall?). An onboarding team should check its own workflow with one application and one test identity: list every field the agent's model received, list the fields the decision actually needed, and compare the two lists with the approval log. The difference is the exposure the approvals never covered.
Methodology and limitations
This page rests on the KYC vendors' own documentation (Persona, Stripe Identity and Jumio pages), two workplace records where identity fields are changed (Gusto's payroll help and Zendesk's role help), the GDPR text of Article 5(1)(c) and one preprint on prompt injection against task-executing agents. Public documentation read in full gives a sound view of where each product applies its control. Vendor pages were read as of October 22, 2026, and each Sources line carries the date for its page.
The products on this page are described from documentation and none was tested for this page; "not described" means the pages reviewed, vendor features change, and the page carries its date. RedactSure is deploying now with enterprise and government customers. The KYC verdict describes a record type, not an organization, and no applicant data is real. Determinations belong to counsel, assessors and the organization's own security and compliance officers, and nothing here replaces a pilot of one case on the organization's own screens.
Frequently asked questions
Is it safe to let an AI agent run KYC checks?
No, not while the case renders the identity record. The check can run without the model seeing the passport: an inquiry returns a status and results. The exposure is the case the agent opens around the result, where the name, date of birth, address and document images sit together. It becomes safe when those values are replaced before the model reads the screen, a named person approves and a record exists.
What does the model receive from a KYC case screen?
Whatever the case renders. Persona's inquiry carries the status and the results, and Persona's KYC solution collects both sides of a government ID and a selfie. Stripe's session returns verified outputs such as name and address, and Jumio's notice lists passport numbers and document images. A reviewer needs it in one place; an agent reading the same page receives it.
Can an agent run a check without the passport image?
Yes, when the integration creates the session and reads a result rather than the document. The vendor captures the images, and the agent receives a status and a result object. That removes the passport from the model's context but not the identity data, because the result carries the verified name, date of birth or address. A restricted key narrows which results a caller can retrieve; it does not change what the case screen shows.
Who should approve a KYC decision an agent prepares?
A named person at the organization, not the account that holds the API key and not a role. The KYC vendors return needs_review as a status for a human queue, and a queue is a place to look, not an approval that names anyone. Zendesk's role page shows the distinction: a role can be assigned access, and it does not record who approved a decision. The approval should name the person and the decision.
Does replacing values on the screen break the check?
No. The check runs on the vendor's side against the real document, and the model works on the token. The research on masking reports that consistent pseudonyms with restoration after the model's work reduce semantic utility errors by a factor of five compared with baseline techniques (Does Masking Data on Screen Break Browser Agents?), which places the utility cost on inconsistent redaction. A case that renders APPLICANT_014 can still be reviewed and decided.
What record should the organization keep of an agent's KYC work?
A per-run record of what the model received, which fields it used, what action it took and who approved it, exported to the organization's own logging rather than left in the vendor's dashboard. The KYC vendors' records show that a check ran and what it returned. The organization's question is what its agent read and did, and that record has to sit with the organization that owns the customer.
How RedactSure Keeps the Passport Out of the KYC Verdict
An agent closing a KYC case reads the identity record to write one status line. Stripe's page says redaction "can take up to 4 days", a limit on the stored record, not on what the model read (Stripe, Verification Sessions, 2026).
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before, the case rendered the name, date of birth and passport image to the model, which a note could repeat. Inside the governed environment the case renders APPLICANT_014, the date of birth as DOB_014 and the passport number as GOVID_014, the model writes the decision on the tokens, real values resolve only when a named reviewer approves, and the AI Control Record keeps every screen and approval.
RedactSure is deploying now with enterprise and government customers.
Everyone else controls where data can go. RedactSure controls what the AI can see.
See it on your own workflow
A KYC verdict arrives with an identity record attached, and the agent reads the record to write the verdict. Bring one case your team closes and see, with test values, what the model reads and who approves the change. Book a demo