Your KYC was built to stop a human attacker. The attacker is now a machine. This is AI-native verification.

Picture an onboarding that goes perfectly. The selfie is sharp and the face turns when asked. The passport photo page is clean and every field reads. The integration behind it shipped in an afternoon and has never thrown an error. The account is approved in under a minute.

Now suppose that no person did any of it. The face was generated. The document image was generated to match. The video never passed through a camera lens at all: it was fed to the app by software pretending to be one. And the integration that waved it through was written by a coding agent that guessed at two field names and treated a timeout as a pass.

That is a pattern, not a named incident. But every part of it is documented, and most verification stacks were designed before any of it was possible. AI-native verification is what you build when that scene is the starting assumption.

Three things changed at once

The attacker. In November 2024 the US Treasury's financial crime unit published an alert on deepfake media (opens in a new tab) which says: "Beginning in 2023 and continuing in 2024, FinCEN has observed an increase in suspicious activity reporting by financial institutions describing the suspected use of deepfake media in fraud schemes". It adds that accounts have been opened with identities suspected to be AI-generated. Europol's Innovation Lab had already listed "fooling 'know your customer' mechanisms" among the criminal uses of deepfakes in its 2022 report (opens in a new tab).

The method matters more than the media. ENISA, the EU's cybersecurity agency, separates a presentation attack (something held up to the camera) from an injection attack, where a digital artefact is "injected directly to the biometrics recognition subsystem" and so, in its words, "aims to bypass the PAD controls", the checks that look for a mask or a screen. In its March 2024 good practices report (opens in a new tab), deepfake presentation and injection attacks were the two biometric attack types that the stakeholders it surveyed found hardest to mitigate. One of FinCEN's red flags is the same thing seen from a bank: "A customer uses a third-party webcam plugin during a live verification check."

The builder. In the 2025 Stack Overflow Developer Survey (opens in a new tab), 84% of respondents said they were using or planning to use AI tools in their development process, and more of them distrusted the accuracy of those tools (46%) than trusted it (33%). That is a figure about tool use, not about how much code a machine writes, and we found no primary source for the second number that we would repeat. The first reader of your provider's documentation is increasingly an agent, and the agent's author does not fully trust it.

Documentation is being rebuilt for that reader. The llms.txt proposal (opens in a new tab), first published by Jeremy Howard in September 2024, asks sites to add "a /llms.txt markdown file to websites to provide LLM-friendly content". The OpenAPI Specification (opens in a new tab) has long described an API so that "both humans and computers" can understand it without reading source code. The Model Context Protocol (opens in a new tab) lets an AI client call a server's tools, and its own text is blunt about the risk: "Tools represent arbitrary code execution and must be treated with appropriate caution."

The decision. A verification result used to end as a PDF in front of a compliance officer. Now it lands in a webhook handler that grants or withholds access in milliseconds. Software cannot read a green tick. It needs a status, a reason and a statement of how strong the evidence was.

What AI-native should mean: five tests

These are properties you can check.

1. Some evidence does not depend on the camera feed. If every check reads pixels that the applicant's device supplied, a good enough injection defeats all of them together. ENISA names two document defences as the most prominent: registry lookups and reading the chip, which it says "could eliminate several of the synthetic attacks" (it also notes that private companies are not consistently permitted to read chips across the EU).

2. What the device claims is checked again on the server. NIST's SP 800-63A-4 (opens in a new tab) (final, July 2025) says providers "SHALL implement technical controls to increase confidence that digital media is being produced by a genuine sensor", and gives detecting a virtual camera, an emulator or a jailbroken device as examples. A liveness verdict computed only on the phone is a claim, not a finding.

3. The result says how strong it is, and why. A passport verified from its chip and a driving licence verified from a photograph should not come back as the same word. We covered this in KYC assurance levels.

4. A coding agent can integrate without guessing. That means an index it can fetch, exact contracts for requests and responses, and a free sandbox with a test case for every outcome, so the agent's work is proved by tests instead of trusted.

5. Decisions name their rule and leave room for a person. The same NIST section says automated analysis and decisioning "SHOULD be augmented by manual reviews to address detection errors". A system that can only say yes or no has nowhere to put doubt.

What it does not mean

• A chatbot on the dashboard. It changes nothing about what a forged video can get past.

• A model deciding alone. More AI in the decision is not the goal. Better evidence, and a decision you can explain, is.

• A black-box score. "Risk: 0.83" with no reasons cannot be defended to a customer, an auditor or a regulator.

• A claim to catch every deepfake. Nobody can show that. NIST runs independent evaluations (opens in a new tab) of presentation attack detection software precisely because performance varies and has to be measured. Europol's point stands: "the robustness of any identification process will depend on the process as a whole, and not only its visual step(s)."

What the law says about the human in the loop

Three texts are worth reading in the original, because they are narrower than they are usually described.

• GDPR, Article 22. A person has "the right not to be subject to a decision based solely on automated processing" that produces legal or similarly significant effects. Where an exception applies (contract or explicit consent), the controller must still offer "at least the right to obtain human intervention", to express a view and to contest the decision. Article 22(1) and (3) (opens in a new tab).

• Nigeria Data Protection Act 2023, section 37. Nearly the same structure: a right not to be subject to a decision "based solely on automated processing of personal data, including profiling", with safeguards that include the rights to "obtain human intervention", to express a point of view and to "contest the decision". Section 37(1) and (3) (opens in a new tab).

• EU AI Act, Annex III. Remote biometric identification is listed as high-risk, but the same point says it does not include biometric verification "the sole purpose of which is to confirm that a specific natural person is the person he or she claims to be". Annex III, point 1(a) (opens in a new tab). Where a system is remote biometric identification, Article 14(5) (opens in a new tab) requires a result to be confirmed by at least two competent people before it is acted on, and Article 86(1) (opens in a new tab) gives an affected person a right to "clear and meaningful explanations" of decisions based on Annex III high-risk systems.

So a one-to-one selfie check is treated differently from searching a face against many. Which side a feature falls on is a question for your lawyers. The voluntary NIST AI Risk Management Framework (opens in a new tab) (January 2023) puts the practical version in one line: processes for human oversight should be "defined, assessed, and documented". We read the EU, Nigerian and US texts only. Other countries differ.

What to do with this

If you are buying. Ask these in procurement, and ask for the answer in writing.

• Which of your checks would still hold if the attacker controlled the camera feed completely?

• Which liveness results are computed on the device, and which are checked again on your servers?

• Does the result tell me how it passed, in a field my code can branch on?

• When a rule sends someone to review or declines them, can I see which rule, and who changed the outcome afterwards?

• What can you not detect? Distrust a short answer.

If you are building. This afternoon, with Toden, you can hand the integration prompt (opens in a new tab) to your coding agent. It makes the agent read your repository, interview you and wait for your approval before writing code. Then make it prove the work: Sandbox is free and has a test ID for every outcome. Finally, read assuranceLevel and reasonCode on the result.

If you are watching. Watch three things: whether injection attack detection gets a testing standard as settled as the one for presentation attacks (ENISA noted in 2024 that none was yet globally accepted), whether chip reading becomes legally available to private companies in more places, and whether providers start publishing what they miss.

Where Toden is today, and what comes next

Here is what exists now, with the limits attached.

• Evidence beyond the camera. A verification can rest on a government database (in Nigeria, Ghana, Kenya, South Africa and Côte d'Ivoire) or on a passport's chip, authenticated on our servers. A chip counts only when its signer chains to a trusted issuer; otherwise it comes back inconclusive. Chip reading needs our mobile SDKs, because no browser can do it. Everywhere else, verification rests on the document, and the result says so: assuranceLevel is chip, gov_db or document.

• Server-side re-checks. Liveness can use gestures, a random sequence of screen colours, or both. For the flash check the phone reports what it saw and we then read the recording ourselves, colour by colour. If our reading is too faint to judge it is recorded as inconclusive and is not held against the person. If the recording never arrives, your workflow either routes that case to a person or declines it. More in server-side liveness and gesture versus flash.

• Injection signals, not injection proof. Device Intelligence looks for virtual cameras, emulators, rooted phones and failed app integrity, and a decision rule can read verification.cameraSuspect. These are signals that feed your rules. We do not claim to detect every deepfake and we publish no detection rate. This post explains the attack in detail.

• Results that explain themselves. Every result carries a top-line status, the checkStatus underneath it, a reason sentence and a stable reasonCode. Your own approve, review and decline rules run as a decision graph that records the path it took, and statusHistory lists every change and who made it, whether a workflow, an API key or a reviewer.

• Documentation for agents. The docs publish an llms.txt index, every page as Markdown, two OpenAPI 3.1 contracts, agent skills and a documentation MCP server that searches the docs and makes no API calls. The agent builds in Sandbox; a person publishes workflows and switches to live keys.

And what does not exist yet. An MCP server that acts on your account, creating sessions or reading results, is planned and not available. The MCP specification makes authorisation optional, and where it is used requires that servers "validate that access tokens were issued specifically for them" (authorisation section (opens in a new tab)). A tool that can read identity data has to meet that bar and more before we ship it.

Beyond that is our view, not a commitment. We think verification is heading towards results that carry their own evidence trail, towards agents that act for customers and need their own way to be identified, and towards a market where providers are judged on what they admit they cannot see. We would rather be measured on that than on an adjective.

Nothing here is legal advice for your situation. What you must verify, when a person must review, and what you must tell an applicant depend on your regulator and your country.

Want to see it? Open a Toden workspace (opens in a new tab), or point your agent at the AI integration guide (opens in a new tab).