# Verifying the tenant that isn't your default

> A route returned 401 for a real tenant while every test passed and the deploy was green. The suite couldn't see it because the harness injects the tenant id directly — so the route's own resolution code never runs in tests. When your harness supplies the input a bug is about, it is structurally blind to that bug.

URL: https://biloh.com.au/docs/engineering-notes/verifying-the-tenant-that-isnt-your-default
Category: Engineering notes | Audience: builder | Updated: 2026-06-26

A route returned `401 — no tenant context` for a real tenant. The full test suite was green. The build was green. The deploy was green. Every automated signal said the code was correct, and it was broken for an actual user the moment they loaded the page.

The reason the suite couldn't see it is worth keeping: **the test harness injects the tenant id directly into the request.** Tests run with the tenant already resolved, so the route's *own* tenant-resolution code — the exact lines with the bug — never executes under test. The harness that exists to verify the route was quietly skipping the one part of it that was wrong.

## When the harness supplies the input, it can't test the input

This is a general trap, not a one-off. A test fixture that hands the system a clean, pre-resolved value buys speed and isolation — and in exchange it stops exercising whatever produces that value in production. If the bug lives in the producer, the fixture is blind to it by construction.

> When your harness supplies the very input the bug is about, it cannot see the bug. You have tested everything except the broken thing.

Tenant resolution is the classic case: in-process tests inject the tenant so they don't need a real auth round-trip, and as a result the middleware and route logic that derive the tenant from a session or token go completely unrun. Auth, request parsing, and header derivation all have the same shape — cheap to stub, dangerous to leave unverified.

## The default tenant hides bugs too

There's a second blind spot stacked on the first. The seed or default tenant — the one every developer reaches for — often resolves through a slightly different path or carries data the others don't. A bug in shared resolution can pass on the default and fail on every real tenant. So "I clicked it and it worked" is only true if you clicked it **as the tenant a real customer would be**, not the house account.

## The catch: adversarial use on a real tenant

What actually found the 401 was a person opening the deployed app, signed in as a non-default tenant, and using it — not a green checkmark. That's the durable practice: after the automated signals pass, drive the live deployment by hand, on a tenant that isn't your default, and try to break it. This is a *different boundary* than the one in [the gap between a green build and a live deploy](/docs/engineering-notes/green-build-vs-live-deploy): there the failure was build-versus-deploy; here it's harness-versus-reality. Both reward the same move — cross the boundary the green check didn't.

For the multi-tenant safety rails this verification protects, see [making a multi-connector MCP setup safe to act on](/docs/engineering-notes/multi-tenant-mcp-safety).

## Related

- [The gap between a green build and a live deploy](/docs/engineering-notes/green-build-vs-live-deploy)
- [Making a multi-connector MCP setup safe to act on](/docs/engineering-notes/multi-tenant-mcp-safety)
- [Drag is a desktop idiom; the phone wants a tap](/docs/engineering-notes/drag-is-a-desktop-idiom)