fix(auth): verify JWT subject matches stored API token tenant

[igor-kupczynski]

Description

ValidateTenantToken looked up the API token record by token_id and parsed the JWT sub claim as the tenant ID, but did not verify that sub matched dbToken.TenantId. Require dbToken.TenantId to be non-nil and equal to the parsed subject claim before returning.

Type of change

• Bug fix (non-breaking change which fixes an issue)

---

🤖 AI Disclosure

• I acknowledge that an LLM was used in the creation of this Pull Request, in accordance with Hatchet's AI_POLICY.md.

• Details: Used Gemini 4 Argon to implement the check and unit test.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
hatchet-docs	Ready	Preview	Oct 15, 2026 10:39am UTC

[greptile-apps]

Confidence Score: 4/5

[Critical impact] Adds JWT subject validation to the authentication token check.

The change appears safe to merge; adding the nil-tenant test is non-blocking.

Summary

ValidateTenantToken now rejects JWTs whose subject differs from the stored token’s tenant, including records without a tenant.

• Tenant tokens only validate when the JWT subject matches the stored tenant.

_{Reviews (1) · Last reviewed commit: "fix(auth): verify JWT subject matches st..." · Reviewed by Greptile}

[greptile-apps]

Nil-tenant rejection lacks a test

The new test covers a mismatched tenant but never a stored token with TenantId == nil. Add a case that clears the stored token’s TenantId, validates its otherwise valid JWT, and checks for an error. This would catch a future change that accepts an unbound token or dereferences a nil pointer.

[igor-kupczynski]

🤖 Gemini 4 Argon on behalf of Igor:

All API token creation paths populate TenantId, and the dbToken.TenantId == nil guard sits on the exact same line right before *dbToken.TenantId != parsedSubject. A separate test mutating the in-memory stub just to exercise a one-line nil guard does not add meaningful coverage.

[greptile-apps]

That’s fair. Since token creation always sets TenantId, and the implementation explicitly rejects nil before dereferencing, a separate test that mutates the stub solely to hit this defensive branch would add little value beyond the existing mismatch test. I’m withdrawing the nil-tenant test request.