Verification is a trust problem. Every time a business accepts a piece of information as true — an income figure, an employment status, a policy number, a loyalty tier — it is making a trust decision. The history of verification is the history of how that trust decision gets made, and the models that support it have changed more than most people realize.
We are now at the end of the third model and the beginning of the fourth. Understanding why the first three failed in sequence reveals why the fourth is fundamentally different.
How has verification trust evolved?
Verification trust has moved through four distinct eras, each defined by its assumptions about how to determine whether information is authentic. The first three share a structural flaw. The fourth breaks from the pattern entirely.
Era 1: Manual review
The original trust model was human judgment. A person looked at a document and decided whether it seemed legitimate. Loan officers reviewed pay stubs. Insurance adjusters examined repair invoices. Property managers read employment letters. The trust assumption was simple: a human expert can spot a fake.
This worked when document forgery required skill and effort. A forged pay stub in 2005 required knowledge of payroll formatting, access to design software, and enough time to make the result convincing. The cost of forgery was the primary deterrent, and manual review served as a reasonable check against casual fraud.
Era 2: OCR and automation
As document volumes grew, manual review became a bottleneck. Organizations adopted optical character recognition (OCR) and rules-based automation to extract data from documents and flag inconsistencies. The trust assumption shifted: if the data in the document matches expected patterns, it is probably authentic.
OCR systems checked whether numbers added up, whether dates fell within expected ranges, and whether formatting matched known templates. This scaled the review process but did not change the underlying model. The system was still trying to answer the same question — does this document look right? — just faster.
Era 3: AI-powered detection
The current era applies machine learning and computer vision to document analysis. AI models are trained on datasets of authentic and fraudulent documents to classify new submissions. They analyze pixel-level patterns, metadata structures, font rendering, compression artifacts, and dozens of other signals invisible to human reviewers. The trust assumption is: if a model trained on enough data cannot distinguish this document from an authentic one, it is probably real.
This is the most sophisticated detection approach yet, and it is already failing. Generative AI produces documents that defeat these models because the generation tools and detection tools are built on the same underlying technology. A GAN or diffusion model can produce outputs that specifically optimize against the features a detection model looks for.
Era 4: Cryptographic proof
The fourth era abandons the detection paradigm entirely. Instead of examining a document and trying to determine if it is real, cryptographic proof confirms that data came from the claimed source. The trust assumption is categorically different: if the data is cryptographically linked to the authoritative source, it is authentic by definition.
This is not an incremental improvement on detection. It is a different question. The first three eras all asked: is this document real? The fourth era asks: did this data come from the source?
Why do detection-based models always fail eventually?
All three detection eras — manual, automated, and AI-powered — share the same structural vulnerability. They operate on the output (the document) rather than the origin (the source system). This creates an asymmetry that favors the attacker.
The defender must catch every possible type of forgery. The attacker only needs to defeat the specific detection method in use. When the defender publishes new detection signals or deploys new models, the attacker adapts. The feedback loop is fast and the adaptation cost is low, particularly when generative AI tools make iteration nearly free.
This dynamic plays out identically across all three eras:
- Manual review: Forgers learned what human reviewers looked for and produced documents that passed visual inspection.
- OCR and automation: Forgers ensured their documents had consistent data, proper formatting, and expected patterns.
- AI detection: Generation models optimize against detection model features, producing outputs that are indistinguishable from authentic documents by the detection system's own criteria.
Each era lasted until the forgery tools caught up with the detection tools. The current era is the fastest cycle yet because AI-powered generation and AI-powered detection are evolving in lockstep, and the generation side has the structural advantage.
What makes cryptographic proof fundamentally different?
Cryptographic proof does not examine documents. It verifies the origin of data using mathematical guarantees that cannot be forged, regardless of how sophisticated the attacker's tools become.
Every previous trust model asked the same question: is this document real? Cryptographic proof asks a different question entirely: did this data come from the source? That shift is categorical, not incremental.
Three properties distinguish cryptographic proof from every detection-based approach:
It is not probabilistic. Detection models produce confidence scores — 87% likely authentic, 94% likely fraudulent. Cryptographic verification is binary. The data either came from the claimed source or it did not. There is no gray zone, no threshold to tune, no false-positive rate to manage.
It does not degrade over time. Detection models lose effectiveness as generation tools improve. Cryptographic protocols do not degrade because they do not depend on pattern recognition. The mathematical properties of DKIM, TLS, and OAuth are not weakened by advances in generative AI. A DKIM signature is exactly as reliable today as it will be in ten years.
It cannot be defeated by better forgery. You can produce a pixel-perfect document that fools any detection model. You cannot produce a valid DKIM signature for a domain you do not control. You cannot forge a TLS session with a server you have not connected to. You cannot fabricate an OAuth token from a system that did not issue one. The security is mathematical, not heuristic.
What does this look like in practice?
The mechanisms of cryptographic proof vary by source, but the principle is consistent: verify the data's origin rather than inspecting a copy of it.
DKIM-signed email verification
When an organization sends an email — a booking confirmation from an airline, a pay notification from a payroll provider, an account statement from a bank — the sending server attaches a DKIM signature. This signature cryptographically binds the email content to the sending domain. Burnt verifies this signature against the sender's public DNS key, confirming that the email was sent by the claimed domain and that its content has not been altered. The specific fact needed (a flight date, an income figure, an account balance) is extracted from the verified email without retaining the full message.
TLS-based portal verification
Many data sources expose information through web portals — insurance portals showing policy details, government portals showing license status, employer portals showing employment records. When a user authenticates with a portal and Burnt retrieves the relevant data, the TLS connection provides cryptographic proof that the data came from the claimed server. The certificate chain confirms the server's identity, and the encrypted channel ensures the data was not intercepted or modified in transit.
OAuth-based API verification
Where data sources expose APIs — payroll systems, banking platforms, subscription services — OAuth provides a standard mechanism for user-consented data access. The user authenticates with the source system and grants Burnt access to specific data. The API response comes directly from the source, authenticated by the OAuth token exchange. There is no document in the process and no opportunity for the data to be intercepted or fabricated between the source and the verifier.
The shift from detection to proof is not a technology upgrade. It is a change in what verification means. For two decades, verification meant inspecting a document and hoping it was real. Going forward, verification means confirming that data came from its source — with mathematical certainty, not probabilistic confidence. That difference is not a matter of degree. It is a different category entirely.
Frequently asked questions
Detection-based verification accepts a document and tries to determine if it is real or fake. Proof-based verification skips the document entirely and confirms data directly from the authoritative source using cryptographic mechanisms like DKIM, TLS, and OAuth. Detection asks "is this fake?" while proof asks "did this come from the source?"
Detection models identify patterns in fraudulent documents, but each new signal teaches forgers what to fix. Generation tools evolve to defeat whatever detection catches, creating a permanent arms race where the offense has a structural advantage — it only needs to match the latest detection model, while detection must catch every possible forgery.
Source verification uses three primary cryptographic mechanisms. DKIM verifies that emails came from the claimed sending domain and have not been altered. TLS confirms that data was retrieved from a specific web portal over a secure connection. OAuth provides authenticated access to data through the source system's own API, with the user's explicit consent.
No. The protocols that power cryptographic verification — DKIM, TLS, and OAuth — are already deployed at global scale. DKIM has been signing emails for nearly two decades. TLS secures virtually every website. OAuth is the standard authentication mechanism for APIs. Source verification builds on infrastructure that already exists.