I made a mistake in how I used to think about identity screening in AI products. I treated identity verification as a boring compliance layer. Friction, yes. Annoying, definitely. But still separate from the real product.
The honest answer is that this framing no longer holds up. If even part of that architecture works the way the report suggests, then “prove you’re human” has quietly expanded into something else: submit yourself to ongoing risk classification.
I made a mistake in how I used to think about identity screening in AI products.
I treated identity verification as a boring compliance layer. Friction, yes. Annoying, definitely. But still separate from the real product. You upload an ID, take a selfie, wait a few seconds, and move on.
The honest answer is that this framing no longer holds up.
A recent investigation by vmfunc and collaborators argues that OpenAI and Persona may sit inside a much deeper identity screening stack than most users realize. The claim is not simply that users verify themselves once. It is that verification may now feed into a broader architecture of watchlist checks, biometric comparisons, recurring screening, and government-adjacent compliance workflows.
If even part of that architecture works the way the report suggests, then “prove you’re human” has quietly expanded into something else: submit yourself to ongoing risk classification.
That shift matters far beyond one company.
When a platform asks for your passport, most people assume a narrow transaction.
The implied bargain sounds simple. Confirm that I am a real person. Confirm my age if needed. Then delete whatever you do not need. That is the mental model most of us carry into these flows.
But the investigation describes something wider.
According to the report, Persona’s infrastructure included public indicators of a dedicated openai-watchlistdb.withpersona.com deployment and certificate transparency records going back to November 2023. The report also cites source-map exposure on a government deployment that allegedly revealed 2,456 source files and 53 MB of TypeScript source. The reported code references describe functions for Suspicious Activity Reports, FINTRAC reporting, face list management, watchlist screening, and 269 verification checks across multiple categories.
That is no longer a narrow identity check.
It looks more like an identity intelligence layer.
Not everyone agrees with treating infrastructure evidence this seriously. Some prefer to wait for official confirmation. Others see source-map analysis as too indirect to support larger claims. I think that caution is fair.
But I also think the underlying pattern deserves attention even if some of the strongest allegations remain unproven.
Because the pattern is already visible.
According to the report, Persona’s infrastructure included public indicators of a dedicated openai-watchlistdb.withpersona.com deployment and certificate transparency records going back to November 2023. The report also cites source-map exposure on a government deployment that allegedly revealed 2,456 source files and 53 MB of TypeScript source.
The reported code references describe functions for Suspicious Activity Reports, FINTRAC reporting, face list management, watchlist screening, and 269 verification checks across multiple categories.
openai-watchlistdb.withpersona.com/vite-dev/269 verification checks
When a platform asks for your passport, most people assume a narrow transaction. The implied bargain sounds simple. Confirm that I am a real person. Confirm my age if needed. Then delete whatever you do not need.
But the investigation describes something wider. Even if you set aside the most alarming language in the original article, the architectural direction is clear. Identity verification is no longer behaving like a one-time gate. It is turning into an ongoing classification process.
The investigation points to a stack that may include selfie and liveness checks. A user sees one prompt.
Behind that prompt may sit portrait similarity scoring and list-based monitoring that continues after the initial decision. The company knows the process. The user experiences only the verdict.
The investigation points to a stack that may include device and browser fingerprinting. A classification layer keeps asking new ones: Should this user still be trusted? Has this device appeared before?
Those are fundamentally different products, even if they are wrapped in the same onboarding screen. That distinction matters.
The investigation points to a stack that may include sanctions screening. The reported code references describe functions for watchlist screening, and the report cites a hostname labeled watchlistdb.
Individually, each point could have a narrower explanation. Together, they suggest a different category of infrastructure than the public language of “trust and safety” usually implies.
The investigation points to a stack that may include politically exposed person checks. The report cites source code references to PEP facial similarity.
A classification layer keeps asking new ones: Does this face resemble another face? Does this name match a list? Those are not the same as a simple one-time identity check.
The investigation points to a stack that may include adverse media screening. Here’s what I learned from reading the article closely: the biggest risk is not one dramatic abuse case.
It is the normalization of layered scrutiny without proportional explanation. Behind one prompt may sit adverse media configuration, fuzzy name matching, and list-based monitoring that continues after the initial decision.
The investigation points to a stack that may include recurring re-screening. The report cites support for recurring screening intervals.
Identity verification is no longer behaving like a one-time gate. It is turning into an ongoing classification process, where the system keeps asking whether this user should still be trusted.
The investigation points to a stack that may include crypto address risk checks. A classification layer keeps asking new ones: Has this wallet touched a flagged cluster?
That is part of what makes this feel like an identity intelligence layer rather than a narrow identity check. The interface stays simple while the machinery behind it gets denser.
The investigation points to internal list management for faces, geolocations, and device identifiers. The reported code references describe functions for face list management, and the report cites retention controls for face list items capped at 3 years.
That is no longer a narrow identity check. It looks more like an identity intelligence layer.
One-time access gate
A gate answers one question: Can this user enter? The implied bargain sounds simple. Confirm that I am a real person. Confirm my age if needed. Then delete whatever you do not need. That is the mental model most of us carry into these flows.
Identity verification, in this narrower model, behaves like a single checkpoint. You upload an ID, take a selfie, wait a few seconds, and move on. The user experiences a bounded transaction rather than a persistent system of scrutiny.
Ongoing classification layer
A classification layer keeps asking new ones: Should this user still be trusted? Does this face resemble another face? Does this name match a list? Has this device appeared before? Has this wallet touched a flagged cluster?
That is no longer a narrow identity check. It looks more like an identity intelligence layer. Identity verification is no longer behaving like a one-time gate. It is turning into an ongoing classification process, where recurring screening, watchlist checks, biometric comparison, and list-based monitoring may continue after the initial decision.
November 2023
Certificate transparency records going back to November 2023.
2+ years
Certificate history showing the service live for more than two years.
Millions monthly
Persona’s public case study claiming it screens millions monthly.
3 years
Retention controls for face list items capped at 3 years.
269
A check enum containing 269 verification checks.
2,456 files / 53 MB
A government deployment allegedly revealed 2,456 source files and 53 MB of TypeScript source.
The most uncomfortable part of the investigation is not the headline language. It is the accumulation of specific details.
The report cites:
/vite-dev/Individually, each point could have a narrower explanation.
Together, they suggest a different category of infrastructure than the public language of “trust and safety” usually implies.
Here’s what I learned from reading the article closely: the biggest risk is not one dramatic abuse case. It is the normalization of layered scrutiny without proportional explanation.
A user sees one prompt.
Behind that prompt may sit sanctions logic, fuzzy name matching, portrait similarity scoring, adverse media configuration, and list-based monitoring that continues after the initial decision. That is a serious asymmetry of information.
The company knows the process. The user experiences only the verdict.
The company knows the process. The user experiences only the verdict.
Based on the article’s citations and links, the strongest elements appear to be: Publicly observable infrastructure records; Certificate transparency history; Public Persona marketing claims about large-scale screening; Source-map exposure on government endpoints; Code references to reporting, watchlists, and verification logic; Presence of OpenAI-related infrastructure naming.
These are more interpretive: The degree to which OpenAI user data and government compliance workflows share practical overlap; Whether the same codebase implies the same operational use of data; Whether recurring screening applies to all verified users in the same way.
This is where caution matters most: Direct data transfer from OpenAI user verification into government enforcement pipelines; A confirmed connection between Persona’s “ONYX” deployment and Fivecast ONYX; Specific intent beyond what the infrastructure and code paths reveal.
Most privacy debates fail because they happen at the wrong level of detail.
When a user sees one onboarding prompt, the mental model is a one-time verification exchange: prove identity, satisfy the rule, move on. But if the underlying system supports recurring screening intervals, watchlist checks, facial similarity comparisons, and list-based monitoring after the initial decision, then the meaning of that prompt changes. Consent given for a narrow gate does not automatically become consent for an ongoing classification layer.
That is the design choice that matters. A product can present a calm, minimal verification flow while quietly authorizing a much broader process than the interface suggests. The real issue is not only data collection. It is low-resolution consent: the user agrees to a simple front-end action while the back-end reserves the right to keep asking new risk questions later.
| QUESTION | WHAT A COMPANY SHOULD EXPLAIN IN PLAIN LANGUAGE |
|---|---|
| What exactly is being checked beyond the ID and selfie? | A company should explain whether the flow only confirms that a user is a real person. It should say whether it also runs sanctions screening, politically exposed person checks, adverse media screening, device and browser fingerprinting, wallet risk checks, face list matching, or watchlist screening. The key point is whether the process is a one-time gate or an ongoing classification process. |
| Does screening happen once, or does it happen again later? | A company should explain whether verification ends after onboarding or whether there is recurring re-screening. If recurring intervals exist, users should be told what triggers a new check, how often re-screening can occur, and whether a person can be flagged after they were previously approved. |
| How long is this information kept, and what is retained? | A company should explain what data is stored, including IDs, selfies, biometric templates, device identifiers, geolocation data, and list-management records. It should also explain retention limits in concrete terms. The reporting references retention controls for face list items capped at 3 years, and users should not have to infer that kind of timeline from exposed code or infrastructure clues. |
| What happens if someone is blocked, matched, or misclassified? | A company should explain what recourse exists if access is denied or restricted. That means stating whether a user can appeal, request review, correct a false match, learn whether a watchlist or similarity score was involved, and understand why the decision was made. The article’s concern is the asymmetry of information: the company knows the process, while the user experiences only the verdict. |
Most people do not meaningfully consent to an identity governance layer. They consent to a screen. A prompt. A compliance ritual that appears narrow, temporary, and easy to understand. But if that layer quietly governs whether someone can access core AI systems, appeal a decision, or remain continuously eligible for participation, then the real issue is not just privacy. It is institutional power hidden inside interface design.
That is why the future questions are larger than whether one investigation proves every link in the stack. The harder question is what kind of digital society gets built when identity checks become durable control systems for access to intelligence. If AI tools increasingly shape how people write, code, learn, research, and earn, then the standards around screening, retention, recurring review, and explanation cannot remain vague. A user should know the threshold being applied, the category they were placed in, the basis for that decision, and whether any meaningful appeal exists.
If identity systems are going to sit at the gateway to AI participation, then they should be governed like infrastructure, not presented like a one-time form. That means clearer disclosure, narrower data use, real auditability, and due process that extends beyond a silent rejection. Otherwise, “trust and safety” becomes a soft label for something much harder: opaque classification with social consequences. The more essential AI becomes, the less acceptable that arrangement is.