There’s no arguing that information is worth investing in. But there are beautiful expectations, and then there’s the ugly face of reality. Dashboards exist, alerts come in, reports land in the inbox, busy activity buzzes yet the client never gets the feeling that they have better control of the situation or that decision-making has become easier.

The inevitable outcome is disappointment and skepticism. The gap between expectation and reality is disheartening; the employer is dissatisfied and the OSINTer gets fired.

In this case, the problem is not that OSINT as a methodology doesn’t work. It’s that it is misunderstood, misused, and misinterpreted. Misunderstanding breeds errors in approach.

OSINT is not just a set of tools and methods. It is, first and foremost, a way of thinking and working with chaotic, noisy information. Tools can help and speed up the process, but they will never replace the human mind. If company management believes it all comes down to software and platforms, failure is baked into that very belief. “Press a button and everything pops out” doesn’t work here.

Let’s start from the beginning. First and foremost, you need to understand what you’re looking for and define your goals. From there, set the research task. A correctly posed question is half the answer. In practice, it sometimes happens that the OSINTer has to formulate the task themselves so that it can be understood and executed, because the client may deliver it in the form of various hand-wavy gestures and incoherent wishes (if you’re lucky, in a language that makes sense). But the client is not obligated to understand your work. Translating and interpreting their wishes is your headache. That is the very first stage of research, and one of the riskiest.

It’s important to understand not just what is happening, but also why it even matters. That is what determines the use of one particular methodology and one particular set of tools over another.

It often happens that tasks get handed over as “monitor threats,” “track social media,” “flag anything suspicious.” In form, it’s a task; in substance, it’s just a wish. Without a specific question behind a real problem, research quickly devolves into a simulation of busywork: stuff gets collected, stuff gets written into reports, but no one sorts out what’s actually important and what just seemed curious.

At the end of the day, the point of research is to reduce uncertainty for those who will make decisions. But if the client themselves can’t clearly articulate what exactly they’re unsure about, no amount of collected data will help.

Example from practice: a client a mid-sized firm in the pet food industry handed over the task as “figure out in your internets who’s messing with our pockets.” The result was a week of wasted time, a pile of disparate information, and an unhappy client. After adjusting and redefining the task as “social media and media monitoring, identifying the source of negativity, verifying information, filtering out white noise, identifying the instigator,” the result was different: identification of a coordinated campaign across local media and social platforms, and direct communication between the client and the campaign’s instigator.

So, briefly, the intermediate takeaway: the point of effort in the first stage is not speed and not the toolset, but who translates the vague “I want to know what’s going on” into a concrete question with a clear criterion for results — and how they do it. If the OSINTer explicitly takes ownership of goal-setting and documents it, the expectation gap is largely closed. What remains is the “small” matter of convincing the client that this is indeed what they want, without falling into a new conflict of expectations and reality.

Separating the Wheat from the Chaff

Any tool does a good job showing what it’s built for. But its blind spots what it doesn’t see, and what assumptions are baked into its data collection logic you won’t get those from it. It delivers a picture and stays silent about what fell outside the frame.

An unprepared analyst doesn’t notice this silence. They simply don’t see that something important is missing from the data. From this, a dangerous overconfidence can arise: appearance is mistaken for understanding. They look at the dashboard, ask no follow-up questions, and don’t challenge the data. A tool should make a strong analyst even stronger, not carry a weak one on its back. OSINT where no one asks questions is just activity for activity’s sake.

Example from practice: a serious company was leaking kilotons of important documents into open access simply because it didn’t properly filter outgoing documentation. The leak was discovered by accident, during unrelated work. To the natural question “are you out of your minds?” came the natural answer: “everything’s fine, wonderful, marvelous.” People had never even had a flicker of thought that a leak could happen in that exact place and in that way. As far as they were concerned, all the lights were green.

Information Without Context Is Useless to Anyone

The client often wants guarantees: clear-cut, unambiguous, once and for all. But OSINT operates amid probabilities, assumptions, incomplete data, and a picture that changes literally before your eyes. This is not a bug but a feature of the profession that’s how open-source analytics works, and it simply cannot be otherwise.

When clients demand guarantees instead of assessments and scenarios, disappointment is inevitable. OSINT gets blamed for “not providing answers,” even though it was never obligated to provide them in that form. Decisions are not made by the OSINTer, but by the one who is paid to make them.

Even technically strong teams fail if they are disconnected from the real context. They see perfectly well what’s happening online, but have no idea what the current priorities are, what level of risk is acceptable, or what the decision timeline is. And then the client sets the reports aside not because they don’t value the analytics, but because they can’t find an answer to the simple question: “so what do we do with this now?”

Critical Analysis Is Not Fact-Checking

Critical analysis of open data is not “fact-checking.” It’s systematic work with uncertainty, bias, gaps, and context. To avoid falling into severe uncertainty, here is a basic set of procedures. None of it is dogma, but it performs well in practical work, and it earns its keep by saving unnecessary effort.

The first layer, and the one most often skipped, is source assessment. Who created the information, when, why, and in what context? Did the author have real access to what is described? What were their motives commercial, political, reputational, ideological? How has the source behaved in the past, and where did it come from? What do the technical traces show — metadata, edit history, IP, domain, writing style, linguistic markers? A practical technique here is to explicitly record, for every key claim, who said it and on what basis.

Second comes triangulation. A single source is rarely evidence, so the work is to seek independent confirmation from sources with different interests, origins, and methodologies and to compare not just matches but discrepancies too. It’s worth differentiating primary observation from secondary retelling from tertiary commentary. And a caution worth keeping in mind: three media outlets quoting the same agency is not triangulation.

Third is context and scale analysis. Data without context is almost always useless. That means weighing temporal context (when something happened versus when it became known), geographic and cultural context, the scale of the phenomenon (an isolated incident or a systemic pattern), and a comparison against a baseline what’s considered normal in this environment. The question worth asking constantly is how much a given finding deviates from the usual state of affairs.

Fourth is searching for the absent, one of the most powerful and underrated methods available. What is missing from the data that ought to be there? Which sources are silent? What types of information are systematically absent? Are there gaps that are themselves a signal? Often the most important thing is not what’s written, but what’s persistently left unsaid.

Fifth is identifying bias and framing: which words are chosen and which are avoided, what’s placed in focus and what’s pushed to the periphery, what emotional coloring or moral judgment creeps in, and what was shown versus what was cut. It helps to keep observed fact, interpretation, and evaluation clearly separated from one another.

Sixth is checking internal consistency does the source contradict itself across different places or points in time, does its stated methodology match the actual data it produced, and does the resulting picture look too convenient?

Seventh is working with hypotheses and alternatives. Instead of seeking confirmation of your own working theory, formulate several competing explanations, look for data that could disprove each of them, and assess which hypothesis requires the fewest assumptions Occam’s razor, applied deliberately rather than assumed.

Eighth is quantifying uncertainty. Honest analytics always shows the boundaries of its own knowledge: a confidence level (high, medium, or low), the key assumptions behind it, what could change the conclusion, and what critical data is still missing.

To this list, it would be good to add temporal analysis connecting events over time and reflexive analysis of the analyst’s own work, but these aren’t always necessary. Most cases are simpler and don’t call for that depth.

Putting It Together

Combining what was said at the start with this checklist gives a practical workflow. First, formulate a specific question not “what is happening,” but “what do we need to know to make decision X.” Second, collect the initial data set. Third, assess sources and filter out obvious noise. Fourth, triangulate the key claims. Fifth, analyze context, gaps, and bias. Sixth, construct and test alternative hypotheses. Seventh, formulate conclusions with explicit indication of uncertainty and implications.

Common Mistakes

The recurring failures worth naming: mistaking appearance for understanding a green dashboard read as “everything is fine.” Confusing data volume with analytical quality. Ignoring silence and the absence of information. Demanding certainty and guarantees from open data. And working only within a single platform or ecosystem, mistaking its view for the whole picture.

Good critical analysis of open data almost always leaves more questions than answers, and that is normal. Its value isn’t in knowing everything — it’s in reducing uncertainty around the case just enough to support the decision that has to be made.

I think we’re looking in the wrong direction. Not because AI won’t replace anyone certain tasks, roles, and even entire professions will almost certainly disappear. It’s just that “replacing humans with machines” doesn’t quite capture what’s really happening. AI is changing not so much the volume of work as its economics, and much more rapidly: the cost of achieving a certain quality of output is dropping sharply, and along with it, our sense of what quality even counts as acceptable is shifting too.

I quickly got used to the short distance between “roughly knowing what I want” and the final result. Previously, any improvement came at a cost. Checking one more source, digging into an unfamiliar topic, double-checking your own logic, iterating through options, rewriting a text, building a prototype and discarding it all of that took time. So at some point, “good enough” became a perfectly reasonable stopping point. If improving a result from 80% to 85% requires another two hours, sometimes those five percentage points simply aren’t worth the time.

AI broke that math. Now the next iteration often costs just a few minutes: fact-checking, finding a weak spot in the argument, asking the model to argue against the original thesis, looking at the problem from another angle, iterating through options, and then circling back to the first idea. The model’s answer doesn’t have to be correct in an experiment with 758 BCG consultants on a task beyond GPT-4’s capabilities, the control group gave the correct answer 84.5% of the time, while GPT users got it right only 70.6% of the time. But on tasks within the model’s capabilities, people worked faster and produced higher-quality results. An experiment by Shakked Noy and Whitney Zhang with 453 professionals shows the same dynamic: roughly 40% less time with an approximately 18% increase in quality.

In other words, AI doesn’t just make producing results cheaper. It makes trying to improve the result cheaper. And this, in my opinion, is more important than yet another forecast about the number of programmers in 2030.

Quality Inflation

In 1937, Feuerhand sold about 12 million kerosene lanterns. Then electric lighting came along, but Feuerhand didn’t disappear well into the 21st century, the company was still producing millions of lanterns a year. The kerosene lamp remained a perfectly functional device; electricity just made light so cheap, accessible, and ordinary that the lamp stopped being a normal way to light a room and moved to places where its features still made sense off the grid, in emergencies, on camping trips.

Something similar may happen to intellectual work. A good report, presentation, analysis, or piece of code doesn’t become worse because AI exists. What changes is the cost of achieving that result, and with that cost, the point at which we’re willing to say “good enough.”

If an additional review of a report costs two hours, you can justify skipping it by citing the cost. If it costs ten minutes, that justification becomes harder. If a presentation of a certain caliber used to take half a workday and now takes twenty minutes, the ability to produce exactly that presentation remains useful but it no longer commands the same price. The next employee will show up with the same PowerPoint, the same ChatGPT, and the same twenty minutes.

You could call this quality inflation in intellectual labor. What’s being devalued is not intelligence or the profession itself, but a certain level of output, because it has become cheaper to produce. Yesterday it was rational to stop at 80%, because the next five percentage points cost two hours. Today they cost a few prompts and thirty minutes of verification so they gradually stop being an extra premium and become part of the baseline.

There’s nothing particularly new here. Spreadsheets didn’t wipe out accounting, even though a huge chunk of the work accountants used to do by hand now happens instantly in Excel. Computers didn’t mean accountants could finish the monthly report by lunch and spend the next two weeks staring out the window. Email didn’t free up the hours once spent on paper correspondence, and search engines didn’t give researchers half their day back. When technology lowers the cost of an operation, organizations usually don’t return that gain to the employee as free time they start demanding more.

With AI, quality stacks on top of quantity. If you can test more hypotheses, explore more options, do an extra iteration, and double-check your conclusions in the same amount of time, that eventually becomes what’s considered normal work. So I don’t think productivity gains will automatically leave half of knowledge workers idle. Historically, we’ve been far better at turning productivity into new demands than into free time.

It Didn’t Land

With AI, this has only become more relevant. You can have a model at your fingertips that’s capable of checking arguments, finding sources, offering alternatives, pointing out contradictions, and playing devil’s advocate and yet use it only as a “write me a text” button. You can get an analysis and fail to notice that the machine perfectly answered a slightly different question. You can ask for code, get a decent result, and have no idea why it works or under what conditions it breaks.

The problem here isn’t the model’s quality. A person first has to understand what exactly they need, and then be able to evaluate what they got. And the better the models get, the less noticeable a mistake can be: poorly written nonsense is suspicious on its face; well-written nonsense has to be checked.

When only one analyst in ten has access to AI, that access gives a noticeable edge. When all ten have it, access itself stops meaning anything. Two people with the same model get different results not because one got a good ChatGPT and the other a bad one. One uses the model to iterate through options, test their own assumptions, and find holes in their reasoning; the other takes the first decent-looking answer and runs with it.

So the mass adoption of AI doesn’t destroy skill. It just changes which part of it is worth paying for.

A study by Erik Brynjolfsson, Danielle Li, and Lindsey Raymond with 5,179 customer support employees illustrates this well. After introducing an AI assistant, average productivity rose by about 14%, but for newer and less experienced employees the increase was about 34%, while for the most experienced it was modest. The model effectively let less experienced workers adopt some of the practices of the best performers.

It’s easy to spin this into a catchy headline about AI erasing the gap between juniors and seniors, but the study only shows that a novice with a model starts performing better on certain tasks. Years of experience, an understanding of the system, and the ability to spot a problem no one has articulated don’t come with a subscription.

And here an interesting asymmetry emerges. Producing an answer is getting cheaper much faster than verifying it.

METR studied experienced open-source developers working on large codebases they already knew well. Before the experiment, the developers expected AI to speed them up by about a quarter; afterward, they still felt it had sped them up, but in fact their tasks took about 19% longer. This doesn’t mean AI hinders programming the study is narrow, the participants are experienced, and the tools are changing fast. But it clearly shows where some of the promised speedup goes.

The model can write a function in thirty seconds, but the engineer still needs to understand what it does, whether it accounts for constraints, and whether it broke a neighboring component. You can get a text in a minute, but someone has to notice that one argument doesn’t follow from the previous one. You can assemble an analytical memo in ten minutes, but someone needs to know that the baseline metrics can’t be compared that way. Generating answer options becomes nearly free — but the ability to tell a good option from convincingly packaged nonsense doesn’t get any cheaper.

Research from Microsoft Research and Carnegie Mellon on 319 professionals adds another wrinkle. The more a person trusted AI’s ability to perform a task, the less critical thinking they applied; the more confident they were in their own ability to perform and evaluate that task, the more often they checked and reworked the result. This creates a somewhat ironic dynamic: the person best equipped to control the AI is the one who needs the least help from it to understand the task, while the one with the most reason to trust a ready-made answer is precisely the one who may lack the knowledge to verify it.

So skill isn’t going anywhere. Part of its value is just shifting from the ability to produce an answer to the ability to frame the right question, choose between responses, and determine whether the result can be trusted.

So What About Juniors?

Here I’m not so sure about the popular prediction that AI will inevitably eat the bottom of the professional ladder. Early data from the Stanford Digital Economy Lab does show a worsening position for young workers in AI-exposed professions, mainly through reduced hiring — though the authors themselves caution that causality hasn’t been proven (as if they’d say anything else; they’d be eaten alive otherwise — author’s note). This could well be the first effect: if a junior with AI produces more, a company today needs fewer juniors to handle the same volume of work.

But “the same volume of work” is precisely the questionable assumption here.

If productivity gains automatically reduced the need for specialists in proportion to those gains, Excel should have caused a small demographic catastrophe in accounting. Instead, accounting got Excel, ERP, electronic document management, automated postings, bank integrations, and a massive volume of reporting, control, and analysis that simply wouldn’t have made economic sense with manual processing.

With AI, the same mechanism could operate across all skill levels at once. A junior with AI will be able to do some of yesterday’s mid-level work — but the mid won’t stand still. They’ll have the same AI, more baseline skill, and the ability to tackle tasks that were previously too expensive or time-consuming. The same applies to the senior. If the cost of intellectual iteration falls for everyone, the boundary of economically viable work shifts for everyone as well.

So I wouldn’t rush to bury juniors. It’s quite possible their work will simply get harder. What yesterday required hiring someone for an entry-level position will be partly automated, but at the same time, a whole range of work will emerge that no one used to do because it cost more than it was worth. We don’t know whether one will fully offset the other, and today’s data doesn’t prove it. But the assumption that “productivity went up 30%, so we’ll need 30% fewer people” has held up poorly through several technological revolutions in a row.

The training problem remains, though. If the simple tasks people used to learn on disappear, we’ll have to change how we grow specialists. But that’s a problem of how the professional ladder is built not proof that the bottom rung becomes unnecessary.

On Dependency

Another popular question is whether we’ll become too dependent on AI.

Of course we will. We depend on electricity, cars, food logistics, computers, the internet, and search engines. I’m always late everywhere, so I’m heavily dependent on clocks and cars. :-)

Civilization is largely built on technologies that prove so useful that giving them up becomes costly. So dependency itself tells us little about the quality of the technology. The more interesting question is which capabilities we hand over to the tool and which we keep for ourselves.

The calculator long ago took away the need to quickly multiply large numbers, and that’s been fine as long as a person can tell that 14,812 × 73 = 81 looks suspicious. The problem starts not when the machine calculates instead of the person, but when the person can no longer tell that the machine has calculated nonsense.

With AI, this boundary is harder to see, because it doesn’t handle just one operation. It writes, searches, compares, analyzes, codes, proposes solutions, and explains its own answers. The more of these operations we hand over, the more important it becomes not to check every intermediate step, but to check the whole construct: did we ask the right question, can we trust the source data, does the conclusion follow from the arguments, and does the result make sense?

And here we come back to the start.

AI doesn’t just make intellectual work faster. It lowers the cost of quality. Additional checks, another hypothesis, an alternative approach, a critique of your own decision, and one more iteration become cheaper and therefore gradually stop being an extra service and become part of normal work. What yesterday counted as a good result doesn’t disappear and doesn’t get worse it just stops being a sufficient reason to call the work good.

So the main effect of AI on the labor market may not look like the sequential disappearance of copywriters, juniors, mids, and seniors. It’s much more likely that all of them stay in the game but everyone will have to do work that yesterday cost more than their time was worth. The junior gains some of the mid’s capabilities, the mid gains some of the senior’s, and the senior can afford a depth of analysis and a number of iterations that previously made no economic sense.

And if that’s truly the case, the question “who will AI replace?” is being asked too early.

First, we should see how much work suddenly becomes worth doing once doing it well has become cheap.

That folder gets built more often than you’d think, and not just for people who did something wrong. In M&A due diligence, litigation prep, and executive risk assessments, the subject of the investigation is frequently just a person who signed up for a lot of things over twenty years and never gave it a second thought. The findings aren’t secret. They’re sitting in public view, waiting for someone with the right method to connect them.

What an analyst actually sees

Per my own experience running these investigations, the process rarely starts with anything dramatic. It starts with an email address or a phone number, because those are the keys that tie everything else together. If someone reused an email address across a banking login, a decade-old forum account, and a shopping site that got breached in 2019, that address alone gives me a timeline of services, a rough age of the account holder, and via a breach dump sometimes a password pattern that person still uses elsewhere.

From there, usernames do the rest of the work. A person picks a handle at nineteen, uses it on a gaming forum, then again on GitHub, then again on a professional network years later without thinking twice. Tools built for exactly this purpose checking a username’s footprint across hundreds of platforms will return every account tied to that string of characters in seconds. The GitHub profile that looks entirely professional links, through the username alone, to a decade-old post where the person named their employer, their city, and their daily commute.

None of this required hacking, purchasing stolen data, or any method Red Dog Security’s ethics policy would prohibit. Every one of these findings came from publicly accessible information: cached pages, breach data that’s already circulating publicly, metadata embedded in ordinary files. That’s the uncomfortable part. The information was never hidden. It was simply never assembled before.

Metadata is the quiet one

If cookies and browser fingerprinting are the noisy trackers everyone half-understands, metadata is the one nobody thinks about at all. Every photo carries GPS coordinates, a timestamp, a device model, sometimes a serial number. Every document carries an author name, an editing history, and the software used to produce it.

I’ve seen this bite people in ways that had nothing to do with malice. A leaked internal document during a litigation matter still had the original author’s name embedded in the file properties, despite every visible reference to that person having been redacted from the text itself. In a due diligence context, the same oversight can attach an executive’s name to a document they believed was anonymous, or place them at a location they’d rather not have confirmed on a specific date.

Stripping metadata before sending or publishing a file takes one extra step. Skipping that step is how confidential becomes public.

Why this matters to deal teams and legal practices

Executives and principals involved in a transaction, a litigation matter, or a security incident carry the same accumulated digital footprint as anyone else, and that footprint doesn’t stop being relevant just because the person in question runs a company instead of posting on a forum. A due diligence team evaluating a target company’s leadership benefits from knowing what’s publicly reconstructable about the people making representations in that deal. A litigation team benefits from knowing what an opposing party’s own public footprint already establishes, before the other side finds it first.

This is the business case for what’s otherwise personal advice: the same OSINT methodology used to find undisclosed breaches or verify beneficial ownership applies just as cleanly to individuals. Reused credentials, linked usernames, and unstripped metadata are findings, not gossip. They belong in a risk assessment the same way an unpatched server does.

A practitioner’s framework for reducing exposure

The goal here isn’t to disappear. Total invisibility isn’t achievable in 2026, and chasing it usually wastes effort that would be better spent on the following, more achievable steps.

Compartmentalize by context. Maintain a professional identity tied to your real name, a separate personal identity for friends and family, and a third identity for one-off registrations and trial subscriptions you don’t intend to keep. None of these three should share an email address, a username, or a payment method. The moment they overlap, an analyst can connect them, and the whole point of separating them collapses.

Treat email addresses and phone numbers as the primary keys they are. A breached email address exposes every service tied to it. A compromised phone number, particularly one used for two-factor authentication, exposes considerably more. Separate addresses for banking, for social accounts, and for disposable registrations reduce that exposure meaningfully.

Strip metadata before any file leaves your hands, whether that’s a photo, a resume, or a document produced for a deal or a filing. This is a five-second habit that closes a gap most people never think to check.

Assume anything posted publicly will eventually be found by someone with a reason to look for it. That includes location data, which reveals routines and patterns far more readily than most people expect. A public account that posts from the same coffee shop every morning has already disclosed a neighborhood and a schedule.

Audit the footprint periodically rather than once. Search your own name, your usual usernames, and your primary email address every six months or so. What comes up will change as accounts age, as breaches accumulate, and as your professional profile changes with a new role or a new deal.

Do We Really Need Code Agents?

Preface

Several factors prompted me to write this article:

• Problems with generated code when working in a team.

• Increased cognitive load.

• Active (forced) adoption pushed by CTOs/management.

• And overall, you can’t really have a proper debate with colleagues you need a larger audience. When I suggest we think things through, I usually get marketing articles from LLM beneficiaries thrown at me, or some rather strange analogies, which I’ll also address in this article.

In general, I’m not trying (okay, I am trying) to convince anyone of anything. My main point is to encourage asking more questions and thinking about clearer boundaries for the applicability of AI/LLMs in development.

What This Article Will NOT Cover

I see no reason to avoid using LLMs altogether. They definitely provide value and certainly speed up certain routine tasks.

“Generate a JSON mock for me, here’s the contract schema,” “What do you think about…,” “Do you see any problems in this piece of code…,” “Here’s an ORM query, I need an equivalent SQL query in PostgreSQL dialect,” “I’m writing in language X, framework Y, and I’ve run into this problem, here’s the log—what’s the cause and how can I fix it…”

These are examples of queries that, in my opinion, are perfectly valid, and LLMs handle them remarkably well in most cases. LLMs are pretty good as a second opinion. So, there won’t be any total LLM hate here.

What This Article WILL Cover

I’ll examine the problems of using LLMs as a primary tool. Again—not as a second opinion tool, but as the primary tool that writes the majority of the code in merge requests spanning hundreds or thousands of lines. I’ll also cover edge cases where the developer supposedly reads the generated code and supervises the agent.

The Problems

1. Generated Code in Team Work

Merge requests. LLMs generate a lot of code. LLMs cannot think a feature through deeply. LLMs cannot form a set of questions and go to product managers/designers/analysts for additional information that could help design and write simpler, more intuitive code.

LLMs write code only for the current request. They don’t care about tomorrow, they don’t care about the roadmap, they don’t care about the consequences for neighboring services/modules. As a result, we see a lot of code for a small feature in a merge request.

A few days later, a request comes in to add another feature to the same module, and the LLM rewrites the entire code, and again we get a diff of +1500 -1400. Reviewing such volumes this frequently is simply impossible. This doesn’t just slow down development—it completely nullifies any benefits. It accelerates the rate of change in the codebase, and the pace becomes overwhelming for the human brain.

After a few such iterations, I stop understanding a service that just yesterday I was reasonably familiar with and could quickly fix some unexpected bugs thanks to a deep understanding of the codebase. Now even bug fixes will take much longer. Cognitive load skyrockets. Developers were supposed to fight complexity, but the exact opposite has happened.

As a result, review quality drops. And consequently, code quality and the quality of releases/products as a whole suffer.

2. Increased Cognitive Load

This point ties into the previous one. However, I’d like to focus on slightly different aspects. As of 2026, most players in the IT world still underestimate the level of cognitive load. This, in turn, affects emotional strain and the developer’s overall health.

Today, a developer uses tons of different tools in their daily work, which require knowledge beyond just the programming language itself. These include linters, formatters, containers, CI/CD pipelines, task trackers, methodologies, frameworks, various architectures and SOLID principles, type checkers, load testing tools, emulators, version control systems, databases, message brokers, and so on, and so on.

Not to mention that the languages themselves are getting more complex. I’ve yet to see any language become simpler. Yesterday’s object-oriented language is now heavily using pattern matching branches instead of familiar ifs. Getting familiar with this whole zoo takes months, and mastering it takes years.

And that was all yesterday. Today, another tool has been added: LLMs. Which differ from all the rest. Their interface changes too quickly. Their boundaries of applicability are blurred. There’s no time to think—you must use it, or the market will cast you out tomorrow, as every second person claims—from LLM provider CEOs to your colleagues, and indeed, it’s in almost every other job posting (if not the first).

LLMs generate code fast. You need to read it, understand it, correct it again, read it again, understand it, correct it again. Nobody even stops to wonder whether the brain can even work at such a pace. But, as usual, there’s no time to think the feature was promised to be released yesterday.

3. Active (Forced) Adoption by CTOs/Management

It’s the usual story here. Management is driven by hype. Management is more prone to cargo cult thinking. Having made +x profit yesterday, today they’re already thinking about +10x. And nothing will stop them. Not appeals to articles or facts, not explanations of how things work, not descriptions of the problems, not questions about what we’ll do with the generated code in six months nothing.

But unlike any other hype, this one is special. It infects the minds of even the smartest among us. Many CTOs, tech leads, and team leads, despite being engineers just yesterday, can no longer be cured of this affliction. And it’s understandable. On one hand, they’re under pressure from higher management. On the other hand, LLMs generate code that looks awfully convincing.

A Bit of Theory

Many refer to this article, and I’m no exception. The article by Peter Naur, Programming as Theory Building.

In it, the author argues that a significant part of development involves building a theory in your head. A theory about how the various components of the system are interconnected, how the constructed model reflects the business processes embedded in it, how flexible the current model is, various tradeoffs, and so on.

And all of this exists in the developers’ heads. Some of it can be captured in documentation, specs, and comments, but one way or another, when new developers join the project, they need to build this entire theory in their heads from scratch. And this takes a tremendous amount of time, including communication time with colleagues.

Documentation is good, but it isn’t always accurate. The pace of development can outpace the speed of writing documentation. Some might say that LLMs can help write documentation. But an LLM won’t write in the documentation why a particular class was implemented in a certain way and how it affected neighboring classes, even though this might be critically important for future feature development. Nobody checks what the LLM writes there.

And if we abstract further, we could even move to the most formal language of all mathematics. Differential equations or Field Theory were written down long ago and in great detail.

First, did that allow anyone to apply them in practice, solving problems without building those theories in their own heads?

Second, how many people have you seen who interpret differential equations in exactly the same way?

And that’s the most formal language possible. What about applied matters and business logic? Therefore, even with detailed documentation and quality code, a person will need a certain amount of time to understand the essence of the project.

At the end of the article, you can find some scientific research on this topic.

Questions About the Current State of LLMs

We all see and feel the intense marketing pressure from LLMs and AI tools in general. However, let’s step away from the news about “the new x.yz version of the ABC network, which is e^100000 times better than all previous versions combined” and look at the impact of LLMs on development from a different angle.

For several years now, we’ve been assured that soon there will be no work left for developers. That is, LLMs will do everything for us. But what’s happening to the products, to the tooling, to programming languages? If LLMs are really doing the heavy lifting now, this should already show up in the tools we use every day. So look at the record so far:

Have some faster, more reliable databases appeared, written by LLMs?

Has everything been rewritten in Rust, eliminating problems with Electron-based apps that consume tons of memory?

Have IDEs stopped lagging during simple typing?

Has Wayland been finalized and all problems resolved?

Has CPython seen significant optimizations via LLMs and caught up with compiled languages in speed?

What about the browser from Anthropic?

And what about Bun—does it not crash in production anymore?

So, the question is: where are the tons of products? When will every developer become an entrepreneur?

Yes, we hear about individual successes of small vibe projects, but these are often either small projects generating income at the level of a middle/senior programmer, or even less, or… very isolated cases that would need a thorough verification. And what’s new and interesting in open source? For 2025/2026, GitHub hasn’t been very abundant in this regard.

Real Bottlenecks

Somehow, without any prior announcement, everyone suddenly decided that the biggest bottleneck in development is writing code. It’s not clear what research this claim is based on and it isn’t new. Vim users who could touch-type at 120 words a minute never turned typing speed into the industry’s competitive edge, because typing was never the bottleneck to begin with.

What customers forget/don’t understand/don’t want to see:

• Program/service design—from classes and methods to system design of the entire product.

• Communication with product managers, designers, analysts, and colleagues.

• Finding solutions.

• QA of the written code. Yes, developers also spend time testing before handing it over to testers.

• Documentation, problem-solving, thinking through and anticipating various events that could affect the service’s load and its behavior in exceptional cases.

All of this takes a massive amount of time. No, LLMs don’t do this, or they don’t do it very well.

Just run a thought experiment. Suppose it’s not an LLM doing all this, but a personal senior-level slave. Despite some successes, the responsibility lies with the hired developer. And to maintain that responsibility, they need to be convinced of the correctness of the decisions. Transferring that into their own head will still require a significant amount of time.

Arguments of AI Adherents

1. “Imagine you have a team of 10 mid-level/senior developers. Well, agents are the same thing.”

No, it’s not the same thing. I have about 2.5 years of experience as a team lead. Not a huge amount, but it’s not hard for me to draw conclusions and spot the differences:

• Responsibility. A team does indeed take responsibility for its work. Each team member is motivated (by salary) and demotivated (by potential penalties or dismissal). And in real life, by mortgages, loans, needs, etc. Their motivation and demotivation obligate them to bear this responsibility.

• Predictability. From the first point follows predictability. Each team member becomes predictable after some time (roughly the probationary period). The team lead understands their technical level, development speed, degree of involvement in development, and a bunch of other characteristics. It’s not in any team member’s interest to be unpredictable. A colleague won’t cave and say “you’re right, here’s the fix” ten times an hour just to get the ticket closed — there’s a reputation and a paycheck riding on being right. An LLM has none of that. It’s unpredictable and deeply chaotic: it forgets context, repeats the same mistakes, and doesn’t know how to back off.

2. “Everyone uses them, and we absolutely must use them too.”

This is classic cargo cult thinking; arguments won’t save you. BUT. Please. Let’s at least try to ask a few more questions before dragging something new into our workflow.

3. “But LLMs speed up development. Who cares what happens to the project/service in 3-6-9 months? Everyone’s happy and satisfied right now.”

No, I’m not satisfied. It’s painful to review merge requests with thousands of lines in the diff. It’s painful that there are no people left who understand the code. And, most importantly, the fun is gone. What pleasure is there in generating code? When writing code by hand, I at least get some dopamine (fighting off tons of cortisol I got as a junior/mid).

Tons of code that nobody understands directly impact the business and the product. The maintainability curve, while remaining flat for a while, eventually skyrockets. And then feature releases get delayed more and more. Bugs appear more often, and nobody knows how to fix them. A normal, healthy business also needs predictability from the project and development, just like water.

Edge Cases

This is trickier. What I’d include here: the LLM writes the code, but the developer more or less reviews their own code. To objections about the increased number of lines in merge requests and frequent rewrites of the same code sections, they reply, “Just glance over the MR diagonally,” “This module isn’t that critical,” etc.

In my opinion, this is still a risky case for the product. Maybe it’s acceptable for services that are meant to be written once and forgotten, but nothing more. The likelihood of errors increases, and the point of code review evaporates. Responsibility can start to blur. You might start hearing things like “The LLM introduced this bug,” “The LLM messed up the config,” etc.

I believe that responsibility should always lie with the developer. In the case of problems coming from other tools, be it CI/CD, infrastructure components, or even the code editor—such an argument is valid. We trust colleagues, the project’s lifespan, maintainers, companies, etc., and we understand that no software is without issues. However, we continue to trust up to a certain critical point. That critical point might simply be that the tool isn’t suitable for the specific load of the current product. But we still have feedback from real people that the tool works in other cases.

But with LLM generation, we cannot afford that—we have no tools to assess the risks and the likelihood of problematic code. And I believe that any blurring of responsibility in this case leads to risks and problems—both in terms of the developer’s understanding of the product and overall trust in the developer.

Conclusions

LLMs are not stable. There are no tools to determine/increase/work with the level of trust in an LLM. We observed this a year ago with Test-Driven AI Development, which I don’t want to comment on or investigate because it evaporated as a concept. Today we have SPEC-Driven Development, which I don’t hold out much hope for because, again, I don’t see every developer becoming an entrepreneur, and I don’t see an influx of quality projects in open source.

When using LLMs as generators for the main codebase, both the level of trust in the developer and the developer’s own understanding of the codebase, the problems, and the product are lost. This negatively impacts cognitive load and can increase the likelihood of burnout. There are considerable risks associated with using them on long-term projects.

I’ll just repeat the phrase from the article: let’s at least try to ask a few more questions before dragging something new into development.

These numbers carry weight because they didn’t come from a critic. They came from a firm that wants to package WLD into an exchange-traded fund, list it on Nasdaq under the ticker GWLD, and sell shares to retail investors. The application was filed on July 20.

The risk factors section states it plainly: the 100 largest WLD wallets hold about 90% of tokens in circulation. One of those wallets is the bridge between Ethereum and World Chain, which likely serves many users at once but that detail doesn’t change the concentration picture.

This cuts against Altman’s own promises. Back in October 2021, he wrote that Worldcoin would be “fairly distributed to as many people as possible.” The project’s white paper went further, predicting that “most of the currently living people” would hold WLD tokens, making it the most widely distributed digital currency on record. In the actual filing, Grayscale’s lawyers had to work with facts instead of marketing: a large share of the tokens issued ended up with a small group of early participants.

WLD is billed as a governance token, but in practice that function barely gets used. Per the filing, WLD “may be used in the future” for governing the World Network, though the mechanisms for that shift are described as “novel and untested at scale.” Right now, governance “remains largely conducted under the direction of the World Foundation.”

The filing also lays out how much the project leans on centralized infrastructure. The World Chain sequencer runs centrally, and the network sits at an “early stage of decentralization” behind even Ethereum on that count. Protocol updates fall under the “coordinated control of a limited number of participants” tied to the World Foundation, Tools for Humanity (Worldcoin’s developer), and Optimism (operator of the L2 chain running the project’s smart contracts).

That, too, cuts against earlier statements. When World Chain launched in April 2024, the project’s founders said the network would be “built by all of humanity, owned by it, and governed by it.” In May 2025, the World Foundation promised the “final stages” of full decentralization by the end of 2026. It’s July 2026 now, and the project is behind that timeline.

Even the Orb devices the hardware behind the entire iris-scan identity system — are produced and distributed mainly under Tools for Humanity’s control, while the World Foundation holds significant sway over the protocol, the WLD treasury, and ecosystem grant distribution.

At publication, WLD was trading around $0.40 down 20% year-to-date and 96% below its all-time high of $11.74, set in March 2024.

The technical work is solid. The attribution chain is credible. We verified what we could verify, cross-referenced what we could cross-reference, and consulted sources beyond what appears in English-language reporting.

The evidence points where it points.

But before we get to the name and we will get to the name, or rather to the question of what you do with it there are a few things worth examining that the published reporting passed over quietly.

What the cultural markers actually tell us

The email address that Intel 471 traced back to the Hastalamuerte persona contains the number combination 1488. The reporting notes, correctly, that 1488 is associated with white supremacist ideology. What the reporting does not examine is whether that association is meaningful in context.

1488 as a coded white supremacist identifier is primarily an American and Western European neo-Nazi reference. It exists in Russian far-right spaces but it is not organic to Izhevsk — an industrial city in Udmurtia, a predominantly Muslim republic within Russia, where the dominant cultural backdrop is Russian Orthodox, not American extremist subculture.

Three explanations exist. Someone adopted American extremist iconography deliberately as part of a constructed persona. Someone borrowed an identifier without understanding its Western connotation in Russian internet culture, numbers are frequently combined in usernames without ideological intent. Or the number is genuinely meaningful to this individual for reasons that don’t appear in the public record.

All three are possible. None of the published reporting asked which one.

Similarly, the GitHub username SantaMuerte and the forum handle SantaMuerte on Codeby form part of the attribution chain. Santa Muerte — Nuestra Señora de la Santa Muerte — is a Mexican folk Catholic saint, a personification of death associated with healing and protection. The devotion is specifically Mexican and Mexican-American in origin. It does not travel naturally to Russian Orthodox Izhevsk any more than 1488 does in the other direction.

Again borrowed persona, deliberate misdirection, or genuine adoption of foreign symbolism by someone whose online identity was assembled from whatever seemed appropriately threatening in 2019? Possible. Documented. Unexamined.

We raise these questions not to exonerate anyone or to undermine the attribution chain. The chain holds together. We raise them because our job is to ask the next question, not just confirm the last answer.

Who these people actually are

The published reporting includes something important that tends to get buried under the technical detail. A review of Hastalamuerte’s early forum posts from 2019 to 2020 shows a relatively unskilled user still trying to establish a reputation. In June 2020 the account joined a months-long Telegram training program to learn basic penetration testing tools. The posts show someone struggling with fundamentals.

This is not a supervillain origin story. This is a pattern that repeats across nearly every significant threat actor we have studied.

Most people who end up operating at this level did not plan to become ransomware administrators. They were technically curious, found communities that rewarded their skills, discovered that those skills had financial value, and gradually moved further in than they initially intended. The escalation is incremental. The point of no return is rarely visible when you cross it.

The Russian government dimension matters here but not in the way it usually gets framed in Western reporting. The tolerance of outbound cybercriminal activity — the unwritten rule that domestic targets are off limits, that the right people occasionally get paid, that foreign law enforcement jurisdiction stops at the border — does not produce hardened master criminals. It produces people who feel protected enough to be careless. OPSEC mistakes that would end careers elsewhere become survivable. Which means they persist, they learn, and they leave traces that a more pressured operator would have eliminated years earlier.

That carelessness is documented. It is also, from an investigative standpoint, useful.

The motivation is money. Not ideology, not geopolitics, not a desire to destabilize Western infrastructure as an end in itself. The 90% affiliate split that distinguished The Gentlemen from every competing program is not a philosophical statement. It is a market strategy. Experienced operators have options. Higher margins attract better talent. Better talent produces faster scale.

Understanding that the motivation is financial and the behavior is therefore predictable is more operationally useful than knowing a name.

The question nobody answered

Multiple respected intelligence firms have published what they believe to be the real identity of The Gentlemen’s administrator. The evidence chain runs from forum handles through Telegram IDs through phone numbers through data breach records to a named individual with a LinkedIn profile and an employer in Izhevsk.

We reviewed that chain. We conducted our own verification across sources that include Russian-language forums, Telegram channels, and data that does not appear in English-language reporting. The convergence is real. Multiple independent methodologies pointing in the same direction is as close to confirmation as open-source attribution gets.

And then the reporting ends. A name. An employer. A phone number. No response to requests for comment.

Now what?

Here is Vorexig’s position, stated plainly.

We find. We report. We do not make arrests and we do not publish private citizens’ identifying information ahead of law enforcement action. Not because we lack confidence in the evidence. Because a name in a Substack post does not put anyone in handcuffs. It does not protect a single organization from the next attack. It does not disrupt infrastructure, seize cryptocurrency, or trigger extradition proceedings.

What it does is create legal exposure for the publisher, alert the subject, and give them time to move.

If you have evidence strong enough to name someone publicly, you have evidence strong enough to hand to the FBI, Interpol, or the relevant national cybercrime authority first. That is not being a snitch. That is understanding what your evidence is actually for.

Crime does not pay eventually. The historical record of ransomware operators who felt protected by geography and government tolerance and then made the mistake of traveling abroad is instructive. Arrests happen. They just happen on a timeline that does not align with the news cycle.

What you should actually do with this information

If you are reading this as a security practitioner, the actionable insight is not the name. It is the infrastructure.

The Gentlemen maintain a pre-compromised inventory of approximately 14,700 FortiGate devices exploited through CVE-2024-55591. Your organization does not need to do anything wrong today to already be on that list. The breach may have occurred months ago. The encryption has not started yet.

The group targets organizations where the return justifies the effort. They are not ideologically motivated. They are economically motivated. Which means the most effective defensive posture is not impenetrability — it is making your network more expensive to attack than the organization beside you.

Patch your edge devices. Audit your FortiGate exposure. Understand what your acquisition target’s network perimeter looked like eighteen months ago, not just today.

If you are in M&A and a significant portion of Vorexig’s audience is the question to ask before a transaction closes is not whether the target company has been attacked. It is whether they are currently on a list that someone is working through methodically.

We can help you find out.

A final note

The Gentlemen will not be the last group built this way. The conditions that produced them accumulated expertise inside established programs, a payment dispute, a calculated departure with tools and access intact are structural, not exceptional. As the ransomware market consolidates around fewer dominant operators, the experienced affiliates who leave or get pushed out will build competing operations. Some will fail. Some will move faster than any group before them.

The barriers to entry are lower than most organizations assume. The people behind these operations are more human and more fallible than the technical reporting suggests. And the name, when it eventually becomes public through proper channels, will matter less than what you did with your network while you were waiting.

We find. We report. We keep companies safe including the ones that have not invested in cyber yet.

That is the job.

I don’t really care about that argument. I care about how the data got out, because that’s the part nobody outside the OSINT and infosec world is actually talking about and it’s the part that should worry these people far more than which sessions made the agenda.

What actually happened

Strip away the conspiracy framing and here’s the technical reality. Swiss researcher Maia Arson Crimew the same person who previously surfaced the U.S. government’s No Fly List and breached the surveillance camera company Verkada got an anonymous tip and found a directory of 113 names tied to Dialog sitting embedded directly in the source code of the organization’s own website. Not behind a login. Not in a database that required a breach. The directory had been sitting in plain sight, served to anyone who simply viewed the page’s source.

That’s not a hack. That’s a “right-click, View Page Source” discovery. I want to sit with that for a second, because it’s the entire story.

Separately, Dialog’s participant records live in Airtable a commercial, off-the-shelf database and for each person it tracks membership status, every retreat they’ve attended, a biography, a home city, and a private access token that functions as a login credential. A source gave Wired the full 2026 registration list separately, which is how the broader 222-name roster for the August retreat surfaced. WIRED chose not to publish the tokens or the personalized account links that contained them, which tells you those tokens were live and functional, not some sanitized export.

So you’ve got a 20-year-old organization, run by people who built some of the most consequential surveillance, data brokerage, and identity infrastructure on the planet, whose own membership directory was exposed the same way a junior dev’s side project gets exposed: hardcoded into client-facing HTML and parked in a SaaS tool with default-ish access controls. Crimew’s quote on this is the one worth remembering, not the session titles: it shows how confident the people who run the world are in their own safety, since they don’t bother with basic operational security even for the off-the-record gatherings where they discuss the world’s future.

That’s the headline. Everything else is color.

Why this matters more than the gossip

I spend my working life on the other side of this exact failure mode. When I’m tracing a fraud network or doing diligence on a counterparty, the breakthrough almost never comes from some exotic zero-day or a dark web breach dump. It comes from exactly this: someone treated a low-friction tool — a shared spreadsheet, a forum profile, a website’s own source code as private, when it was never actually locked down. People conflate “obscure” with “secure.” Dialog has no public-facing site, no published member list, two decades of media silence. That obscurity bred a false sense of security, and false security is precisely where OPSEC discipline goes to die.

The irony, and it’s a real one, is who’s on the list. This isn’t a retreat of marketing executives. Howie Liu, the founder and CEO of Airtable itself, is a listed participant — the same Airtable that hosted the unsecured records. The roster includes people who built or run the largest data brokerage, ad-tech, and surveillance companies in the country, gathering specifically to discuss, among other things, the future of AI-driven information control, and their own membership records were sitting in a tool with the access discipline of a fantasy football league.

If you only take one lesson from this story for your own organization, take this one: your threat model has to account for low-effort, high-embarrassment exposure, not just sophisticated attackers. Nobody breached Dialog’s infrastructure with anything resembling skill. Somebody looked.

The part that should worry the attendees more than the press coverage

The leaked records include personal email addresses, mobile phone numbers, birthdates, and emergency contacts for the people on the list — for sitting senators, a NATO commander, a Treasury Secretary, and assorted billionaires. That’s not reputational risk. That’s a physical security and targeting risk. Emergency contact information for a sitting general or cabinet official, tied to a home city and a verified attendance history at private events, is exactly the kind of dataset that turns into a social engineering or physical security problem in someone else’s hands. None of them appear to have used government email addresses to register, which tells you the attendees themselves understood there was something worth keeping separate from their official lives — they just didn’t extend that same instinct to the platform holding their personal data.

This is the gap I see constantly in this work: people are good at compartmentalizing what they say. They’re bad at compartmentalizing the infrastructure that holds what they say. Dialog reportedly went to the trouble of building a private, members-only dating feature inside its participant directory, including whether someone was looking for love at Dialog events — a level of granular personal detail most people wouldn’t hand to a stranger at a bar, sitting in the same unsecured system as phone numbers and birthdates for a four-star general.

What I’d tell a client in this position

If you ran an organization like this and frankly, if you run any organization that maintains a membership list, a donor list, an investor list, or a client roster with personal contact data attached here’s the unglamorous checklist that this leak should put back on your radar:

Audit what’s actually rendered in your site’s client-side source, not just what’s behind authentication. Browsers render everything sent to them; “not linked from the navigation” is not the same as “not exposed.” Crimew didn’t break anything. She viewed source.

Treat third-party SaaS tools Airtable, Notion, Google Sheets, anything with a shareable link as a primary attack surface, not a convenience layer. These tools are popular precisely because they’re frictionless, and frictionless almost always means permissive defaults somewhere.

Separate identity data from preference data. A membership directory with names and bios is one risk tier. A membership directory with phone numbers, birthdates, emergency contacts, and dating preferences attached to the same record is a completely different risk tier, and it should never live in the same table, let alone the same access scope.

Rotate and scope access tokens like you mean it. The fact that Dialog’s tokens functioned as standing login credentials, embedded in personalized links, means a leaked link wasn’t just exposure it was account takeover waiting to happen.

None of this requires a six-figure security budget. It requires someone in the organization whose job is to ask “what does our public-facing footprint actually expose,” and to keep asking it as the org grows. Dialog is reportedly building a permanent campus and scaling its membership. Growth without a parallel growth in data discipline is how you end up the subject of a Wired story instead of the host of one.

The bigger picture

I’ll leave the “is this a secret society shaping world events” debate to the political commentators that’s a worthwhile conversation, but it’s not mine to adjudicate here. What I’ll say as someone who does this kind of digging for a living is that this leak is a near-perfect case study in why “we’re private, not public” is not a security posture. It’s a hope. Dialog had twenty years of media discipline and zero years of basic web hygiene, and the web hygiene is what got them.

The people in that room are going to spend a week in August discussing how to survive World War III and whether money buys happiness. I’d suggest they spend twenty minutes first on whether their own vendor stack can survive someone hitting Ctrl+U.

A few months ago, I was reviewing a due diligence file on a crypto payments company. Mid-stack acquisition, reasonable valuation, clean cap table on the surface. Then I started pulling transaction graph data.

The patterns were textbook. Privacy coin layering. Repeated conversion cycles through non-KYC (Know Your Customer) exchanges. Intermediate wallets with a single inbound and single outbound transaction each classic peeling chain behavior. The kind of thing that shows up in every blockchain analytics training course as an example of what not to do.

The founders weren’t criminals. I’m fairly confident of that. They’d built tools for privacy-conscious users in high-surveillance environments journalists, activists, people sending remittances across sanction boundaries. Legitimate use cases, real demand. But nobody had explained to them that the techniques their users employed to stay safe were also the techniques that would make their entire business look like a money laundering operation to any competent analyst, regulator, or acquirer’s legal team.

The deal died in diligence.

What the “invisible” path actually looks like

Here’s the general shape of what privacy-seeking crypto users do stripped of the specific tools and step-by-step detail that would make this a how-to guide, which it isn’t:

They start with fiat currency, typically acquired through a peer-to-peer exchange or crypto ATM that requires minimal identity verification. They move those funds into a non-custodial wallet one they control with a seed phrase and then convert to a privacy-focused cryptocurrency like Monero (XMR) or shielded Zcash (ZEC). These coins obscure transaction history by design: Monero hides sender, receiver, and amount on every transaction by default; Zcash offers optional shielded pools that do the same.

From there, they convert back to a stablecoin or spendable asset through an automated exchange typically one that doesn’t require identity documents and load a virtual card that accepts crypto funding. That card gets used like a normal payment card: VPS hosting, cloud services, software subscriptions, anything that accepts Visa or Mastercard.

The result, from the user’s perspective, is a payment with no clear link back to their identity.

From my perspective and from the perspective of Chainalysis, TRM Labs, CipherTrace, and every AML compliance team at every major financial institution — it’s a recognizable pattern with a signature.

Why the signature matters

Privacy coins don’t actually make transactions invisible to investigators. What they do is shift the analytical burden. Instead of reading a transparent ledger, you’re looking at behavioral patterns around the privacy coin: what went in, what came out, timing correlations, exchange footprints, IP metadata where it’s available, and the transaction graph on either side of the shielded segment.

Monero’s ring signatures obscure which input is the real one, but they don’t eliminate the inputs. Zcash’s shielded pool is genuinely strong but most Zcash transactions still involve transparent addresses at some point, and the transition into and out of the shielded pool leaves artifacts.

More importantly: the behavior of using these tools is itself a signal. Per the EU’s Anti-Money Laundering Regulation (EU AMLR), which takes full effect in July 2027, Virtual Asset Service Providers will be required to screen for privacy coin usage as a risk indicator. Transactions routed through non-KYC exchanges, peeling chain patterns, and repeated conversion cycles are already flagged by blockchain analytics platforms as elevated risk.

This doesn’t mean everyone who uses these tools is laundering money. It means that if your business touches crypto as a payments company, an exchange, a service provider accepting crypto your customers’ behavior becomes your compliance exposure.

The acquisition problem

Back to that due diligence file.

The company’s transaction volume looked fine in aggregate. The problem was the composition. A significant portion of user activity showed privacy-enhanced routing patterns not because the users were criminals, but because the product had been designed and marketed to people who needed privacy. The founders understood their users’ threat models. They hadn’t thought about their acquirer’s compliance team’s threat model.

When you’re building in crypto, you’re not just building a product. You’re building a transaction history that will be analyzed if you ever raise a meaningful round, get acquired, face a regulatory inquiry, or have a correspondent banking relationship reviewed. That history doesn’t disappear. Blockchain is permanent.

The techniques that make your users feel safe can make your business unsellable.

What you should actually do

If you’re moving into crypto — building a product, accepting payments, launching a fund, structuring a deal involving digital assets here’s what I’d tell you directly:

Get a blockchain analytics review before your counterparties do. Know what your transaction graph looks like. Know what patterns are present in your user base. Know what a competent AML analyst will find before they find it.

Understand the regulatory timeline. The EU AMLR July 2027 deadline isn’t far away. Financial institutions are already adjusting their screening criteria in anticipation. Privacy coin exposure, non-KYC exchange routing, and mixer-adjacent behavior are moving from “elevated risk” to “presumptive noncompliance” in many institutional frameworks.

Get legal counsel that understands this space. Not general corporate counsel. Counsel with specific experience in FinCEN, FATF frameworks, OFAC, and blockchain-specific AML. The intersection of crypto and financial regulation is technical enough that generalist advice isn’t sufficient.

(Shameless plug: this is exactly the kind of pre-transaction risk picture that Vorex Intelligence Group builds for M&A teams, PE funds, and legal practitioners. If you’re evaluating a crypto-adjacent company or preparing your own for acquisition, the time to understand your transaction graph is before the term sheet, not after.)

The actual lesson

The tools that allow someone in Tehran or Moscow to pay for a VPS without their government knowing are real, they work reasonably well, and people have legitimate reasons to use them. I’m not here to judge that.

What I am here to tell you is that those same tools, used at scale, by a user base you’re building a business around, produce a transaction signature that looks from the outside like the operational security hygiene of a money laundering operation. The techniques are identical. The intent is different. The blockchain doesn’t record intent.

If you’re building in this space, that’s the problem you need to solve. Not with better privacy tools. With better compliance architecture, better legal structure, and a clear-eyed understanding of what your transaction history actually looks like.

The privacy seekers have a threat model. You need one too.

Vorex Intelligence Group provides AI-enhanced OSINT investigation services to M&A teams, legal practitioners, private equity funds, and corporate security practices. All investigations rely exclusively on publicly available information and documented methodology, per our published Research Ethics and Methodology Policy.

But I recently finished a research engagement for a client that sent me deep into a corner of the threat landscape I had not spent much time in: medical devices. What I found was not theoretical. It was not a projected risk or a worst-case scenario. It was a documented, quantified, reproducible gap that sits inside virtually every hospital network in the country and by extension, inside every healthcare acquisition that does not specifically look for it.

I want to walk you through what I found, why it matters to M&A and PE teams specifically, and what questions you should be asking before you close on a healthcare target.

What the Research Showed

Unit 42 (Palo Alto Networks) analyzed 200,000 infusion pumps across hospital networks. Seventy-five percent contained at least one known vulnerability. Fifty-two percent were susceptible to two specific CVEs with a CVSS score of 9.8 — the top of the Critical scale. Those vulnerabilities were disclosed in 2019. Six years ago.

CVSS 9.8 means: attackable over the network, no privileges required, no user interaction required, full impact on confidentiality, integrity, and availability. That is as bad as it gets on the scoring scale.

Infusion pumps account for approximately 38% of all connected medical devices in a typical hospital. The picture with other categories MRI machines, CT scanners, patient monitors, imaging systems is not better.

This is not a niche finding. This is the baseline condition of most hospital networks right now.

Why This Is an M&A Problem, Not Just a Security Problem

When I think about this through the lens of a deal, three categories of exposure stand out.

Regulatory liability that does not appear in financial statements

Medical devices in the United States operate under FDA oversight. The FDA has been increasing pressure on manufacturers to implement Software Bills of Materials (SBOMs) registries of every software component inside a device, including third-party libraries and their version numbers. Many devices currently in hospital networks predate those requirements entirely.

Here is what that means in practice: a hospital may be running devices with known critical vulnerabilities that cannot be patched, ever, because patching firmware on an FDA-cleared device requires recertification. The manufacturer may no longer support the device. The hospital may have no path to remediation short of full device replacement.

That is a capital expenditure liability. It does not show up in the income statement. It will not appear in a standard financial audit. It requires a technical assessment to find and most healthcare due diligence processes do not include one.

Data breach exposure with a long discovery window

The protocols that medical devices use to communicate were not designed with security in mind. DICOM the standard for transmitting medical images between devices and storage systems requires no authentication by design. Any device on the same network can query a DICOM server and retrieve patient images and associated data. HL7, the protocol carrying lab results, prescriptions, and patient records between systems, transmits in cleartext.

In a flat hospital network meaning no segmentation between device categories and administrative systems an attacker who gains access to one device can move laterally to patient records, billing systems, and administrative infrastructure. That lateral movement is often trivial because the network was never designed to prevent it.

Per Industrialcyber, incidents involving penetration into medical facility networks through equipment increased 42% in the first nine months of 2025.

A healthcare target that has experienced a breach originating through a medical device may not know it. These networks frequently lack the monitoring tools that would detect such movement. Standard endpoint detection and response agents cannot be installed on devices running embedded operating systems. Security information and event management platforms do not parse DICOM or HL7 traffic by default. The blind spots are structural.

The discovery window for this class of breach is long. A PMC/OCDS study covering 92 million procurement records across 36 countries found an average exposure window of 3.2 years from device purchase to CVE publication meaning devices operate for years with vulnerabilities no one has catalogued yet. Even after a CVE is published, devices routinely remain unpatched for the remainder of their operational lifecycle, which runs eight to ten years in medical environments.

Valuation risk from deferred remediation

Device lifecycles in healthcare run eight to ten years. Replacement cycles are driven by clinical function, not security posture. A hospital acquiring a new imaging system does not retire the old one because it runs a vulnerable operating system — it retires it when the clinical upgrade justifies the capital cost.

That means the installed base of vulnerable devices in a target company’s network is not a problem with a near-term solution. It is a cost that will be carried forward. Network segmentation isolating medical devices into separate network zones with strict access controls is the primary remediation path that does not require device replacement. It is also an infrastructure project with real cost, real timeline, and real operational disruption during implementation.

For a PE fund modeling a healthcare acquisition, the question is not whether vulnerabilities exist. Per the Unit 42 data, they almost certainly do. The question is: what is the cost to bring the network to a defensible posture, and who is carrying that cost in the deal structure?

What the Vulnerabilities Actually Look Like

I want to be specific here, because the abstract version of this risk is easy to dismiss. The concrete version is harder to set aside.

The two CVEs affecting 52% of the pumps in the Unit 42 study include CVE-2019-12255, a buffer overflow in the VxWorks TCP/IP stack the operating system layer running on a large share of embedded medical devices. CVSS 9.8. Network-accessible. No authentication required. EPSS score of 0.80, placing it in the top 1% of vulnerabilities by exploitation probability. A public exploit exists. The vulnerability was published in 2019. Devices running VxWorks are still operating in hospital networks without patches, because patching requires firmware recertification, and recertification requires manufacturer support that may not exist.

A separate vulnerability class CVE-2020-12040, affecting Baxter Sigma Spectrum infusion pumps involves cleartext transmission of all status and operational data between the pump and its drug library server. An attacker on the same network segment can intercept that communication and, from that position, manipulate transmitted data. On an infusion pump, transmitted data includes dosage parameters.

I am going to stop there and not editorialize further on that particular implication. The risk is self-evident.

Physical access to devices yields an additional vulnerability class. BD Alaris infusion pumps models covered under CVE-2016-9355 and CVE-2016-8375 — store wireless network credentials in unencrypted flash memory, accessible to anyone who opens the casing. Security researchers, including Billy Rios, one of the leading figures in medical device security, have demonstrated this by purchasing decommissioned devices on eBay and extracting credentials from them in a lab. Decommissioned devices from your acquisition target may be on the secondary market right now.

The Network Architecture Problem

Individual device vulnerabilities are one issue. The network architecture that connects them is a separate and in some ways larger issue.

Most hospital networks were built for clinical function, not security segmentation. Infusion pumps, imaging systems, physician workstations, billing systems, and administrative infrastructure often share the same network segments. The protocols in use DICOM, HL7 were designed in an era when the network perimeter was the security boundary, and the assumption was that anything inside the hospital was trusted.

That assumption has not been valid for years. Guest Wi-Fi, vendor remote access, compromised contractor credentials, and supply chain attacks have all been used to gain initial access to hospital networks. Once inside a flat network, lateral movement to clinical systems is often a matter of minutes.

The monitoring tools that would detect this movement do not work on most medical devices. Endpoint detection agents are incompatible with embedded operating systems. Network traffic analysis tools are not configured to parse medical protocols. The devices generate no logs that a SIEM can ingest.

In practice, this means a hospital network can sustain an active intrusion that touches clinical systems without any alert being generated. The intrusion becomes visible only when it reaches systems that do have monitoring billing, administration, EHR platforms or when ransomware is deployed and clinical operations are disrupted.

What to Ask Before You Close

Based on my research, I would add the following to any healthcare due diligence process:

Device inventory with CVE mapping: Request a complete inventory of networked medical devices including make, model, firmware version, and operating system. Map that inventory against published CVEs. If the target cannot produce this inventory, the absence is itself a finding — you cannot manage risk you cannot see.

Network architecture documentation: Request network diagrams showing segmentation between medical device VLANs and administrative systems. Ask specifically whether DICOM and HL7 traffic is restricted to authorized network paths, or whether those protocols are permitted broadly.

Patch and update history: For each device category, ask what the manufacturer’s current support status is, whether firmware updates are available and applied, and what the remediation path is for devices that cannot be patched. Understand the delta between current firmware and the latest available release.

Incident history: Ask specifically about incidents involving medical devices, not just IT systems. Ask whether the hospital has experienced unexplained network anomalies, device communication failures, or performance degradation that was not traced to a clinical cause. These are potential indicators of compromise that may not have been investigated as security events.

Remediation cost estimate: If the assessment surfaces significant vulnerabilities, request an independent estimate of the cost to implement network segmentation across the affected device population. This is a capital cost that belongs in your model.

Vendor agreements and support contracts: Review manufacturer support agreements for end-of-life devices. Understand which devices are operating beyond manufacturer support windows and what the contractual path to remediation looks like.

The Framing I Keep Coming Back To

I said at the start that I do not write scare pieces. That is still true. The framing I keep coming back to is a simpler one: there are costs in this acquisition that are not in the data room, and the technical assessment required to find them is not standard in most healthcare deals.

The vulnerabilities are catalogued. The exploitation paths are documented. The monitoring gaps are structural. None of this is speculation it is the current condition of most hospital networks, confirmed by independent research across hundreds of thousands of devices.

The question for M&A teams is not whether the risk exists. It almost certainly does. The question is who is pricing it and whether that pricing is showing up in the deal structure before closing or in remediation costs after.

In my experience, deals that answer that question before closing are better deals.

The key witness that ultimately condemns them is an unassuming file: NTUSER.DAT.

When I pull it from a system image, I’m not looking at artifacts in isolation. I’m building a timeline.

Consider a scenario I’ve worked through more than once. RecentDocs tells me a file called “Q3_customer_export.xlsx” was opened at 11:47 PM on a Tuesday. UserAssist confirms that WinRAR launched at 11:52 PM the same evening. TypedPaths shows a network path to an external USB-mapped drive typed into the Explorer address bar at 11:58 PM.

No single artifact makes the case. All three together tell a story that’s very hard to explain away.

This is what I mean by behavioral reconstruction. The Windows registry doesn’t record intent but it records action, sequence, and timing. In an insider investigation, that sequence is often more persuasive than any single piece of evidence.

The Key Witnesses Hiding in Plain Sight

NTUSER.DAT is the Windows registry hive for an individual user. When a departing employee clears their browser history and deletes files before handing in their laptop, they think they’ve done the job. But NTUSER.DAT is, without exaggeration, a treasure trove of behavioral artifacts.

Here are the key witnesses I look for:

• TypedPaths — Stores paths the user manually typed into Explorer’s address bar. Want to jump quickly to a hidden network folder called “Reports_for_competitors”? The entry stays, even if the folder is no longer mapped.

• RecentDocs & OfficeMRU — Shows which documents were opened and edited in Word or Excel, complete with timestamps and full paths. The employee can delete the file. The record of opening it does not go with it.

• WordWheelQuery — This one is a particular problem for insiders. These are the search queries typed into the Windows search bar. When an employee searches for “master_salary_table” or “customer_db_dump” and later claims they accidentally clicked the wrong shortcut, this artifact does an excellent job of demonstrating intent.

• UserAssist & RunMRU — Shows which GUI applications were actually used and how many times, plus commands executed from the Run dialog. If someone launched a file transfer utility at midnight, this is where that shows up.

• ShellBags — Remembers that folders were opened and how they were viewed, even if the folders themselves are later deleted. The folder is gone. The fact that someone opened it is not.

• RDP Connection History — Shows whether the user connected to other machines on the network. Lateral movement in an insider case often starts here.

These records are tied to a specific user account and live far longer than browser history. Cleaning them through normal means is nearly impossible. You’d need to know exactly where to dig in the registry, and the average office employee has no idea these places exist.

The Toolkit

Two tools I reach for consistently when working with NTUSER.DAT:

• Registry Explorer (Eric Zimmermann) — My first stop. It parses the hive cleanly, handles transaction logs, and makes artifact hunting fast. It also handles the ROT-13 encoding that Windows applies to program names in UserAssist automatically, which saves time.

• ShellBagsExplorer (also Zimmermann) — Renders ShellBags into a readable folder timeline that I can drop directly into an evidence appendix. Clear, defensible, exportable.

Both tools are free. Both are industry standard. If your forensic vendor is not using them on insider threat cases, that is worth asking about.

The Rules of Engagement

I want to be direct about something: collecting and analyzing NTUSER.DAT in a professional context requires proper authorization before anyone touches a single file.

At Vorex Intelligence Group, every investigation operates under a documented engagement letter. Per our published Research Ethics & Methodology Policy, we conduct passive analysis of authorized data only no unauthorized access, no overreach. In an employment context, that means working under a documented incident response charter with HR, Legal, and IT aligned before the investigation begins.

If you are an attorney managing e-discovery for a departing employee case, this is exactly the kind of artifact your forensic vendor should be pulling. If they are not, ask why.

The Gap

The departed employee who cleared their Chrome history and emptied the Recycle Bin did not cover their tracks. They covered the tracks they knew about.

NTUSER.DAT records the ones they didn’t.

That gap between what a non-specialist thinks to erase and what is actually preserved is the core of what makes registry forensics so valuable in insider threat cases. In my experience, that gap is wide enough to drive a case through.

What is your go-to registry artifact when investigating insider threats? Let me know in the comments.

If you found this useful, subscribe for more practitioner-level breakdowns of digital forensics, incident response, and the realities of investigating insider threats.

AI tools are genuinely useful. I use them myself. But there’s a question most professionals skip right past in their rush to save time: has anyone actually read the legal documents on these platforms?

I did. Let me tell you what I found.

Your Data Is Fuel

For most of these companies, your inputs are not just code snippets or business reports. They are training data. Almost every major provider says this directly in their documentation.

OpenAI states that they may use content you provide to improve their services, including training the models that power ChatGPT. Google applies similar language to Gemini, noting that your data supports and improves their services explicitly including generative AI models.

This means your proprietary algorithm, your draft acquisition memo, your client risk assessment any of it could theoretically become part of a model’s weights. And if a provider’s anonymization process is imperfect during training, that information could surface in responses to someone else. Including a competitor.

A Human May Be Reading This

Think only an AI sees your conversations? Not exactly.

Google’s documentation for Gemini explicitly states that some chats are reviewed by human specialists employed by Google and its service providers, for the stated purpose of improving their models. Anthropic and OpenAI carry similar language companies reserve the right to conduct human moderation when their security filters are triggered.

So if you’re feeding private financial reports, internal correspondence, or documents containing personally identifiable information into a consumer AI tool, you should know: a human reviewer may see it. In practice, those reviewers are often contractors in offshore locations. The chain of custody for that information after that point is not something any of these companies can fully guarantee.

Where Does Your Data Actually Live?

This is the question compliance officers and general counsel should be asking before any AI rollout.

US-based providers OpenAI, Anthropic, Google store data under US jurisdiction, which means it falls under the Cloud Act. That gives US intelligence agencies a legal pathway to request access, and these companies process data on servers across multiple countries.

Chinese providers DeepSeek and Qwen are a different category entirely. DeepSeek’s documentation states directly that your information may be transferred to the People’s Republic of China. Chinese law gives the state broad access to data held by domestic technology companies. If you are sending anything sensitive to these platforms, you should treat that information as potentially accessible to Chinese government authorities. That is not speculation it is what the legal documentation says.

Why Governments Are Nervous About This

Before generative AI, states had a fairly linear mechanism for controlling information. A regulator could send a request to a search engine or social platform, get a link removed or an IP blocked, and limit access for users in a specific geography.

That model does not work on large language models.

A trained model does not provide a link to information it generates text from billions of internal weights. You cannot simply ban a fact from inside a neural network. You cannot selectively block it for users in a specific region. Filter layers can be built around LLMs, and they are but those filters can be bypassed through prompt engineering, and they add cost and fragility to the product.

Beyond information control, states increasingly recognize that LLMs carry the cultural and political values of the countries where they were trained. That is why we are seeing a race toward sovereign AI models in multiple countries simultaneously. Your conversations with these platforms are stored on servers in the provider’s home jurisdiction. From a state perspective, that represents a meaningful transfer of information and potential influence to a foreign power.

Practical Hygiene: What You Should Actually Do

I recognize that banning AI tools outright in a professional environment is not realistic. These tools improve the speed and quality of work, and the business benefits are real. The goal is not prohibition it is discipline.

Here is what I recommend, both for individual practitioners and for organizations thinking about policy.

Turn off training. OpenAI and Anthropic both offer settings that prevent your conversations from being used for model training. Find the setting. Turn it on. This should be the default state for any professional use.

Anonymize before you paste. Before sending any sensitive document to an AI tool, strip identifying information manually. Replace employee names with Employee_1 or Manager. Replace project or brand names with Project_X or Brand_Alpha. Replace revenue figures with proportional stand-ins or placeholders like [REVENUE_DATA]. This takes two minutes and materially reduces your exposure.

Use temporary chat modes. ChatGPT offers a Temporary Chat setting where history is not saved and training is disabled by default. For quick one-off questions involving sensitive context, this is the right tool.

Watch your access keys. If you use agent-based tools like Cursor or Claude Code, restrict the agent’s file access through the tool’s settings. Your environment files and API key configs should not be in scope for an AI agent unless you have a specific reason.

For high-sensitivity work, run locally. If you hold client data, financial secrets, or information subject to regulatory protection, local models are the only genuinely safe option. Tools like Ollama, LM Studio, or AnythingLLM let you run open models lama 3, Mistral, and others on your own hardware. The data never leaves your machine. No network call, no exposure.

The Bottom Line

AI tools are not going away, and they should not. But the professional and legal exposure from undisciplined use is real, documented in the providers’ own terms, and not yet well understood by most of the people making these decisions in organizations.

Read the terms. Know where your data goes. Apply the hygiene. And if a client engagement or matter involves genuinely sensitive material, have a policy in place before the data leaves the building.

I want to show you the work.

Not describe it in general terms. Not summarize the methodology. Walk you through it, step by step, the way I actually did it. Because the most important finding in this investigation is not about A7 or Tether or the Lutnick family. The most important finding is that everything I have documented was sitting in public registries, open databases, and standard OSINT tools and nobody who was transacting with these entities apparently thought to look.

That is the story your deal team needs to understand.

Let me walk you through approximately 48 hours of passive OSINT work on a single starting point: the domain a7.ru.

Before I do, the standard disclosure: all Vorex Intelligence Group investigations operate under our published Research Ethics and Methodology Policy passive OSINT only, publicly available sources, no unauthorized access, no engagement with any party under investigation. Every tool and technique described below is legal, public, and reproducible by anyone with a browser and the patience to follow the thread.

Step 1: The Front Door

Every investigation starts somewhere. In this case it started at a7.ru the public website of A7, described on its own homepage as a platform for cross-border settlement of Russian business and foreign trade contracts.

The first thing I ran was a WHOIS lookup. Thirty seconds of work.

The domain a7.ru has been registered since March 2001. The current registrant is OBShchESTVO S OGRANIChENNOY OTVETSTVENNOSTU A7 LLC A7 in English transliteration. The registration is through RU-CENTER, Russia’s primary domain registrar. The domain is current through 2027.

That gives me a named legal entity and a registration number. Now I can go to registries.

Step 2: The Russian Corporate Registry

Russia’s EGRUL (Unified State Register of Legal Entities) is publicly accessible through several aggregation services. I used Kontur.Focus, a standard Russian business intelligence platform used by compliance professionals.

What I found for OOO “A7” took about five minutes to pull and read:

The company was registered on September 2, 2024, in an unexpected location: Gelendzik, a Black Sea resort town in Krasnodar region, not Moscow. That geographic choice is worth noting Russian businesses that want reduced visibility sometimes register in peripheral jurisdictions.

Russian Tax ID (INN): 9710137165. OGRN (state registration number): 1247700586891. These are the primary identifiers for any litigation, compliance screening, or sanctions list cross-reference.

The sole shareholder: PAO “Bank PSB” Promsvyazbank. The same Promsvyazbank that holds 49% of A7 LLC, the parent entity behind the A7A5 stablecoin. The registry shows a pledge noted on the PSB share — meaning the equity stake itself is encumbered.

Revenue for 2024: 3.7 billion rubles. For a company registered in September 2024, generating 3.7 billion rubles in its first partial year of operation is not a small operation. That is approximately $45 million USD at prevailing rates.

The registry shows six subsidiary companies founded by OOO A7: OOO Rosveksel, OOO A71, OOO A7-Tekhnologii, OOO A7-Broker, OOO UK A7-Ekspluatatsia, and OOO A7-Agent. Each of these is a separate legal entity in the group structure.

The most recent EGRUL filing: April 15, 2026. Changes to founding documents. That is five weeks ago. Whatever U.S., EU, and UK sanctions have accomplished, they have not stopped this organization from actively maintaining its Russian corporate structure.

Step 3: The Kyrgyz Corporate Registry

The Kyrgyz Ministry of Justice maintains a public corporate registry. I searched for A7-Kyrgyzstan.

The registration certificate confirms: OsOO “A7-Kyrgyzstan” was registered January 17, 2025. Four days after A7A5 launched in early January 2025. The timing is not coincidental A7-Kyrgyzstan is the operational entity that issues the A7A5 token through Old Vector LLC, all registered within days of each other.

Registered address: Bishkek, Sverdlovsky district, TsUM-2 Shopping Center, building 91, 7th floor, office 714. A shared commercial office building in central Bishkek.

Business activity code: 64.99.0 “Other financial intermediation not classified elsewhere.” The same deliberately vague code used by financial entities that want minimal regulatory scrutiny.

Single founder: OOO “A7” the Moscow parent.

Beneficial owner disclosure: not filled in.

That last point deserves a moment. Kyrgyzstan’s corporate law requires beneficial owner disclosure. The field is blank. The actual beneficial ownership Ilan Shor at 51% through A7 LLC does not appear anywhere in the Kyrgyz registry. Anyone conducting counterparty due diligence using only Kyrgyz records would find a single-owner LLC with a Russian parent and no visible human owner.

Step 4: SpiderFoot Domain Intelligence

SpiderFoot is an open-source OSINT automation tool. I ran it against a7.ru. What follows is what came back from publicly available sources — DNS records, certificate transparency logs, web crawling, and standard WHOIS queries.

Active subdomains discovered:

echo.us.a7.ru, grafana.us.a7.ru, and pgadmin.us.a7.ru all resolve to IP address 89.169.57.102, hosted on Mastertel AS, Moscow. Grafana is a data visualization platform used for infrastructure monitoring. pgAdmin is a database administration interface for PostgreSQL.

I want to be precise about what pgadmin.us.a7.ru means. pgAdmin is the primary tool administrators use to directly query, modify, and manage PostgreSQL databases. It is exposed on a publicly resolvable subdomain. Whether the interface itself is accessible without authentication is a separate question I did not investigate passive OSINT stops at the perimeter. But the subdomain’s existence in public DNS records means anyone performing reconnaissance on A7’s infrastructure can identify that they run a PostgreSQL database and know its administrative interface hostname.

For a network processing billions in sanctioned cross-border payments, that is not a minor oversight.

The Azure cloud storage bucket:

SpiderFoot identified a Microsoft Azure blob storage bucket: a7data.blob.core.windows.net. A sanctioned Russian entity whose parent bank is designated for supporting Russia’s military-industrial complex is storing data on Microsoft Azure infrastructure. Whether Microsoft is aware of this tenant and whether it violates Azure’s terms of service are questions for a different investigator. That the bucket exists and is publicly discoverable is verifiable fact.

The German IBAN:

The most striking technical finding: embedded in the JavaScript source code of a7finance.a7.ru, SpiderFoot found a German IBAN: DE89370400440532013000.

Let me explain what that means. IBAN DE89 indicates a German bank account. The BLZ (German bank routing code) 37040044 corresponds to Commerzbank, Frankfurt. The complete IBAN represents an active European bank account embedded directly in the application code of A7’s financial terminal the client-facing platform through which Russian businesses access A7’s cross-border payment services.

A Russian company whose parent bank is sanctioned by the U.S., EU, and UK for supporting Russia’s military-industrial complex was maintaining an active Commerzbank account, with the account number visible in publicly accessible application source code.

The operational security failure here is almost difficult to comprehend. Someone embedded a live European bank account number in client-facing JavaScript. Standard security practice mandates that credentials, account numbers, and financial identifiers never appear in front-end code. This is taught in every security training program, documented in every secure development standard, and violated here in a way that exposes the account to anyone who opens browser developer tools.

Infrastructure co-location:

A7’s web infrastructure shares IP address 178.176.128.128 on MegaFon’s network, Russia’s second-largest mobile operator — with a cluster of other domains including rt-arb.rttv.com, rt-esp.rttv.com, rt-glb.rttv.com, rtenfrance.tv, and esrt.space. These appear to be associated with RT (Russia Today), the Kremlin’s state media network. The infrastructure co-location does not establish organizational connection, but it places A7’s web assets on shared infrastructure with Russian state media properties.

The application names:

The internal portal at portal.a7.ru is named “МояКоманда” “My Team” in Russian. It appears to be an HR or team management system. The financial terminal at a7finance.a7.ru is named “A7Терминал” the client-facing platform where counterparties would log in to initiate cross-border payments. Both applications were fully operational as of May 20, 2026 the date this scan was conducted.

Step 5: The Leaked Internal Documents

As described in the previous installment of this series, internal A7 Group business documents were exfiltrated by an unknown actor in September 2025 and published to ProtonDrive. The Cyfluence Research Center, a Berlin-based open-source intelligence organization, documented the leak in their October 2025 report and provided the public link. Elliptic, the blockchain analytics firm, independently verified and published analysis of the same materials in their September 2025 report titled “The A7 Leaks.”

From those documents, cross-referenced against the corporate registry findings above:

The A7 Group internal payment scheme document, dated July 1, 2025 — after U.S. and UK sanctions were imposed shows the complete operational architecture including Kyrgyz shell entities, Turkish intermediaries, UAE channels, and explicit “payments via crypto” exit ramps. The Turkish entity Globaluei Dysh Tidjaret Shirketi appears both in the payment scheme diagram and in the live bill of exchange system records, receiving billions of rubles in instruments in July 2025.

The client transaction ledger covers September 2024 through April 2025 and documents approximately 172 billion rubles roughly $2.1 billion USD across hundreds of Russian company clients. Ilan Shor appears as an individual counterparty with his Russian tax identification number.

The infrastructure presentation names KIFIKO, a licensed Kyrgyz broker, with its full Legal Entity Identifier (LEI: 254900YXV5VLX25QHX10) and Global Intermediary Identification Number (GIIN: 7CLWIM.99999.SL.417). Both are verifiable through international financial registries. KIFIKO is the licensed conduit through which crypto exits were processed.

What This Means

I want to be direct about what 48 hours of passive public-source investigation produced:

A complete corporate structure across three jurisdictions Russia, Kyrgyzstan, and through the leaked documents, Turkey and UAE with named entities, tax identifiers, registration numbers, and beneficial ownership chains.

Active operational evidence that the network was running after multi-jurisdictional sanctions, including a bill of exchange system processing billions in rubles as recently as July 2025 and corporate filings updated as recently as April 2026.

Technical infrastructure intelligence showing a database administration interface on a publicly resolvable subdomain, a European bank account embedded in client-facing application code, and Azure cloud storage in use by a sanctioned entity.

Confirmation that the beneficial owner Ilan Shor, convicted fraudster, sanctioned by five jurisdictions, currently a fugitive in Russia does not appear in any of the public-facing corporate registries across the jurisdictions where A7 operates.

None of this required a data broker. None of it required dark web access. None of it required any tool that is not freely available or standard in the OSINT practitioner community. All of it was sitting in public registries, corporate databases, DNS records, and application source code.

The Due Diligence Question

I am going to be specific about the professional implication here, because this is a series written for M&A practitioners, private equity professionals, and corporate security teams.

If you are evaluating any company that uses A7, Grinex, Old Vector, A7-Kyrgyzstan, KIFIKO, or the associated bill of exchange infrastructure as a payment counterparty or banking relationship you now know that counterparty’s complete corporate structure, its sanctioned beneficial ownership, its active operational status despite multi-jurisdictional sanctions, and a European bank account embedded in its client-facing code.

If you conducted standard counterparty due diligence on any of these entities and came back clean, your due diligence process has a gap. The information was public. It was findable in an afternoon.

The question is not whether a sophisticated sanctions-evasion network can hide from a dedicated investigator. They cannot hide from basic OSINT methodology applied with patience and the right sequence of queries.

The question is whether your deal process includes that methodology. Most do not. Most rely on sanctions list screening which catches designated entities but not their undisclosed beneficial owners, their subsidiary structures, or their operational infrastructure. The entities that are actually moving money are frequently one layer removed from the designated names.

That gap is what Vorex Intelligence Group closes.

What Remains Open

This investigation has two significant unverified leads that I will not publish as findings until they are confirmed or denied through additional source verification.

The first is the Cantor Fitzgerald custody claim the allegation that Cantor Fitzgerald, beyond its documented relationship with Tether, also claims to custody A7A5 tokens. This comes from a single published source. I am working to identify a second source or primary documentation.

The second is the full beneficial ownership structure of Globaluei Dysh Tidjaret Shirketi, the Turkish entity appearing in multiple A7 internal documents as a major counterparty. Turkish corporate registries are accessible but require closer examination than time has permitted.

Both threads remain open. I will publish findings when I can defend them.

The Investigation Continues

The next installment will move from the A7 network to the broader Washington dimension the documented connections between Tether, Cantor Fitzgerald, and U.S. stablecoin policy. By that point in the series, you will have the full context to understand why those connections matter for anyone evaluating stablecoin counterparty risk.

All investigation work follows Vorex Intelligence Group’s published Research Ethics and Methodology Policy. Passive OSINT only. Publicly available sources only. No engagement with any party under investigation. Nothing published that cannot be defended.

If your organization has current exposure to any entity named in this series and needs immediate due diligence support, contact Vorex Intelligence Group directly.

Let me be clear about what this article is and what it isn’t.

I am not an anti-corruption crusader. I don’t have a mission to expose bad actors. I run Vorex Intelligence Group, an OSINT investigation firm that serves M&A teams, private equity funds, and legal practitioners who need to know what they’re buying before they buy it. My job is due diligence, not activism.

A week ago, I had never heard of A7A5.

I stumbled onto it while running a client investigation that touched Tether’s reserve structure. One thread led to another, the way threads do when you’re doing this work methodically. Tether’s dominant stablecoin position led me to questions about how sanctioned entities access USDT liquidity. That led me to A7A5 a Russian ruble-backed stablecoin specifically engineered to solve that problem. And A7A5 led me somewhere I didn’t expect to go.

This article is not going to stop anyone. The people running this network are not going to read a Substack post and reconsider their life choices. What this article is and what this series is becoming is a demonstration. A demonstration of what a competent investigator can find using public sources, standard OSINT tools, no dark web access, no data brokers, no paid databases, and about a week of focused work.

A demonstration of why you need someone like Vorex Intelligence Group before you close a deal touching crypto infrastructure. And a demonstration of something that should genuinely alarm every security professional reading this: the people running a network that has processed over $100 billion in transactions apparently never hired anyone to protect their operational security. Their internal planning documents detailed PowerPoint presentations explaining exactly how they structure payments to avoid sanctions were sitting in a public repository, linked from news articles, available to anyone with a search engine and the patience to follow the link.

Think about that for a moment. You build a billion-dollar sanctions evasion network. You create detailed slide decks explaining the mechanism. And then you leave them where anyone can find them.

That is the story. Not the corruption corruption exists everywhere. The story is that basic operational security failures make sophisticated financial crime trivially documentable by an investigator with a laptop and a methodology.

How I Got Here: The Tether Thread

The connection between Tether and A7A5 is not alleged or speculative. It is structural and documented.

A7A5 is a ruble-pegged stablecoin. Russian businesses and individuals purchase A7A5 with rubles through Kyrgyzstan-based exchanges. Those A7A5 tokens are then swapped for USDT Tether’s dollar-pegged stablecoin on exchanges and over-the-counter desks. The conversion gives Russian actors access to global dollar liquidity while keeping their funds one step removed from direct Tether holdings, which U.S. authorities can compel Tether to freeze.

Coinbase’s own converter lists the A7A5/USDT trading pair. This is not an obscure dark web instrument. It is a documented trading pair on mainstream crypto infrastructure.

Elliptic, one of the leading blockchain analytics firms, documented $6.1 billion in direct A7A5/USDT trading volume. Total A7A5 transactions since launch in January 2025: over $100 billion. Peak daily volume: $1.5 billion. That is not a niche experiment that is operational scale.

The U.S. Treasury sanctioned the key entities in August 2025. The EU followed in October 2025 with what it described as its first-ever direct crypto asset sanctions. The UK sanctioned related entities in August 2025. Canada acted as well. Five jurisdictions, coordinated action, unprecedented legal tools deployed.

And yet as the documents I’m about to describe make clear the network kept operating.

What I Found in a Public Repository

Here is where this article becomes something different from standard sanctions coverage.

While researching A7A5 through public sources, I found a published analytical report from the Cyfluence Research Center a Berlin-based open-source intelligence and influence operations research organization — documenting what they describe as a “Cyfluence Counteroperation” targeting Ilan Shor’s network ahead of Moldova’s 2025 parliamentary elections.

Their October 2025 report explains what happened: on September 3, 2025, internal data from two Shor-affiliated companies A7 and Anykey LLC was exfiltrated and published to ProtonDrive, then disseminated via Telegram channels. The Cyfluence Research Center assessed the operation as a coordinated hack-and-leak designed to disrupt and delegitimize Shor’s political machinery before Moldova’s elections. Attribution remains undetermined the report notes it could have been regional hacktivist collectives or a state-affiliated actor executing a preemptive countermeasure against Russian election interference.

The Cyfluence Research Center’s report linked directly to the publicly accessible ProtonDrive repository containing the leaked files. That is the link I followed. That is where I found these documents.

I want to be precise about what this means for my sourcing. These documents were not leaked to me. I did not obtain them through any covert method. They were exfiltrated from A7’s systems by an unknown third party, published to a public cloud repository, reported on by a published research organization, and I accessed them through that published report’s public link. Every step in that chain is documented and verifiable.

Before I describe what these documents contain, let me state my methodology clearly. All Vorex Intelligence Group investigations operate under our published Research Ethics and Methodology Policy passive OSINT only, publicly available sources, no unauthorized access, no engagement with any party under investigation. Everything I publish here I can defend.

The investigation is ongoing. I do not publish findings I cannot defend. Where something is still being verified, I will say so explicitly.

Document 1: The Infrastructure Presentation

The first document is a PowerPoint presentation describing A7’s financial infrastructure. It describes bills of exchange векселя issued to bearer for international payments. It names their licensed Kyrgyz broker, KIFIKO, including its full license numbers, its Global Intermediary Identification Number (GIIN: 7CLWIM.99999.SL.417), and its Legal Entity Identifier (LEI: 254900YXV5VLX25QHX10). Both identifiers are verifiable in international financial registries.

It identifies two crypto exchanges used for A7A5 trading: the Meer exchange (subsequently sanctioned) and Kyrgyzstan’s state CNE exchange.

Document 2: The Gazprom Payment Scheme

The second document is the most operationally significant. It is a detailed payment flow diagram titled “Payment Calculation Scheme for Pipeline Natural Gas Deliveries to the Republic of Turkey in Rubles.”

The diagram names the following parties in the payment chain: Gazprom Export, Turkish gas buyers, A7-Agent, a Turkish intermediary called ZMB Gaz Depo A.S., Akkuyu Nukleer A.S. — which is Rosatom’s Turkish nuclear subsidiary and Emlak Bank in Turkey as the settlement institution, with AED (UAE dirhams) as the settlement currency.

This is a documented scheme for routing Russian state energy revenues specifically Gazprom pipeline gas payments from Turkish buyers through A7’s bill of exchange infrastructure, avoiding the SWIFT system, with Russia’s state nuclear corporation as a named participant in the payment flow.

I want to be precise: this document describes a planned or operational payment mechanism. I am not asserting that every transaction in this scheme was completed as described. What I am asserting is that A7’s own internal documents describe this mechanism, name these parties, and detail these flows.

Document 3: The Client Transaction Ledger

The third document is a transaction ledger for A7-Agent covering September 2024 through April 2025 the period before U.S. sanctions were imposed. It lists hundreds of Russian company clients with monthly ruble credit amounts.

Total transactions in this ledger: approximately 172 billion rubles, equivalent to roughly $2.1 billion USD at prevailing exchange rates.

One entry near the bottom of the ledger is particularly notable. Listed as an individual counterparty, with a Russian tax identification number, is: Шор Илан Миронович — Ilan Shor. The same Ilan Shor who owns 51% of A7 LLC, who was convicted of stealing $1 billion from Moldovan banks, who is currently a fugitive in Russia, and who is sanctioned by the U.S., UK, EU, and Canada. He appears not just as the owner of the network — but as a named client transacting through it.

Document 4: The Internal Payment Scheme (July 1, 2025)

The fourth document is the most operationally revealing. It is dated July 1, 2025 after U.S. and UK sanctions had already been imposed on A7’s entities. It is titled “Internal Payment Scheme of Group A7.”

This document maps the complete internal money architecture of the A7 Group as it was operating post-sanctions. The network at that point included: multiple Kyrgyz trading entities (Ala-Too Trade Group, Kyrgyz Front Trading, Alay Nexus Trade, Bishkek Global, Naryn Valley, Kyrgyz Silk Exchange); A71 and A7-Agent as primary conduits; Old Vector handling “market making”; KIFIKO receiving crypto payments; a UAE branch called Galadriël handling external clients in dollars and Chinese yuan; and explicit references to “markets via crypto” and “payment via crypto” as exit channels.

Also listed as a cash collection point: Sadovod. Russia’s largest open-air market in Moscow, long documented as a cash-intensive environment used for informal currency exchange.

The network did not shut down after sanctions. It reorganized and kept running.

The Bill of Exchange Screenshot

The fifth piece of evidence is a screenshot from what appears to be A7’s internal accounting system a “Bill of Exchange Workstation” showing live transactions from July 2025. The screen displays individual bills of exchange with serial numbers, issuance dates, counterparty names, and ruble amounts.

The Turkish entity Globaluei Dysh Tidjaret Shirketi which appears in both the payment scheme diagram and the internal architecture document — is shown receiving bills of exchange worth 1.5 billion rubles, 2 billion rubles, 4.1 billion rubles, and 1.5 billion rubles in July 2025 alone. Other entities shown include Talas Global Merchants, Alay Nexus Trade, and Kyrgyz Front Trading Ko.

The visible transactions in this single screenshot total approximately 14.9 billion rubles roughly $185 million USD processed in July 2025, after sanctions.

What This Means — And What I Still Don’t Know

Let me be direct about the limits of what I’ve established.

I have documented the existence and contents of these internal A7 documents. I have verified their consistency with publicly reported information about A7’s structure and operations. I have not independently verified every transaction claim in the ledgers, and I have not confirmed the current operational status of every entity named.

The Turkish entity Globaluei Dysh Tidjaret Shirketi requires further investigation. It appears in multiple documents as a significant counterparty, but I have not yet located its Turkish corporate registration details or confirmed its relationship to Emlak Bank. That work is ongoing.

The Cantor Fitzgerald custody claim that Cantor custodies A7A5 as well as Tether reserves comes from a single published source and has not been independently verified. I will not publish that finding until I can confirm it through a second source or primary documentation. That standard is non-negotiable.

What I can say with confidence: the A7 network processed billions in transactions through Kyrgyz, Turkish, and UAE intermediaries using bills of exchange and crypto rails, with Russian state energy and nuclear entities as documented participants, operated by a sanctioned fugitive oligarch with documented connections to the Russian FSB and the Kremlin’s press secretary’s social circle, and left its operational planning documents in a publicly accessible repository.

The Real Story Here

I want to return to where I started.

This investigation is not going to stop anyone. The people running this network have resources, legal teams, and geopolitical protection that a Substack series cannot touch.

The real story is operational security. Or the complete absence of it.

Somewhere in this network, someone created a PowerPoint presentation detailing how the A7 Group routes payments to avoid Western sanctions naming the Turkish intermediaries, the Kyrgyz shell companies, the UAE channels, the crypto exit ramps. And that presentation ended up in a public repository where I found it by following a link from a news article.

That is a catastrophic operational security failure. And it is not unusual. In my experience working M&A due diligence and corporate investigations, the most damaging findings rarely come from sophisticated hacking or dark web sources. They come from documents that organizations failed to protect files left in public repositories, presentations uploaded to shared drives, corporate registrations that reveal ownership structures their principals believed were hidden.

The lesson for my clients is straightforward: if you are evaluating an acquisition target with crypto exposure, stablecoin counterparty relationships, or operations in high-risk jurisdictions, the question is not whether they have something to hide. The question is whether they were careless enough to leave it where I can find it.

In this case, they were.

What Comes Next

This investigation is ongoing. I am working to verify the Turkish corporate registration of Globaluei Dysh Tidjaret Shirketi, confirm or deny the Cantor Fitzgerald custody claim, and trace the bill of exchange payment flows through public financial registry records.

I publish findings as they develop, with explicit confidence levels. Verified facts are presented as facts. Unverified leads are presented as open questions. I do not speculate past what the documents support.

The next installment will focus on the political dimension Ilan Shor’s documented connections to Russian state structures, his election interference operations in Moldova, and what all of this means for the regulatory environment surrounding the stablecoin market his network depends on.

All investigation work follows Vorex Intelligence Group’s published Research Ethics and Methodology Policy. Passive OSINT only. Publicly available sources only. No engagement with any party under investigation.

If you are conducting M&A due diligence on any company with exposure to stablecoin infrastructure, Tether counterparty relationships, or operations touching the entities named in this series, Vorex Intelligence Group is available for consultation.

I want to start by correcting a statistic you’ve probably seen.

“Two percent of Bitcoin addresses control 95% of the supply.” That claim is everywhere Bloomberg ran it, it’s been repeated across financial media, and it sounds damning enough that nobody stops to check it.

Here’s the problem: it’s measuring the wrong thing.

When Glassnode, one of the most respected on-chain analytics firms, adjusted for the fact that a single exchange address can hold funds belonging to millions of users, the number dropped substantially. The corrected finding: approximately 2% of network entities control about 71.5% of circulating Bitcoin supply. Still striking. Still a concentration problem worth taking seriously. But not 95%, and that distinction matters when you’re doing due diligence rather than writing a headline.

This is the first lesson for M&A and PE professionals evaluating crypto-adjacent companies: raw blockchain data is not the same as beneficial ownership data, and anyone presenting you with address-level concentration metrics without that caveat is either sloppy or selling something.

With that correction on the table, let’s look at what the data actually shows because the real concentration story is worse than the headline number, just in different places.

The Number That Should Concern Your Deal Team

In March 2026, the European Central Bank published Working Paper No. 3208, authored by Antonella Pellicani and colleagues. The paper analyzed governance structures across four major DeFi protocols: Aave, MakerDAO, Ampleforth, and Uniswap protocols collectively underpinning more than $106 billion in total value locked.

The headline finding: the top 100 governance token holders control more than 80% of voting supply across all four protocols. The top five holders in Aave and Uniswap control nearly 50%. In Ampleforth, the top five control approximately 60%.

That’s the token ownership picture. The voting picture is even more concentrated, because smaller holders delegate their votes rather than participate directly. In Ampleforth, the top 20 voters control 96% of all delegated voting power. In MakerDAO, the top 10 control 66%.

The finding I keep coming back to: approximately one-third of top voters across these protocols cannot be publicly identified.

Think about what that means in a deal context. If you’re acquiring a company with material DeFi exposure, or evaluating a target whose treasury or product depends on one of these protocols, a significant portion of the governance power shaping that protocol sits with anonymous entities. You cannot assess their interests, their stability, or their incentives. From a due diligence standpoint, that’s a structural blind spot — not a theoretical one.

The ECB paper adds a regulatory layer that makes this immediately practical. The EU’s MiCA framework, fully enforced since December 2024, offers a “fully decentralized” exemption from licensing requirements. The ECB’s position is clear: given documented governance concentration at these levels, major DeFi protocols cannot credibly claim that exemption. Over €540 million in MiCA non-compliance penalties have already been issued. For any target company with European operations and DeFi protocol exposure, that’s a live liability question, not a future one.

Where Else Concentration Appears And What It Actually Risks

The governance token problem is specific to DeFi. Bitcoin’s concentration risk looks different.

As of May 2026, seven mining pools including Foundry USA, AntPool, and F2Pool control approximately 75% of Bitcoin’s total network hashrate. Foundry alone holds roughly 30%. The top two pools combined represent over 48% of hashrate, which puts them uncomfortably close to the 51% threshold required to reorganize the blockchain.

The April 2024 halving, which cut block rewards by 50%, accelerated this. Smaller miners operating at thin margins can’t compete, so they join large pools to smooth income which concentrates block construction decisions with pool operators. Currently, an estimated 20% of Bitcoin miners operate at a loss.

In May 2026, the seven largest pools jointly committed to adopting the Stratum V2 protocol, which shifts block template construction authority from pool operators to individual miners. This is a meaningful governance improvement. But it does not change who controls the hashrate. The same seven entities still represent three-quarters of Bitcoin’s computing power.

For your deal work, the practical risk here is transaction censorship. A sufficiently concentrated pool coalition could theoretically exclude specific addresses or transactions from blocks. This is unlikely given economic incentives, but it is not zero and for any deal involving sanctions-adjacent counterparties or crypto assets under regulatory scrutiny, it’s a risk that belongs in the threat model.

Putting Numbers in Context

One more number that needs correcting before we go further.

The raw address data shows 2% of Bitcoin addresses controlling 95% of supply. We’ve already established that’s the wrong metric. The entity-adjusted figure — 2% of network entities controlling 71.5% of supply — is the right starting point for due diligence work. But even that number has a further adjustment: when you strip out exchange custody and institutional holdings representing millions of individual users, beneficial ownership concentration falls to an estimated 55-60% controlled by the top 2%.

That’s still extraordinary inequality. But it’s the honest number, and honest numbers are what your deal work requires.

Now the Gini coefficient — the standard measure of distribution inequality — sits above 0.92 for Bitcoin and above 0.89 for Ethereum, per Glassnode data cited by Oxford Journal analysis. One important caveat your readers should understand: crypto Gini coefficients measure address balance distribution, not human wealth distribution. Traditional economy Gini figures like the U.S. household income Gini of approximately 0.49 measure post-tax income after transfers. These are not directly comparable metrics.

With that caveat stated clearly: even after adjusting for custody aggregation and methodological differences, crypto wealth distribution runs roughly twice as unequal as the most unequal traditional economies. The adjusted Bitcoin Gini falls to approximately 0.87, compared to 0.49 for U.S. household income. That gap doesn’t close it just gets slightly less dramatic when you use the right data.

There’s academic evidence this may be structural rather than temporary. Research published in May 2026 on what its authors call “bosonic wealth statistics” analyzing Bitcoin UTXO data across 63 denominations and 72 monthly snapshots from 2018 to 2023 found that Bitcoin ownership follows geometric distributions consistent with digital money naturally producing enhanced inequality. The implication: this isn’t a market immaturity problem that resolves as crypto matures. It may be a feature of how digital, fungible assets accumulate.

A parallel study from the same period found that Bitcoin markets move from relatively equal states toward “rich-get-richer” dynamics over time, with attention and price shocks making concentration worse, not better.

For M&A analysts: when a target company’s pitch deck describes crypto as a democratizing technology, these numbers belong in your counter-briefing.

What Good Due Diligence Looks Like

Raw address metrics are insufficient for deal work. Here’s the framework I apply when evaluating crypto-adjacent targets.

First, demand custody-adjusted concentration data. Request entity-adjusted reports with exchange and custodian filtering from analytics providers Glassnode, Chainalysis, and Coin Metrics all offer this. A concentration metric without custody context is like assessing a bank’s risk without distinguishing retail deposits from interbank exposures.

Second, separately assess governance risk for DeFi-exposed targets. Token ownership metrics and voting power metrics tell different stories. Ask specifically about delegated voting concentration, not just holder distribution. And ask who the top voters are if one-third are unidentifiable, that’s material to your risk assessment.

Third, apply liquidity filters to concentration data. An estimated 3 to 4 million Bitcoin are permanently inaccessible — lost keys, early miner coins that will never move. These inflate concentration metrics. Filter for addresses with activity in the last five years to assess active, functional concentration rather than theoretical distribution.

Fourth, track custody migration trends over time. Rising institutional custody — regulated custodians holding assets on behalf of identified clients may actually reduce systemic risk even when raw Gini coefficients appear unchanged. The direction matters as much as the number.

Fifth, check MiCA exposure for European operations. If the target has EU customers or operations touching DeFi protocols, the ECB’s analysis creates a direct compliance liability. Governance concentration at the levels documented in Working Paper No. 3208 undermines the “fully decentralized” exemption. That’s not a future regulatory risk it’s a current enforcement environment with over half a billion euros already in penalties issued.

What’s Coming Next — And Why I’m Investigating It

The concentration problem I’ve described above is structural and documented. But it doesn’t stay abstract.

The GENIUS Act signed into law on July 18, 2025, the first comprehensive federal stablecoin legislation in U.S. history requires 1:1 reserve backing, monthly public attestations, and annual third-party audits for U.S.-domiciled stablecoin issuers. It passed the Senate 68 to 30 and the House 308 to 122. The stablecoin market it governs now exceeds $300 billion.

Here’s the problem: Tether, which controls roughly 60% of that market and operates from El Salvador, sits outside the GENIUS Act’s audit requirements. The DOJ is currently investigating Tether for money laundering and sanctions evasion. An estimated $8 billion in Russian sanctions circumvention has allegedly moved through USDT.

And the U.S. Commerce Secretary whose office helps set the regulatory environment for that investigation Howard Lutnick transferred his multi-billion-dollar stake in Cantor Fitzgerald, which has served as Tether’s reserve custodian since 2021, to a family trust benefiting his four children. The day after that transfer, Tether lent an undisclosed amount to that same trust. A convertible bond backing the loan entitles Cantor to a 5% stake in Tether.

Senators Elizabeth Warren and Ron Wyden have now opened four separate conflict-of-interest inquiries. The response deadline for their most recent letter was May 13, 2026.

This isn’t a case where concentration risk is theoretical. It’s a case where the documented concentration of power in the stablecoin market appears to have direct lines into regulatory decision-making and those lines run through a family trust whose beneficial owners are children.

In my next piece, I’m going to run a full OSINT investigation into the Lutnick-Tether-Cantor triangle. Public records, corporate filings, entity relationships, timeline analysis. The goal is to map what’s actually verifiable versus what’s alleged and what that means for any deal team evaluating stablecoin counterparty exposure right now.

All investigation work follows Red Dog Security’s published Research Ethics and Methodology Policy passive OSINT only, publicly available sources, no engagement with any party under investigation.

I want to start with a definition, because the word “stablecoin” gets thrown around in boardrooms and Senate hearings alike, often by people who aren’t entirely sure what they’re describing.

A stablecoin is a cryptocurrency designed to hold a fixed value typically pegged one-to-one with the U.S. dollar. Unlike Bitcoin or Ethereum, which move with market sentiment, a stablecoin is engineered for stability. One token equals one dollar. Always. That’s the promise.

The mechanism behind that promise is a reserve. Every dollar-pegged stablecoin in circulation is supposed to be backed by a corresponding dollar or a dollar-equivalent asset, typically short-term U.S. Treasury bills sitting in a reserve account somewhere. When you send someone $1,000 in USDT (Tether’s stablecoin), $1,000 in Treasuries theoretically backs that transaction.

That “theoretically” is doing a lot of work in this article. We’ll get to it.

Why Stablecoins Actually Matter to Your Business

The reason stablecoins have moved from crypto curiosity to board-level topic isn’t ideological. It’s operational.

Cross-border wire transfers through traditional banking rails take two to five business days and carry fees that compound across correspondent banking relationships. A stablecoin transaction on a blockchain settles in seconds, operates around the clock, and crosses borders without intermediaries.

McKinsey and Artemis Analytics put genuine stablecoin payment activity at $390 billion in 2025 — more than double 2024 levels. B2B transactions drove that growth, surging 733% year over year, now representing roughly 60% of all stablecoin payment volume. These aren’t crypto speculators. These are ship brokers in Singapore, steel traders in Asia, and corporate treasury teams settling invoices across currencies without touching a correspondent bank.

The U.S. Treasury Secretary projected the stablecoin market could reach $3 trillion by 2030. The current market sits above $300 billion. Tether’s USDT alone processed $1.01 trillion in June 2025.

For deal professionals: any acquisition target with international operations, cross-border supplier relationships, or treasury exposure to digital assets has stablecoin risk in the due diligence picture whether or not it appears on the term sheet.

Why Washington Stepped In

Regulators don’t act on principle. They act on scale.

When stablecoins were a niche crypto trading instrument, Washington largely ignored them. When Tether became the 18th largest holder of U.S. Treasury bills globally ahead of countries like Australia and the UAE that changed the calculus entirely.

The concern isn’t abstract. Stablecoin inflows have been documented to move short-term Treasury yields. The Federal Reserve published research in March 2026 confirming this relationship: inflows into stablecoins reduce three-month T-bill yields because the reserves have to go somewhere, and they go into the same Treasury market the Fed uses to conduct monetary policy. At $300 billion and growing toward $3 trillion, stablecoin reserve management is becoming a monetary policy variable.

Add the illicit finance layer. Tether is currently under DOJ investigation for money laundering and sanctions evasion. An estimated $8 billion in alleged Russian sanctions circumvention has moved through USDT. The EU’s MiCA framework has already issued over €540 million in penalties for non-compliance.

The result was the GENIUS Act the Guiding and Establishing National Innovation for U.S. Stablecoins Act signed into law on July 18, 2025. It passed the Senate 68 to 30 and the House 308 to 122, making it the first comprehensive federal stablecoin legislation in U.S. history. The core requirements: 1:1 reserve backing, monthly public attestations, annual third-party audits, and a prohibition on stablecoin issuers paying direct interest to holders.

Here’s the structural gap that matters for the story I’m about to tell: the GENIUS Act applies to U.S.-domiciled issuers. Tether, which controls roughly 60% of the entire stablecoin market and operates from El Salvador, sits outside those audit requirements. Senator Jack Reed has introduced the Foreign Stablecoin Transparency Act specifically to close that gap. Whether it passes is one of the most consequential open questions in digital asset regulation right now.

Who Was in the Room When the Law Was Written

Both Tether and Circle the two dominant stablecoin issuers were active in Washington during the GENIUS Act’s legislative journey, advocating for frameworks that would benefit their respective businesses. That’s standard corporate lobbying, and it’s legal.

What is not standard is what the documented relationships between Tether, Cantor Fitzgerald, and the Lutnick family look like when you map them against the timeline of that legislation.

I want to be precise here. I am presenting documented, publicly verifiable facts. Where something is alleged or under investigation, I will say so. The investigation this article teases is about establishing what’s verifiable and what isn’t — and my methodology is passive OSINT only, publicly available sources, no engagement with any party. That’s documented in Red Dog Security’s published Research Ethics Policy.

With that said, here is what is documented:

The Map: Seven Verified Relationships

Node 1: The Custody Relationship (2021 — present)

Cantor Fitzgerald began serving as custodian for Tether’s U.S. Treasury reserves in late 2021. By late 2024, Cantor held custody of approximately 80% of Tether’s $132 billion in reserve backing. That figure rose to 99% shortly thereafter. To restate that number clearly: 99% of the reserves backing the world’s dominant stablecoin run through a single custodian. Tether is the 18th largest holder of U.S. Treasuries globally. Cantor Fitzgerald holds nearly all of it.

Node 2: The Equity Stake

Cantor Fitzgerald acquired approximately 5% of Tether Holdings through convertible debt and investments totaling around $600 million. At Tether’s current scale, that stake is worth multiples of the original investment. Analysts have estimated that if Tether reaches valuation targets discussed in its 2025-2026 fundraising efforts, Cantor’s 5% could be worth as much as $25 billion.

Node 3: The Generational Transfer

Howard Lutnick was confirmed as U.S. Commerce Secretary in February 2025, bringing with him 106 documented conflicts of interest — the most ever tracked for any cabinet member, per ethics watchdog reports. To comply with federal ethics rules, he agreed to divest his multi-billion-dollar stake in Cantor Fitzgerald. In October 2025, he sold that stake to trusts benefiting his four adult children. His son Brandon, 28, became Chairman and CEO of Cantor Fitzgerald. His son Kyle became Executive Vice Chairman. The family retained operational control of the entity holding 99% of Tether’s reserves.

Node 4: The Dynasty Trust Loan

The day after Howard Lutnick transferred his Cantor stake to his children’s trusts, a credit filing appeared in New York state records. “Dynasty Trust A” one of the trusts benefiting all four Lutnick children had borrowed an undisclosed amount from Tether. The loan is secured by all trust assets, including future acquisitions. A convertible bond structure backs the loan, entitling Cantor to an additional 5% stake in Tether.

Senators Elizabeth Warren and Ron Wyden have now opened four separate congressional inquiries into this transaction. Their May 2026 letter to both Lutnick and Tether CEO Paolo Ardoino stated directly: “We want to ensure that Tether has not sought to bribe or otherwise exert control or influence over Secretary Lutnick.” The response deadline was May 13, 2026.

Node 5: Twenty One Capital

In April 2025, Cantor Fitzgerald, Tether, SoftBank, and Bitfinex jointly launched Twenty One Capital — a Bitcoin-focused entity structured as a special purpose acquisition company. SoftBank committed $900 million. Tether contributed $1.6 billion in Bitcoin. Brandon Lutnick chairs the venture. The stated goal is to rival MicroStrategy as the dominant corporate Bitcoin accumulation vehicle.

Node 6: USAT and the GENIUS Act Pipeline

Tether’s new U.S.-compliant stablecoin USAT uses Cantor Fitzgerald as its designated reserve custodian and preferred primary dealer. The CEO of USAT is Bo Hines, who previously served as Executive Director of the White House Crypto Council under President Trump where he participated directly in crafting the GENIUS Act framework. He departed that role to lead Tether’s U.S. regulatory compliance vehicle, which is custodied by the company his former boss’s family controls.

Node 7: The Open DOJ Investigation

Tether is currently under Department of Justice investigation for alleged money laundering and sanctions evasion. An estimated $8 billion in alleged Russian sanctions circumvention has moved through USDT. The Commerce Secretary whose family’s trust holds Cantor equity which holds 99% of Tether’s reserves and a 5%-plus stake in Tether itself — oversees the regulatory environment in which that investigation proceeds. He received a limited ethics waiver in July 2025 permitting participation in “senior strategic and executive” discussions on issues that could have “minimal impact” on the businesses he divested.

What This Means Right Now for Deal Work

I’ll keep this section tight because I’m going to go deeper in subsequent pieces.

If you are evaluating any company with material USDT exposure as collateral, as treasury holdings, as a payment rail the counterparty risk picture is not just Tether’s reserve quality. It includes the regulatory disposition of a $180 billion stablecoin whose dominant custodian is controlled by the family of a sitting Commerce Secretary, while that stablecoin issuer is under federal criminal investigation and the custodian’s family trust borrowed money from the issuer the day after acquiring control of the custodian.

That sentence is complicated. The underlying reality is more complicated. Which is exactly why I’m running a formal investigation rather than writing opinion pieces about it.

What I can say now, based on documented public sources:

Any deal team treating USDT as a neutral treasury instrument without understanding the Cantor-Tether-Lutnick triangle is missing a material concentration and regulatory risk that is actively under congressional scrutiny.

The GENIUS Act created a compliance framework. But it left Tether’s 60% market share outside its audit requirements. And the people most positioned to close or not close that gap have documented financial ties to the company that would be most affected by the outcome.

What’s Coming Next

Red Dog Security has opened a formal OSINT investigation into the entity relationships documented above. The next installment will begin pulling threads orporate filings, entity registration records, timeline analysis, relationship mapping using passive-only methodology under our published Research Ethics Policy.

Every time I pull one thread in this story, five more appear. That’s not an exaggeration. Brandon Lutnick interned at Tether before his father became Commerce Secretary. The USAT CEO came directly from the White House crypto policy office. The structure of the Dynasty Trust loan means Tether gains additional Cantor equity as collateral converts. Cantor holds over 30% of its portfolio in MicroStrategy stock and options the same company that champions Bitcoin accumulation while co-chairing Twenty One Capital.

This is going to take weeks, possibly months, to map properly. I will publish findings as they develop and I will be explicit about confidence levels throughout what’s verified, what’s alleged, and what’s still open.

All investigation work follows Red Dog Security’s published Research Ethics and Methodology Policy. Passive OSINT only. Publicly available sources only. No engagement with any party under investigation.

“We’re reaching out to let you know your latest payment was received successfully.” Order ID: 083733. Total: $199.99 USD. Call this number to cancel: +1 804-522-8520.

That’s it. No product. No merchant name. No billing address. Just a dollar amount, a six-digit order ID, and a phone number.

My first reaction wasn’t panic. It was curiosity because this is a textbook refund scam template, and I wanted to see how far the infrastructure went before it fell apart. It didn’t take long.

The First Four Minutes

The first thing I did was check for links. There were none. That’s actually deliberate. No links means no URL to block, no domain to flag, nothing for an automated filter to catch. The entire attack runs through a phone call, which puts the victim in a live conversation with someone trained to manipulate them.

Next I looked at the attachment INVX3E.dosx. I ran it through filescan.io. No malicious code, no embedded links, no payload. The file is essentially a prop. It exists to make the email look like a real transaction receipt. Open it, see a formatted “invoice,” feel more confused about whether you actually made this purchase. That confusion is the point.

Then I looked at the sender domain. This is where it got interesting.

The Domain That Didn’t Exist

The email referenced a payment domain. I ran it through WHOIS. The result: Pymnt33asddsvice.com is available for registration.

Read that again. The domain the scammer used as part of their payment branding vailable for anyone to buy right now for about twelve dollars. This isn’t a sophisticated operation. It’s a phone scam wearing a costume, and the costume has no lining.

What the Headers Actually Showed

This is where most people stop investigating. They see a suspicious email, maybe Google the phone number, move on. I pulled the full headers and ran them through MXToolbox.

Here’s what came back.

The email originated from mail-pf1-f175.google.com IP address 209.85.210.175. That’s a legitimate Google server. The authenticated sending domain was bel.youngchefindia.com. SPF passed. Microsoft’s composite authentication returned compauth=pass reason=100.

In plain language: this email passed basic authentication checks because the scammer used a real Google Workspace account registered under a real domain one apparently connected to a culinary organization in India. The email didn’t spoof headers in the technical sense. It used a legitimate account on a legitimate domain that has nothing to do with payment processing.

That distinction matters. Classic header spoofing is detectable by SPF and DMARC checks. This approach passes those checks. The fraud lives entirely in the gap between the authenticated domain bel.youngchefindia.com and whatever display name the recipient sees in their inbox. Most people read the display name. Almost nobody reads the authenticated domain.

The routing chain confirmed it: four hops, all Microsoft Exchange infrastructure, total delivery time of three seconds. Hop 4 flagged with an anomaly likely a DMARC alignment issue that the receiving mail client caught. But by then the email was already in the inbox.

The Phone Number

The number +1 804-522-8520 is registered through Neutral Tandem, now operating as Inteliquent under Sinch. Neutral Tandem provides carrier-neutral VoIP interconnection. In practice, that means the number can be provisioned, rotated, and abandoned with minimal friction. There’s no physical location tied to it, no individual account that traces back to a person without a legal process.

For the scammer, this is the end of the road for passive OSINT. The number exists to receive calls. Once you call it, you’re in their environment. From there the script is well-documented: fake refund that “accidentally” overpays, request to wire back the difference. Or remote access requested to “process the cancellation,” which opens your machine to whatever they want to do with it.

What This Scam Is Actually After

Per my experience with these templates, the emotional mechanics are more important than the technical ones. The $199.99 price point is not random. It’s high enough to feel urgent that’s real money but low enough that a recipient might genuinely wonder if they forgot a subscription renewal. The vague phrasing (”your latest payment”) is designed to hit that doubt.

The absence of a merchant name is also deliberate. A specific company name gives you something to verify. “Your latest payment” gives you nothing to check except the phone number, which routes straight to the scammer.

This is sometimes called a McAfee Invoice scam, though the template gets applied to PayPal, Norton, Geek Squad, and a rotating list of recognizable brands. The brand often appears only in the display name never in the authenticated infrastructure, because the infrastructure is always borrowed or disposable.

What I Did Not Do

I did not call the number. I did not respond to the email. I did not attempt to identify the individual behind the account.

Per Red Dog Security’s Research Ethics and Methodology Policy, our OSINT work stays passive. We observe, document, and analyze publicly available information. We do not engage with potential threat actors, attempt to “scam the scammers,” or take any action that crosses from investigation into active contact. The methodology has to be defensible, and active engagement is where defensibility ends.

What I did do: documented the infrastructure, preserved the headers, and noted that the sending account whoever controls bel.youngchefindia.com may itself be a victim. Compromised Google Workspace accounts are a common delivery mechanism for exactly this kind of campaign. The organization whose domain is being used may not know it’s happening.

The Takeaway for Security and M&A Teams

A few things worth noting for readers who work in due diligence, legal support, or corporate security.

First, SPF pass does not mean safe. This email passed SPF. It passed Microsoft’s composite authentication. It landed in an inbox. Technical authentication confirms that an email came from where it claims to come from — it does not confirm that the sender has any legitimate relationship to the content of the email.

Second, display name fraud is underappreciated. The gap between the authenticated domain and the visible display name is where a significant portion of business email compromise originates. Training users to look past the display name to check the actual sending address reduces exposure meaningfully.

Third, VoIP numbers are not investigative dead ends, but they require legal process to go further. Passive OSINT gets you the carrier and the interconnect provider. Attribution beyond that requires a subpoena. Know where the line is before you start.

The Full Toolchain (Reproducible)

For readers who want to run this workflow on similar emails:

Step 1 Check for links. If there are none, the attack runs through the phone number or attachment.

Step 2 Analyze the attachment. filescan.io handles this without executing the file locally.

Step 3 Run the domain through WHOIS. A nonexistent or newly registered domain is an immediate red flag. A domain available for purchase ends the investigation there for most purposes.

Step 4 Pull and analyze full headers. MXToolbox Header Analyzer gives you the relay chain, authentication results, and originating IP in a readable format. Look for the authenticated domain, not just the display name.

Step 5 Check the originating IP. AbuseIPDB, Shodan, and Censys will show you whether the IP has prior reports. A Google server won’t, but the authenticated domain may turn up in other complaint databases.

Step 6 Research the phone number. Reverse lookup tools, 800notes, ScamNumbers, and the FTC complaint database. Search the number in quotes on Google and on Reddit. Scam numbers accumulate reports quickly once they go active.

Step 7 Document everything. Screenshots, timestamps, source URLs. If this becomes relevant to a legal matter, the chain of custody starts at collection.

What’s Missing From This Investigation

Without access to the full email account infrastructure login records, associated accounts, payment trail attribution stops at the sending domain. That’s appropriate for passive OSINT. Going further requires legal process and, in most cases, law enforcement involvement.

The analysis here is a point-in-time snapshot. The number is likely already rotated. The Google account may already be suspended. The domain was probably never going to be registered. That’s how high-volume, low-sophistication scam campaigns work: fast deployment, fast abandonment, high contact volume, low success rate per contact. They don’t need to fool many people. They need to fool enough.

Every website you visit shows you the same dialog. Cookies. Accept or decline. You click through it in two seconds and move on. That dialog is real it addresses something. It just addresses the most visible layer of a tracking infrastructure that extends considerably further down than the regulatory frameworks built around it.

This series mapped that infrastructure. Browser fingerprinting assembles a persistent device identifier from signals your browser generates automatically Canvas rendering, WebGL behavior, font sets, audio hardware operating below the layer where cookies and privacy tools intervene. TLS fingerprinting captures a connection record at the transport layer, before any page content loads, before any application-layer code runs, unaffected by VPN routing or incognito mode. Data brokers normalize both into commercial identity graphs that get enriched with demographic and behavioral attributes and licensed as commercial products. And that entire chain from the first millisecond of a connection to the commercial sale of the resulting profile is largely invisible to the professionals whose work it most directly affects.

The tracking infrastructure does not care about your intent. It is neutral technology. It protects banks from account takeover. It enables attribution in cyber investigations. It powers the advertising economics that fund most of the open web. It also generates a permanent, largely unaccounted-for record of professional activity that sits in server logs, CDN databases, and broker data warehouses, waiting for someone to ask for it in discovery or pull it for analysis.

That record is the subject of this series.

What the Record Actually Is

I want to be precise about this because the tendency in privacy writing is toward alarm, and alarm is not useful to the professionals this series is written for.

The fingerprint record is not a surveillance conspiracy. It is the output of infrastructure that was built for legitimate purposes browser identification for rendering compatibility, TLS fingerprinting for fraud detection and bot mitigation, identity resolution for advertising attribution and that generates tracking data as a byproduct of normal operation. Most of the organizations collecting it are not examining it for the purpose of monitoring professional activity. They are running it through automated systems designed to detect fraud, target advertising, and resolve identity at scale.

What makes it significant for M&A practitioners, litigation attorneys, and investigators is not that it’s being weaponized against them. It’s that it exists, it’s auditable, and most of the professionals generating it have never been trained to account for it.

The gap between the privacy tools most professionals rely on VPNs, incognito mode, cookie clearing and the tracking infrastructure those tools don’t reach is the operational blind spot this series was built to surface. A VPN changes your IP address. It does not change your JA4 fingerprint. Incognito mode clears local session data. It does not change what your browser reports to servers. Clearing cookies addresses one mechanism in a stack that has several more. None of this is a criticism of those tools — they do what they were designed to do. The problem is that the threat model they were designed for is no longer the complete picture.

The Asymmetry That Matters

Consider two deal teams conducting pre-announcement due diligence on the same acquisition target.

The first team uses standard corporate browsers, routes through the firm’s VPN, and conducts research through standard OSINT and commercial intelligence platforms. They clear their cookies periodically and use incognito mode for sensitive searches. They believe they are conducting their research with reasonable privacy protection.

What they are actually generating: a consistent JA4 fingerprint associated with their browser configuration, appearing repeatedly in the target’s server logs against specific pages — investor relations sections, executive team profiles, engineering job postings, terms of service. The VPN masks their IP. The fingerprint persists. A technically sophisticated target, or a target whose security team is running standard bot mitigation tools, has a record of methodical, repeated access from a consistent device profile that predates any formal deal process.

The second team understands the fingerprint trail. They treat pre-announcement research as a sensitive operational activity, segment their research environments from their normal work infrastructure, and account for what TLS and device fingerprints they’re generating against the target’s infrastructure. Their research interest remains opaque until they choose to reveal it.

Both teams have identical legal access to identical public information. The difference is that the second team is operating with an accurate model of the information environment. The first team is operating with a model that was accurate ten years ago.

That asymmetry between professionals who understand the tracking record and those who don’t is the practical stakes of this series.

The same asymmetry runs through litigation. A law firm conducting preliminary research on a litigation adversary prior to filing is generating a fingerprint record against that adversary’s infrastructure. That record may be discoverable. It documents when the research started, which resources were accessed, and how frequently. Whether that matters in a specific case depends on the case. The point is that most litigation teams have never considered it, because they’ve never been told the record exists.

And it runs through investigation. The counterparty you’re investigating is generating a fingerprint record against every infrastructure asset their activity touches. That record tells a different story than their public representations about what software they’re actually running, what their operational patterns look like, whether their claimed security posture matches their technical emissions. Reading that record is an investigative capability. Most practitioners don’t know to ask for it.

What This Means for Professional Practice

I’m not going to close this series with a checklist. The research briefs underlying Parts 3 and 4 have those, and they’re useful references. What I want to close with is a framing observation, because the checklist is only useful if the underlying model is right.

The professionals who will get the most out of this series are not the ones who go implement every mitigation and demand fingerprint logs in every discovery request. They’re the ones who update their mental model of the information environment they’re operating in.

The tracking record is real. It is generated by normal professional activity. It is retained by the infrastructure your clients interact with every day. It is auditable by anyone who controls that infrastructure or can compel its production. And it is largely invisible to the professionals generating it, because the tools and training available to most practitioners were designed for a different version of the problem.

Understanding the record is the first step. Accounting for it in how you conduct sensitive work what environments you use, what you treat as a sensitive activity versus a routine one, what you examine when you’re building an investigation or preparing for litigation is the second step. Building it into how you advise clients on data practices, privacy policy accuracy, and due diligence scope is the third.

The record is not going away. The infrastructure that generates it is becoming more capable, not less — more signals, more accurate matching, longer retention, more sophisticated enrichment. The consent banner is not going to expand to cover JA4. Incognito mode is not going to be redesigned to mask TLS fingerprints.

What can change is whether the professionals whose work this record affects understand it well enough to account for it.

The One Thing Worth Remembering

If you take one thing from this series, make it this:

The fingerprint is not stored on your device. It is stored on the receiving server. Which means you cannot delete it, cannot control its retention, and cannot know whether someone has looked at it unless you are doing the looking.

The organizations that understand this treat the data trail as a material consideration in how they conduct sensitive work. They know what they emit. They know who retains it. They know how it might surface later. And when they need to read someone else’s record, they know where to look and what it tells them.

That is the operational advantage this series was built to surface.

That’s the infrastructure. Part 4 is about what you do with that knowledge professionally and what it means that the same record you can read about a counterparty exists for your own activity as well.

The Investigation Angle: What the Record Reveals When Public Sources Don’t

Most OSINT work focuses on what’s findable through public channels DNS records, corporate filings, breach data, social media, professional networks. These sources present curated narratives. Fingerprint and TLS data present operational reality, and the gap between the two is frequently where the most useful intelligence lives.

Three categories of signal matter here.

Device continuity is the first. Stable fingerprint hashes, consistent browser stack patterns, characteristic GPU and OS combinations these link disparate accounts, email addresses, and IP ranges to a single physical environment. A target running multiple corporate entities, a counterparty claiming no connection to a specific domain, an executive whose disclosed devices don’t match the activity pattern in available logs device continuity evidence surfaces those gaps in ways that public records rarely do. Shell accounts and ghost entities tend to leave technical tells that their operators don’t account for because they’re thinking about identity at the account level, not the device level.

Infrastructure posture is the second. A company’s JA4 fingerprint profile, its CNAME chains, the third-party SDKs embedded in its web properties, its WebRTC leak patterns these validate or contradict the security and compliance claims in its public documentation. Per my experience running due diligence investigations: a target marketing itself as privacy-forward while running twelve marketing and analytics SDKs is leaving a technical contradiction on the record. That contradiction is findable. It belongs in a due diligence finding.

Behavioral consistency is the third, and the most useful in executive-level investigations. Timezone shifts in session timing, input rhythm patterns, scroll and click behavior distributions these flag automation, shared workstations, and travel patterns that don’t match disclosed activity. In corporate espionage investigations and multi-jurisdictional compliance reviews, behavioral fingerprint data has surfaced operational patterns that no document review would have found.

The comparative advantage over traditional OSINT is specific: IP logs rotate, public records lag, and social media presents curated surfaces. Fingerprint and TLS data is passive, continuous, and difficult to spoof consistently. Even sophisticated actors using anti-detect browsers or virtual machines leave structural tells mismatched User-Agent and TLS signatures, abnormal extension ordering, rendering artifacts that diverge from the claimed device profile. The technical record is harder to maintain a consistent lie in than a document trail.

The Litigation Angle: Fingerprint Logs as Evidence

Courts are being asked with increasing frequency to weigh digital tracking records against privacy policies, consent representations, and attribution claims. The gap between what a company says it collects and what its infrastructure actually emits is now a standard litigation vector and fingerprint logs are at the center of it.

What to demand in discovery. The starting point is the collection architecture: CDP configurations, tag manager logs, SDK deployment records, and server-side forwarding rules. These establish what signals are actually gathered, which is frequently more than what the privacy policy discloses. From there, the identity resolution pipeline identity graph queries, match-rate reports, collision and split metrics, consent propagation logs establishes whether the defendant could have re-identified a fingerprint but claims they did not. Vendor and data-sharing agreements reveal who received the data downstream and under what restrictions. And the raw session logs TLS handshake captures, fingerprint hashes, session linkage tokens provide the baseline for expert validation.

The specific language matters in discovery requests. Asking for “all device fingerprint records” will be interpreted narrowly. Asking for “all server-side logs, packet captures, or CDN headers recording TLS Client Hello parameters, including JA3, JA4, cipher suites, extensions, ALPN, and SNI, for connections to Defendant’s servers from the relevant date range” is harder to answer evasively.

The gap between policy and infrastructure. This is the core litigation opportunity, and it’s more common than most practitioners expect. Many privacy policies state that the company does not collect device fingerprints or unique identifiers beyond standard web logs. The CDN is logging JA4. The analytics SDK is passing device attributes to a broker. The tag manager is forwarding session linkage tokens to three ad tech partners. The policy drafter frequently doesn’t know, because the engineering deployment happened independently of the legal disclosure review.

That gap — policy says one thing, infrastructure does another supports deceptive trade practice claims under FTC Act Section 5 and state UDAP statutes. It supports invasion of privacy claims, particularly where TLS fingerprinting occurs before any user interaction, meaning before any consent mechanism could have been presented. In jurisdictions with fingerprint-specific privacy statutes, it can support statutory claims with per-violation damages.

What expert testimony needs to establish. The plaintiff’s expert, or the defense rebuttal, needs to address several things clearly: how JA4 is generated and why it functions as a quasi-unique device identifier; the timing of collection relative to any consent mechanism using packet timestamps to show that data transmission began before the page loaded; re-identifiability analysis demonstrating that JA4 combined with IP and timestamp, or with User-Agent and screen resolution, is sufficient to re-identify a device with meaningful probability; and a direct mapping between collected fields and specific representations in the defendant’s privacy policy.

On the defense side: probabilistic matching is not legal identity. Shared devices, enterprise network environments, and browser update drift all introduce attribution noise that needs to be addressed with honest error bounds. Courts accept probabilistic evidence when experts clearly articulate match rates, error bounds, and collection provenance. The standard is not perfection it’s technically validated probabilistic confidence, which is a bar that both sides need to prepare to meet.

When opposing counsel argues incognito mode or cookie deletion. The technical response is straightforward. TLS extension ordering and cipher suite counts persist across sessions regardless of local storage state. Behavioral timing distributions typing intervals, scroll velocity, click patterns diverge from bot baselines in ways that are stable across sessions. Cross-vendor correlation between analytics platform identifiers, identity graph tokens, and server-side CDP hashes survives local storage wipes because it exists in the server’s records, not the user’s browser. Incognito mode is a local session tool. The server-side record doesn’t care what mode the client was in.

The Operational Security Angle: The Record Your Clients Are Leaving

This is not a guide to hiding from the record. The record is part of how legitimate security, attribution, and fraud prevention work, and attempting to evade it entirely is neither realistic nor, in most professional contexts, appropriate.

What it is: a risk awareness framework for professionals whose work depends on information advantage, and who have been operating under an incomplete model of what their activity generates.

Every deal team conducting extended research on a target company is generating a device and TLS record against that target’s infrastructure. Executives doing preliminary counterparty research, attorneys investigating a litigation adversary, analysts running competitive intelligence all of it leaves a trail in the receiving server’s logs that is independent of what the researcher does with their own browser settings.

The three risk vectors that matter most in professional contexts are these.

Cross-contamination between personal and professional activity. Identity graphs link devices to accounts across contexts. A senior partner doing preliminary research on a litigation target from a personal laptop that also handles personal email and personal browsing is generating a fingerprint profile that connects those contexts. The research and the personal account history sit in the same graph node. That connection exists whether or not anyone looks for it until someone does.

Vendor exposure through research tools. Many OSINT platforms, competitive intelligence tools, and research databases retain session data and, in some cases, share it with third-party partners. The organization using the tool to research a counterparty may be generating a record of that research interest in the tool provider’s logs, which may be subject to broker syndication or discovery in unrelated litigation. Vetting the data retention and sharing practices of research tools is a reasonable operational consideration that most organizations skip.

Discovery exposure for future litigation. Fingerprint logs are discoverable. An organization that has been conducting extensive research on a counterparty prior to litigation, using standard browsers and standard infrastructure, may find that the counterparty’s discovery requests include server log productions that document that research activity. The record exists on the counterparty’s servers, not the researcher’s which means the researcher has no control over its retention or production.

The question worth building into professional practice is not whether the record exists. It does. The question is: if the counterparty examines their server logs at the most inconvenient possible moment during discovery, during a deal negotiation, during a regulatory inquiry what does that record show about your clients’ activity? Is the answer something they’ve thought about, or something they’re finding out for the first time in a deposition?

Low-sensitivity research public filings, news, published social media generates a record that is unlikely to matter in most scenarios. High-sensitivity research adversary due diligence, investigation of a litigation counterparty, preliminary M&A reconnaissance before any formal process generates a record that a sophisticated counterparty can surface and use. The distinction between those two categories, and what operational approach is appropriate for each, is something professional practice should have a position on.

The Through-Line

The investigation angle, the litigation angle, and the operational security angle are three faces of the same underlying reality: the fingerprint record is real, it is largely invisible to the professionals whose work it affects, and it is auditable by anyone who controls the receiving infrastructure.

In investigation, that means the record is a source of intelligence about counterparties that most practitioners haven’t learned to read.

In litigation, it means the gap between what companies represent about their data practices and what their infrastructure actually does is discoverable, documentable, and increasingly central to privacy-related claims.

In professional practice, it means that sensitive research activity generates a trail that existing privacy tools don’t address and most operational security frameworks haven’t accounted for.

Part 5 closes the series with what this means at the level of professional practice not tactically, but as a question of how practitioners model the information environment they’re operating in

Parts 1 and 2 of this series covered the collection layer browser fingerprinting, TLS handshakes, the technical signals your device generates before you’ve done anything a privacy tool could intercept. That layer is interesting as engineering. It matters as business risk because of what happens next.

The fingerprint is not the product. The fingerprint is the raw material.

What gets built from it and sold, and licensed, and used in decisions about credit and insurance and fraud risk and advertising targeting is a different thing entirely. Understanding that pipeline is where the due diligence and litigation implications become concrete.

The Five Steps From Signal to Sale

Most organizations that collect fingerprint data don’t sell fingerprints. They sell what fingerprints become after several stages of processing that most privacy policies don’t describe in any meaningful detail.

Collection is where Parts 1 and 2 left off. JavaScript tags, server-side analytics, CDN headers, mobile SDKs — these capture browser fingerprints, TLS signatures, device attributes, and behavioral signals. Many website operators don’t realize that their CDN or ad tags are forwarding JA4 fingerprints to third parties as a byproduct of normal infrastructure operation. The data leaves before anyone makes a deliberate choice to share it.

Normalization converts raw signals into stable identifiers. A browser fingerprint has high entropy but also drift it changes when the browser updates, when fonts are installed, when the operating system patches. A data broker’s normalization layer uses probabilistic matching across signals — JA4 fingerprint plus IP range plus User-Agent plus behavioral timing to collapse multiple sessions and fingerprint variants into a single persistent device identifier. This is where the fingerprint stops being a technical observation and becomes a trackable record.

Aggregation is where device records get connected to people. Deterministic matching uses hashed emails, phone numbers, and login IDs where available. Probabilistic matching fills the gaps using the fingerprint data and behavioral patterns. Identity graph databases link devices to people to households to interest categories to transaction histories. Modern identity graphs achieve 80 to 92 percent match accuracy on desktop configurations. The fingerprint that identified your device in Step 1 is now one node in a graph that connects it to everything else the broker knows about you.

Enrichment layers commercial inference on top of the graph. Demographic attributes age range, income tier, education level are inferred or purchased from other data sources and attached to the device record. Purchase intent signals, health interest categories, credit risk indicators, political affiliation inferences. The device identifier that started as a hash of your GPU rendering behavior now carries a commercial profile worth considerably more than the raw fingerprint.

Distribution is the sale. Identity resolution APIs, audience segment licensing, risk and fraud scoring services, data clean room access these are the commercial products built on top of the pipeline. A raw device identifier might be worth fractions of a cent. A verified “in-market buyer” segment attached to that same identifier commands meaningfully more. The fingerprint is the foundation. The enriched profile is what gets priced.

What Most Website Operators Don’t Know They’re Doing

One detail from the research underlying this piece is worth pausing on: most website operators don’t realize they are passing JA4 fingerprints to third parties. The CDN handles it. The ad tag handles it. The analytics SDK handles it. The operator installs infrastructure to make their site fast and measurable, and that infrastructure — as a byproduct of normal operation forwards connection fingerprints to third parties who have built businesses around processing them.

This matters for due diligence because it means the question “does this company collect fingerprint data” is the wrong question. The right question is “what does this company’s infrastructure send to third parties, and what do those third parties do with it.” The answer is often more extensive than the target’s own privacy team is aware of.

Per the research: major identity brokers include LiveRamp, Oracle Data Cloud, Acxiom, TransUnion ID, Neustar, Babel Street, and Tapad. Many have moved toward privacy-enhanced data clean rooms and synthetic data pipelines in response to regulatory pressure. The underlying data flow — collection, normalization, enrichment, sale continues regardless of the interface through which it’s delivered.

The Regulatory Exposure

The regulatory landscape around fingerprint data and data brokerage has been moving faster than most compliance functions have tracked.

Under GDPR, probabilistic tracking which is what fingerprint-based identity resolution is — generally requires explicit consent. Legitimate interest claims face strict scrutiny. The UK’s ICO stated directly in response to Google’s 2025 fingerprinting announcement that fingerprint-derived identifiers constitute personal data and require lawful basis for collection and processing. EU enforcement against probabilistic tracking has been inconsistent but is accelerating.

In the United States, California, Vermont, Oregon, Texas, Delaware, and Colorado now have data broker registration laws requiring public registration, disclosure, and opt-out mechanisms. The FTC has pursued enforcement actions against brokers for covert fingerprint and location collection In re Kochava, In re InMarket, FTC v. SafeGraph on the theory that collection without adequate notice and consent constitutes an unfair or deceptive practice under Section 5. The same logic that applied to location data in those cases applies directly to fingerprint-derived identifiers.

The FCRA boundary is the one that creates the most immediate compliance risk for companies that haven’t thought carefully about their data flows. If fingerprint-derived risk scores feed into credit decisions, insurance underwriting, employment screening, or tenant evaluation, FCRA compliance is triggered including adverse action notice requirements, dispute procedures, and permissible purpose restrictions. Many companies running fingerprint-based fraud scoring haven’t mapped whether their outputs touch any of those decision categories. In acquisitions, that gap is a liability that doesn’t appear on the balance sheet until a regulator or plaintiff finds it.

What This Means for M&A Due Diligence

The data pipeline described above is simultaneously a commercial asset and a compliance liability. Both need to be assessed with the same rigor applied to financial statements and IP portfolios. Neither is well-served by a standard privacy policy review.

Data provenance is the starting point. What signals does the target collect browser fingerprints, TLS fingerprints, hardware identifiers, behavioral beacons? What is the disclosed legal basis for each? The gap between what a privacy policy describes and what the technical infrastructure actually collects is frequently material. Per my experience conducting OSINT investigations on acquisition targets, the technical footprint almost always tells a more complete story than the policy documentation.

Third-party data flows are the primary risk surface. Which brokers or ad tech partners receive the target’s fingerprint data? What contractual restrictions govern downstream resale and re-identification? Uncontrolled syndication a target passing fingerprint data to a broker who combines it with sensitive categories and sells it to high-risk buyers creates successor liability for an acquirer who didn’t map it during due diligence.

De-identification claims require technical validation. JA4 fingerprint plus IP address plus timestamp is re-identifiable in most realistic scenarios. A target claiming that its fingerprint data is anonymized should be asked for a third-party audit confirming that claim. False anonymization claims are an FTC enforcement trigger and a litigation theory. The bar for genuine de-identification of high-entropy fingerprint data is high enough that few organizations actually clear it.

Revenue exposure needs to be modeled. If more than a meaningful portion of a target’s revenue depends on data flows that carry regulatory uncertainty consent chain gaps, missing state broker registrations, FCRA applicability questions that exposure should be priced into the deal. The practical mechanisms are privacy reps and warranties, indemnities triggered by regulatory action or consent chain breaks, and earnouts tied to compliance milestones for identity graph assets.

Identity graph quality is a valuation input. An identity graph with high collision rates different devices mapping to the same identifier or high split rates the same device appearing as multiple identifiers after updates is worth less than its owner claims and carries more compliance risk. Requesting collision and split metrics, DSAR fulfillment rates, and opt-out propagation testing is reasonable due diligence on a data asset being acquired.

What This Means for Litigation

The litigation exposure generated by the data broker pipeline runs in several directions simultaneously.

Wiretap and interception claims focus on the timing established in Part 2: TLS fingerprinting occurs before any page content loads, before any user interaction, before any consent mechanism has been presented. In jurisdictions with broad wiretap statutes, collection that precedes any possibility of consent is a viable plaintiff theory. The pre-page-load timing is not an abstract technical detail it’s the factual predicate for the claim.

Biometric privacy claims under statutes like Illinois BIPA are primarily associated with facial recognition and voiceprints, but device fingerprinting that incorporates keystroke dynamics, mouse movement patterns, or typing rhythms has been argued as covered by biometric privacy frameworks. Brokers who purchase and resell behavioral fingerprint data can be named as collectors under some readings of these statutes.

FTC enforcement theories in the Kochava and InMarket actions involved location data collected through SDKs but the structural argument applies directly to fingerprint brokers. A broker that represents data as anonymous or de-identified while selling profiles that can be re-identified faces Section 5 exposure. The technical specifics of how re-identification works, and whether the broker’s anonymization claims are accurate, are exactly the questions that expert testimony in these matters has to address.

Securities disclosure claims following data broker breaches have argued that identity graph assets the aggregated fingerprint-linked profiles constitute material assets whose compromise triggers disclosure obligations. As fingerprint-based identity graphs become more central to a company’s commercial model, the argument that their compromise is material becomes easier to make.

For litigation teams on either side: the technical experts who can explain fingerprint entropy, collision rates, consent propagation mechanics, and graph matching accuracy are increasingly central to these matters. The gap between what a company’s privacy policy represents and what its technical infrastructure actually does is frequently where these cases are won or lost.

The Complete Chain

This is where the three parts of this series connect.

Part 1 established that browser fingerprinting identifies your device through technical signals your browser generates automatically, operating below the layer where cookies and privacy tools intervene.

Part 2 established that TLS fingerprinting extends that identification to the transport layer, generating a connection record before any application-layer code runs, unaffected by VPN routing or incognito mode.

Part 3 establishes that those technical signals are raw material for a commercial pipeline that normalizes, enriches, and sells device profiles — and that the pipeline carries regulatory exposure and commercial risk that most due diligence processes don’t adequately assess.

The consent banner addresses the cookie. The cookie is one mechanism in a stack that extends from the browser application layer down through the transport layer and out through a commercial distribution network that most of the organizations feeding it don’t fully understand.

For M&A practitioners, security professionals, and litigation attorneys: that chain is auditable. The technical record exists. The data flows can be mapped. The regulatory exposure can be modeled. The question is whether the due diligence process is asking the right questions at each layer.

Part 2 goes one layer deeper.

There is a record of your connection that exists before your browser loads a single pixel of page content. Before JavaScript runs. Before cookies are set. Before any of the application-layer tracking mechanisms that generate the most public debate have had a chance to execute. Within the first 200 milliseconds of connecting to any HTTPS website, your browser has already identified itself not through anything you did, but through the mandatory technical handshake that establishes encryption.

This is TLS fingerprinting. And unlike browser fingerprinting, you cannot block it with an extension, disable it in settings, or route around it with a VPN. The only way to prevent it is to stop making encrypted connections entirely, which is not a realistic option.

The Handshake You Can’t Skip

Every time your browser connects to an HTTPS website which is nearly every website it performs a TLS handshake to establish an encrypted session. This is the mechanism that puts the padlock in your address bar. It is not optional. Without it, there is no encryption.

The handshake begins with your browser sending a ClientHello message. That message contains, among other things: the TLS version your browser supports, a prioritized list of cipher suites the encryption algorithms your browser is willing to use a set of extensions announcing additional capabilities, your elliptic curve preferences for the key exchange, and your supported signature algorithms.

None of this is sensitive in the way that your browsing content is sensitive. It’s negotiation data your browser telling the server what it can work with so they can agree on how to communicate. The server needs this information to establish the session.

The problem, from a tracking perspective, is that different browsers make different choices about every one of those parameters. Chrome sends a different number of cipher suites than Firefox. Firefox orders its extensions differently than Safari. Each browser vendor’s implementation choices create a characteristic pattern in the ClientHello message that is consistent across sessions and identifiable without decrypting any traffic.

That pattern is a TLS fingerprint. It is generated by the normal operation of your browser. It exists whether you are in incognito mode or not, whether you are on a VPN or not, whether you have every privacy extension installed or not. It is collected passively the server observes the handshake without running any JavaScript, setting any cookies, or triggering any consent dialog.

From JA3 to JA4: Why the Upgrade Matters

The original framework for capturing TLS fingerprints was JA3, developed in 2017. JA3 concatenated ClientHello fields and hashed the result into a 32-character string. It worked, for a while. Then browser vendors noticed that their TLS signatures were being used for tracking and detection, and began randomizing the order of cipher suites and extensions to break the fingerprint. JA3 hashes are sensitive to ordering, so randomization produced different hashes from the same browser — rendering the fingerprint unstable.

Google updated Chromium in 2023 specifically to randomize extension ordering and defeat JA3-based detection.

JA4, developed by FoxIO and adopted by Cloudflare, addresses this directly. Rather than hashing the raw order of fields, JA4 sorts cipher suites and extensions alphabetically before hashing. Randomizing the order of something that gets sorted before hashing has no effect on the output. The evasion tactic that broke JA3 doesn’t work against JA4.

The format is also human-readable in a way JA3 wasn’t. A JA4 fingerprint like t13_47_a1b2c3d4 tells you immediately: TLS 1.3, 47 cipher suites offered, followed by hashed values of the sorted cipher and extension lists. A security analyst reading a JA4 fingerprint can extract meaningful information without reverse-engineering an opaque hash.

JA4 is part of a broader suite. JA4S captures the server-side TLS response. JA4X captures certificate data. JA4H combines TLS and HTTP header information into a cross-layer fingerprint. For attribution purposes, the suite allows analysts to characterize not just what client software is connecting, but how it’s connecting and what it’s connecting to.

The practical result: a February 2026 study from Istanbul Technical University found that JA4-based machine learning models distinguished bots from humans with 98.63% accuracy even when those bots were using header spoofing and IP rotation. The TLS handshake told the truth that the application-layer claims were lying about.

What TLS Fingerprinting Identifies

It is important to be precise here, because TLS fingerprinting is frequently misunderstood in both directions overstated as individually identifying and understated as irrelevant.

What a TLS fingerprint identifies is client software, not an individual. Millions of Chrome users on similar versions share the same JA4 fingerprint. The fingerprint says “this is Chrome 120 on a standard configuration,” not “this is a specific person.” On its own, that’s a relatively coarse signal.

What makes it operationally significant is what it reveals when the claimed identity doesn’t match.

A Python script using the requests library has a completely different JA4 fingerprint than a stock Chrome browser, because it uses a different underlying TLS implementation. If that script spoofs its User-Agent header to claim it’s Chrome a standard evasion technique the TLS handshake contradicts the claim. The server sees “Chrome” in the application-layer header and a Python requests fingerprint in the transport-layer handshake. That inconsistency is itself a signal.

Per the research: VPN traffic generates its own characteristic TLS signatures. A corporate VPN client, a consumer VPN service, and a stock browser all produce different JA4 fingerprints. Using a VPN doesn’t produce a neutral, unidentifiable connection profile it produces a VPN connection profile, which is identifiable as such. In some contexts, that identification is worse than no VPN at all, because it flags the connection as deliberately anonymized.

The same logic applies to the cross-layer consistency checks that advanced detection systems perform. Your TLS fingerprint, your browser fingerprint from Part 1, and your User-Agent header should all tell the same story. When they don’t when a mobile Safari TLS fingerprint appears on a datacenter IP, or when a Chrome User-Agent comes with a Python TLS handshake the inconsistency is the finding.

The Business Risk Applications

For the audience this series is written for, the question is not whether TLS fingerprinting is technically interesting. The question is where it creates exposure or opportunity in professional contexts.

Attribution in litigation and investigation. TLS fingerprints appear in server logs. They are collected passively, without requiring any active fingerprinting script to run. Any organization running modern security infrastructure — which includes most enterprise-grade web properties is logging JA4 data as a byproduct of normal operations. In litigation contexts where server log evidence is discoverable, TLS fingerprint records can establish session attribution, connect activity across IP addresses, and contradict claims about the technical environment from which access occurred. This is not theoretical it follows directly from how the logging works.

Pre-announcement research exposure. The scenario from Part 1 applies here with greater force. A due diligence team researching a target company through a corporate VPN generates a consistent TLS fingerprint not their IP address, which the VPN masks, but their browser’s characteristic handshake pattern. If that fingerprint appears repeatedly against a target’s infrastructure, a technically sophisticated target can observe the pattern in their own logs without needing to know the underlying IP. The VPN obscures one data point while leaving another intact.

Vendor and third-party risk assessment. In the same way that browser fingerprinting data constitutes personal data under GDPR frameworks a position the UK’s ICO has stated directly TLS fingerprint data collected at scale raises similar questions about lawful basis, particularly when combined with other identifiers. Acquisition targets running large-scale TLS logging without adequate privacy governance carry regulatory exposure that belongs in a due diligence finding.

Security operations and threat intelligence. For defenders, JA4 provides stable bot detection that survives the IP rotation and header spoofing that defeat earlier detection methods. Command-and-control beacons from malware generate characteristic TLS fingerprints that persist even when the malware uses encryption. Correlating JA4 fingerprints across traffic logs can identify coordinated activity from the same tool or framework across different IP addresses and time windows which is the kind of pattern attribution that matters in incident response.

The Limits Worth Acknowledging

TLS fingerprints change when browsers update roughly once a year for major version changes that alter TLS implementation. A fingerprint that identifies a specific Chrome version becomes less precise as that version ages and the user population on it narrows.

Sophisticated adversaries can spoof TLS fingerprints. Tools exist that allow a client to mimic the TLS handshake of a target browser, producing a JA4 fingerprint that matches Chrome even when the underlying client is something else entirely. This requires deliberate effort and technical sophistication, and it’s detectable through other consistency checks, but it’s not impossible.

Encrypted Client Hello (ECH), a developing TLS extension, is designed to encrypt portions of the ClientHello message that currently leak identifying information. Adoption is limited most browsers don’t implement it by default, and most servers don’t support it but it represents the direction browser vendors are moving in response to exactly this kind of transport-layer identification.

The honest framing: TLS fingerprinting is not individually identifying on its own. It becomes significant in combination with IP data, with browser fingerprints, with behavioral signals, and particularly when the claimed identity in one layer is inconsistent with what the transport layer reveals. That combination is where attribution becomes meaningful, and it’s where the gap between assumed privacy and actual privacy is widest.

The Pattern This Series Is Documenting

Part 1 established that browser fingerprinting operates below the layer where cookies and privacy tools intervene. Part 2 establishes that TLS fingerprinting operates below the layer where browser fingerprinting intervenes at the transport layer, before any application-layer code runs, collecting a record of your connection’s technical identity that no extension can block and no incognito window can prevent.

The consent banner addresses the cookie. The cookie is the most visible layer of a stack that extends considerably further down.

What exists at each layer, who collects it, and what it means for the professionals whose work depends on information advantage that’s what this series is working through.

Next in this series: The data broker layer how fingerprint data, device identifiers, and behavioral signals get aggregated, packaged, and sold, and what that market means for due diligence and litigation.