co-written with UnitBuilds, who built most of this out loud in the comments of my last piece.
I recently wrote about the $30. someone in cambodia or kenya, paid under $30 to complete a biometric verification step on behalf of a stranger, so a developer somewhere could access an ai model that's geo-blocked where they live.
I framed it as exploitation. it is. but I stopped at the harvesting.
UnitBuilds didn't stop there. over a series of comments, he walked through what happens after the $30 — and it's worse than anything I'd written.
the part the verification step doesn't tell you
when you complete a biometric check — face the camera, look left, look right — you're not just proving you're human. legally, you're authorizing.
not authorizing this one transaction. authorizing the account. anything done with it, by anyone, from that point forward, is yours. that's not a loophole. that's the definition of authentication.
as UnitBuilds put it:
"they can contest in court, but they won't win, by law they can't win, because the very definition of the authentication is that you, as yourself, fully authorize yourself and anyone else by proxy, to use your account to do with, for whatever purposes, assuming full responsibility for it."
the person who took the $30 didn't sign up to be liable for whatever happens next. but the law doesn't have a category for "deceived into authorizing." it has a category for "authorized." and once you're in that category, you're not fighting the bill. you're fighting jailtime.
what "fighting jailtime" actually looks like
UnitBuilds laid out the scenarios plainly:
a bad actor uses the harvested identity to rack up charges, commit fraud, or worse. the account holder — the person who took the $30 — has no idea any of this happened. months later, maybe years later, they get a job offer overseas. they travel. at the border, there's a warrant. for a crime committed using their face, on the other side of the planet, by someone they've never met.
or the company affected sues. the debt is structured for someone earning a developer's salary in a wealthy country. the person actually liable is earning $100 a month.
"imagine that, an entire month's pay gone, on a single ai subscription they never even knew existed, from a bank account they never made. and they don't have the finances to actually fight it in court."
that's UnitBuilds describing namibia specifically — people working full contracts, 8 to 5, for $100 a month. not informal work. not gig work. contracted employment. wiped out by a bill that was never theirs, with no path to contest it, because contesting it costs more than the bill itself.
the version where you don't even get the $30
the scenario above assumes someone got paid. UnitBuilds described a worse one: phishing.
a fake overseas job offer. "all you have to do is submit your id and do the facial verification, and send the code that's sms'd to you." it looks exactly like a routine hiring process. and then:
"that's the last you ever hear of them."
no payment. no awareness that you were ever part of a supply chain. just a verification step that felt normal, and a liability that surfaces however long it takes for someone to misuse it.
this isn't new, it's just wearing new clothes
UnitBuilds has watched this pattern before ai existed. bank impersonation calls — spoofed numbers, confident voices, "confirm your account details" — targeting pensioners who grew up trusting that a call from the bank was actually the bank.
"life-savings gone from pensioners, who have no means of earning it back or fighting the bank for it. some had to choose between food on the table and paying their wifi, losing access to communication with everyone they know, for the sake of not going hungry, because someone scammed them out of 50 years worth of hard work."
whatsapp cloning works the same way — impersonate a relative, get the verification code, clone the account, spread it to the entire contact list, harvest more identities, repeat.
the throughline, in his words:
"it's a system built on accountability, not morality, and the legal system is there to defend the dollar not the person."
in namibia, you go to prison longer for poaching a cow than for murder.
the part that has nothing to do with biometrics
then UnitBuilds introduced something I hadn't considered at all: hardware identity theft.
two forms. the first is shadow proxy networks — malware that quietly routes traffic through your residential gateway, so someone else's activity travels under your ip, your network, your name.
the second is newer and stranger. you buy a windows 11 laptop. secure boot signs the hardware to your microsoft account the moment you log in. from that point, you're the authorized owner of that device — and liable for whatever it does — until you go through the process of manually removing it from your account's device list. format it, sell it, give it away: none of that breaks the link. the new owner is using hardware that's still, in microsoft's records, yours.
"a small little detail they don't tell you when they say it's 'for your data security.'"
the mechanism is identical to the biometric one. ownership and liability bound to an identity that doesn't update when the physical reality changes. the gap between who actually controls something and who's legally responsible for it is where all of this lives — bodies, devices, accounts, doesn't matter. the structure repeats.
the sentence underneath all of it
a developer going by self-correcting systems read the original piece and named the pattern precisely:
"a control that can't see its own downstream doesn't stop the harm, it relocates it."
that's what every layer of this is. kyc doesn't stop fraud — it relocates the verification burden onto someone with no stake in the outcome. secure boot doesn't stop hardware theft — it relocates ownership liability onto whoever's account it happened to be signed into. every fix moves the cost. none of them eliminate it. they just choose, by design or by accident, who absorbs it.
the people who absorb it are consistently the people least equipped to refuse, least equipped to understand what they're agreeing to, and least equipped to fight it once it lands.
UnitBuilds runs Halo Cybersecurity adjacent work and built NMCP, a rust-based mcp implementation. everything quoted here, he gave permission to use directly — his words, not mine, paraphrased into something smaller than what he actually said.
most of what's true in this piece, he wrote first, out loud, in a comment thread.
AI helped me research, structure, and edit this piece. The arguments, the examples, and the opinions are mine and UnitBuilds'. So is whatever's wrong with them.
Top comments (23)
This reminded me of Wikipedia's entry on On Contradiction — specifically this part: "When old processes change, new processes and contradictions emerge."
KYC set out to solve verification. It did — and created a new contradiction right inside the solution. A bounded proof now backs an unlimited liability. The fix didn't remove the problem. It just moved it.
@unitbuilds nailed it: "the system protects money, not people." In the language of the text — the principal aspect of the contradiction is always capital, and the secondary side always carries the cost. That pattern isn't limited to biometrics. It shows up in KYC, Secure Boot, every hardware handshake. Not a bug in the implementation. It's the architecture.
Not to mention, KYC made the lie look right on paper. @kenielzep97 and I had a discussion about the exact failure point when it came to NDA file format. Even if a document is self-correcting, if a balance sheet balances, it's considered correct, there's no way for the document to know that the values were wrong and a lie the system thinks is true, is more dangerous than a lie that gets questioned. Because now it's a face to the account, but that face is the lie, because it's not the person using it. As long as the process itself is the only verification stage, it's open to fraud... Except now it's verified fraud that nails down liability on 1 person.
Take a phone for instance, you use facial ID, it assumes owner is you, because of your face. But loading a face is a 1 time procedure, that can allow anyone really to get full authority of your device. Eg. scenario, mine is added on my fiance's phone, but by me having access via biometrics, it means I can go on app store and make purchases from her account, with nothing but my face. So who pays the bill? (still me, cuz my card is linked, but you get the point 😂)
UnitBuilds, "verified fraud" — that's exactly the transformation of opposites On Contradiction is talking about.
"The two aspects of contradiction coexist and aspects can transform into one another. Any one aspect is dependent on the existence of at least one other aspect."
Verification and fraud aren't fighting each other. They're the same coin. Once the system stamps "verified" on a face that isn't the user's — verification just turned into fraud. Same mechanism, opposite ends. You can't have one without the other.
Your phone example says it all: load your face once, now any face that passes is the owner. The thing that's supposed to protect you becomes the thing that bypasses you. No external breach needed — the attack path was built into the design from day one.
Exactly, the real problem is, design a system that's actually anti-fraud. Doesnt matter how many verification steps you add, it's still spoofable. Fake ID, Fake face, Fake fingerprint, copied private key, copied account logins, proxied IP, cloned phone number. Even standing face to face with a person, who shows you their ID and bank account, you cant verify anything really, it just boils down to trust. How much do you trust the authentication methods used to verify they are who they say they are.
Exactly why the principal contradiction keeps moving. KYC solved "who are you" — then "who verifies the verifier" took its place. Solve one, the next one's already waiting.
@xulingfeng, @unitbuilds . "a lie the system thinks is true is more dangerous than a lie that gets questioned" and "the principal aspect of the contradiction is always capital" are the same observation from different traditions landing in the same place.
The verification mechanism doesn't know the difference between a face and the truth behind it. the system stamps verified, capital is protected, and the lie becomes load-bearing. that's not a failure of implementation . it's the architecture completing its intended function.
the phone example closes it: one face loaded once, full authority granted indefinitely, bill paid by whoever's card is linked. the system worked exactly as designed. that's what makes it dangerous.
@dannwaneri , and that's exactly the universality of contradiction — "contradiction exists in the process of development of all things, and in the process of development of each thing a movement of opposites exists from beginning to end." The pattern repeating across KYC, Secure Boot, biometrics, transfer station economy isn't a coincidence. It's the same contradiction surfacing in different forms of motion. The architecture is the same because the contradiction is the same.
The Wikipedia entry sums it up: "No society — past, present, or future — could escape contradictions, for this was a characteristic of all matter in the universe."
Essentially Yin and Yang. Every good implementation has it's exploitability, that's equally and oppositely as sophisticated and harmful.
When it was just 'link your email', you had plausible deniability if it went bad. Now with KYC, the cost of entry is steeper, you need to pay someone for a face. But as high as the cost of entry is, so is the cost of it going wrong. Namely, irrefutable evidence in court that you authorized it.
Yin and Yang is the older name for the same observation. On Contradiction just formalized it. Glad that landed.
"The cost of entry rises,and so does the cost of it going wrong". That's the piece in one sentence. the architecture scales both directions simultaneously. no coincidence it keeps surfacing in the same form.
That's why the same pattern shows up across systems that share nothing but the contradiction. Thanks for the conversation — this thread went deeper than I expected. 🤝
@dannwaneri, @unitbuilds, this piece and this thread are the strongest conversation on this problem ive seen on here. The line you quoted about a control that cant see its own downstream. seeing it carried into the harvesting side and made concrete like this means a lot. what i do is research one narrow thing in public, how systems keep obeying authority that expired, and i pre-register every claim before results so the failure condition is on record first.
The reason im commenting is @vinicius just described something i spent the last two months building and testing. a grant as its own object that carries the action its good for and the window it dies in. i published that exact shape as a pre-registration, the grant was still valid but the source had changed: dev.to/kenielzep97/the-grant-was-s... . the bounded proof underwriting an unbounded window is the one i call signed is not fresh, authority needs both properties: dev.to/kenielzep97/signed-is-not-f... . and the deeper one, permission is not purpose, a perfectly scoped grant can still be used inside its window for something it was never for: dev.to/kenielzep97/permission-is-n...
One thing id add to making unscoped authority unrepresentable. its necessary but not sufficient. the grant can be perfectly scoped and still wrong because the source it was issued against changed after issuance. the face check was real on monday, whats behind the account is different by friday. so the gate has to re-check the source at decision time, not just the shape of the grant. we ran that exact cell against a live external certificate authority and the distinction between revoked and unreachable turned out to matter more than the signature did. UnitBuilds already named the human version of this, a lie the system thinks is true is the dangerous one. verified fraud is just a valid grant over a rotten source.
Everything is timestamped and public, so if any of it helps the follow-up piece its there to use. and honestly the most valuable thing anyone in this thread could do is try to break it.
kenielzep97, "signed is not fresh — authority needs both properties" is the gap the $30 piece didn't name and the follow-up needs. the face check was real on Monday. what's behind the account is different by Friday. a perfectly valid grant over a rotten source is still verified fraud — UnitBuilds named the human version, you named the architectural version.
"permission is not purpose" is the one that extends furthest. Vinicius' bounded proof problem and your pre-registration approach are solving adjacent things — he's scoping the window, you're tracking whether the source the grant was issued against is still the source it's being used against. both properties are necessary. neither is sufficient without the other.
reading all three pre-registrations before the follow-up gets written. everything timestamped and public is exactly the sourcing posture Wren flagged as the right one — failure conditions on record first means the claim survives scrutiny whether it holds or breaks.
Daniel, the Monday face Friday account line is the whole problem in one sentence. Keep that in the follow up.
One thing from actually running those three pre registrations that might matter for what you're writing. When I tested source drift against a real external certificate authority, the lesson that survived was that CAs at least speak in status signals. Revoked, expired, something a gate can fetch at decision time. The $30 grant has nothing like that. There is no revocation registry for what's behind the account changed. The human source has no status API. So the fix goes one step past making grants first class objects like Vinicius said. Every grant needs a source it can be rechecked against at decision time, and if no such source exists, the system should not be able to express a grant of that liability size at all. Right now the $30 flow is a permanent grant issued against a source that can never be reread. That is the architecture naming the exploitation, not enabling protection.
All three pre registrations are frozen with failure conditions on record and the claims stay internal and class limited until someone breaks them from outside. If it helps, send me the scenarios you're building the follow up around and I'll run them against the frozen packets before you publish. Rather find the holes before it ships than after.
the line that a control which can't see its downstream relocates the harm is the whole thing, and i'd put a finer point on the mechanism: this is authentication being silently promoted to authorization. the biometric check only ever proves one thing, that a specific person was present for one moment. the system then treats that as standing permission for everything the account does forever. a bounded proof underwriting an unbounded liability window. that gap is where the harm lives, and it always rolls downhill to whoever is cheapest to enroll.
and it isn't a biometrics problem, so a stronger or wider check doesn't fix it. the fix is scoping the authority the proof grants. bind the verification to a specific bounded action or window, not to the account and every future action attached to it. "this face passed once" should never compile to "this holder authorized all of it, indefinitely." most of these systems collapse identity, presence, and authority into one event because it's convenient at signup, and the person who pays for that collapse is never the one who designed it.
from where i sit, $30 for a quick verification is a completely real offer to a lot of people, and none of them are reading the liability surface they just underwrote. the asymmetry isn't an edge case the design missed, it's load-bearing.
Vinicius, "a bounded proof underwriting an unbounded liability window" is the sentence that should be in the piece. That's the mechanism stated precisely not a flaw in the verification, a flaw in what the verification is allowed to authorize. the check proves presence at one moment. the system compiles that into standing permission for everything, indefinitely. the gap between those two things is where every harm in this thread lives.
The fix you're describing — bind the proof to a specific action or window, never to the account and all future actions is the right architecture. the problem is that collapsing identity, presence and authority into one signup event is convenient for the platform and catastrophic for the person. convenience always wins at design time because the person paying the catastrophic cost isn't in the room when the decision gets made.
that line goes in the follow-up piece verbatim...
agreed. and the reason it keeps happening is the grant isn't even a thing you can point at in most of these systems. presence and authority ride the same token, so "scope it" becomes a discipline you have to remember every release, and discipline loses to convenience every time.
the version that holds is making the grant its own object: it carries the action it's good for and the window it dies in as first-class fields, issued at the moment of use, not at signup. then "this face passed once" can't be represented as "this holder authorized all of it", because no token says that. you're not scoping the authority by being careful, you're making the unscoped version unrepresentable.
if you want the follow-up's spine in one line: the goal isn't to scope authority carefully, it's to make unscoped authority impossible to express.
Horrible, and frightening - we might call it "digital slavery" ...
And this:
"kyc doesn't stop fraud"
But of course not, that's been obvious from day 1 - KYC is only for "legally cover your ass" purposes, it does nothing to deter criminals - just tons of bureaucracy to harrass the little man, while the millionaires, the billionaires and the professional crooks know how trivially easy it is to evade it ...
The tricks get more nasty and sophisticated, the goals (extorting $$$ from the innocent) stay the same!
leob, "legally cover your ass while doing nothing to deter criminals" is the honest version of what KYC is. the burden lands on the person cheapest to burden. that's not a side effect . it's the design.
the 'bounded proof, unbounded liability window' framing from Vinicius is the cleaner mechanism statement. the system treats 'was present at one moment' as 'authorized indefinitely' because collapsing both into one token is cheaper to ship.
we hit the same shape in AI agent auth: sign one webhook event and the platform compiles that into full API access — because the key proves 'authenticated' and authentication carries no downstream scope. 'this integration signed once' shouldn't mean 'this integration owns the account.'
is there a version of the grant as object fix that doesn't require the platform to want the complexity, or does it always bottom out at 'whoever absorbs the edge case wasn't in the room'?
Mudassir, "whoever absorbs the edge case wasn't in the room" is the answer to your question. there isn't a version of the grant-as-object fix that doesn't require someone to want the complexity because the complexity is the cost of not externalizing the failure onto whoever is cheapest to absorb it. the platform that collapses authentication and authorization into one token does so because scoping is expensive to build and the person who pays for the collapse isn't a stakeholder at design time.
The webhook example makes it concrete — sign once, own the account, because that's cheaper to ship than expiring scopes. the fix exists architecturally. it just requires the platform to internalize a cost it currently externalizes. that's a business model problem before it's an engineering problem.
Interesting take on the long-term risks of low-cost hardware. In my work with GPU infrastructure, I've seen how cheap components can lead to hidden costs in maintenance and security—especially when dealing with sensitive workloads. At VoltageGPU, we focus on making confidential computing more accessible, but it's a constant balance between cost, performance, and trust.
As someone who's worked on secure GPU isolation, I can say that $30 is a drop in the bucket compared to the risk of a side-channel leak or misconfigured enclave. You're not just paying for the code — you're insuring against the next Meltdown variant.