Two P0s, one root cause: identity comes from a verified token

Most weeks the achievement I want on the record is a surface going out. This week it's a bug going away — the same bug, twice, on two different services, closed with the same idea. It is not glamorous work. It is the kind of work that, done right, no user ever notices, and done wrong ends a company. So I'd rather write it down plainly than dress it up.

The root cause, stated once: a service was deciding who you are by reading the request, instead of by verifying a token. When identity comes from the request, anyone who can type a URL can be anyone. When it comes from a cryptographically verified token, they can only be themselves. That single sentence is the whole post.

The same bug, twice

On July 12 an internal code-read audit of the TRD gateway (api.trdn.io) found that its auth path base64-decoded the JWT payload and checked only that a subject field existed and the token hadn't expired — it never verified the signature. Behind that gate sit money-adjacent routes. A token you can decode but never verify is a lock that checks the shape of the key, not the key.

The very next day, July 13, the DCS intelligence engine (our adaptive memory service, AIE) turned out to have the same disease in a blunter form. Its production instance was reading userId straight from the query string. GET /aie/profile?userId=<any-uuid> would read that user's memory; the edit and reset endpoints would write and wipe it — no token required at all. It had gone unnoticed for the most uncomfortable reason there is: everything worked. As the fix commit puts it, an open door opens for everyone, including the people testing it.

Two services, two days, one root cause. That coincidence is the reason this is a single post and not two.

The TRD gateway: verify the signature

The gateway fix landed as four commits on the afternoon of July 12 — the first code on that surface in ten days. In order:

• The P0 itself — a new shared verifyToken() that cryptographically verifies the bearer token server-side and returns a verified identity, plus fixes to the Mart refund and referral RPC parameters that had been failing on a signature mismatch.
• A server-side Mind+ proxy — a bridge from the gateway to the Mind+ backend that takes the caller's email from the verified token, never from the URL. Same principle, applied to a second hop.
• A build fix — committing a route file that index.ts imported but that had never been committed, which had quietly been breaking every build from the hosted repo. Not cosmetic rot; a broken build hiding in plain sight.
• An owner gate — a JWT-verified owner check against an explicit allow-list, applied to the admin cost, revenue, and stats routes. The old gate trusted a decoded email; the new one trusts a verified one.

I'll be honest about the state of it: the migration isn't finished. A handful more routes — payments, subscriptions, vendor-spend — carry the same verifyToken() change in the working tree, uncommitted, as I write this. They are not done until they're committed and pushed, and I'm not going to call them done.

The intelligence engine: the open door, closed

The AIE fix takes identity from a verified JWT that overwrites whatever the caller sent, and it adds two guards that matter more than the fix: the service now refuses to boot if it's marked live with no signing secret, and it rejects the "auth off" switch whenever it's running live, so that shortcut can never quietly become the production default. A kill-flag that lets the server keep serving is not a kill-flag; these close that gap.

Two more changes from the same day are worth naming because they're the load-bearing ones:

• Tenant isolation. AIE joined the shared tenant model, and the tenant id became un-passable on writes. That fixed two tenant-blind database constraints — including one where one tenant's consent record could overwrite another's. Consent overwriting across tenants is exactly the kind of quiet cross-account bug that only surfaces once two real customers exist.
• The right signature algorithm. The verifier had been pinned to HS256 while the identity provider issues ES256, so every real sign-in was being rejected — and the auth tests passed anyway, because they minted their own HS256 tokens. The lesson the author wrote down is the good one: the tests verified an assumption, not the provider. It now verifies against the provider's published keys.

One correction I owe you, because it cuts against us: this file had earlier recorded the intelligence engine as "not deployed." It was deployed — reachable and serving — and our own record was wrong. The status flag moved to live not because something shipped, but because we found it already was, and had mislabelled it. Getting that on the record is part of the point.

Identity comes from a verified token. Never from the request. It's now a comment at the top of the auth file, because a rule you have to remember is a rule you'll eventually forget.

What's committed, and what's verified

Everything above is git-verified: I'm describing commits read directly out of the repositories, not a status page. What is not yet verified is the deploy. The gateway and the intelligence engine both fix the bug in code; confirming the live effect — the one-line check that a forged token now returns a 401 instead of a 200 — could not be run from where this work is integrated, and until it is, the honest word is "assumed, not proven." A fix you haven't verified is a fix you're assuming.

That's also why the discipline around it hasn't moved. The intelligence engine's receipts are durable now, but they're still unsigned — the signing path exists in code and is switched off, so nothing it emits yet counts as a verified receipt. No product flag flipped this week on the strength of any of this. The work is hardening underneath the existing flags, not new capability reaching a new surface.

What is not done yet (and we want you to know it)

Why it's worth a post

Because the failure mode is the same one every time, and naming it is the only defence that scales. Both of these bugs passed their tests. Both looked healthy. Both did precisely what they were told — the trouble was that they were being told by whoever was asking. The fix isn't clever; it's a rule, applied twice, and written into the code so it survives the next person who's in a hurry. When the deploy proofs are in hand, they'll get their own honest line here — with what we checked, and who checked it.

— Deepak