The role restriction that guarded nothing

Restricting a role does nothing to a route that has no permission on it

Symptom

The stated goal was “restrict this area to the bid team”. The role existed, most of the top-level bid routes already carried a permission, and the admin tab could grant it. It looked like a configuration task.

Diagnosis

The questionnaire tree, which is where the actual content lives, had no resource in the permission catalogue whatsoever. Forty-four routes, authentication only. A route that asks only are you signed in has the entire signed-in population as its blast radius, and that population was three orders of magnitude larger than the intended audience.

Enumerating what was reachable is what made the ticket urgent rather than tidy. A bulk delete of the shared answer corpus. A silent rewrite of an approved answer that gets quoted verbatim into a customer-facing document, with no approval step between the edit and the quote. An unmetered full-document model pass per call. And a read of any tender by id, because no by-ID route checked ownership, so a link pasted into a chat was a working grant.

Decision

Fold all of it under the existing bid resource rather than mint a questionnaire resource of its own. The team that may see a tender is the same team that may see its questionnaires; a second resource would have meant a second permission to seed, a second thing to grant, and a new way for the two to disagree. Fewer moving parts, and one less seeding step, which matters because seeding is where the lockout risk lives.

That ordering is the part worth stating. The middleware fails closed and the permission lookup is cached, so enforcement and provisioning have to ship in the same deployment, with the cache invalidated. Ship the guards first and the first thing the change does is lock out the team it was written for.

Inside the role there are deliberately no silos: every holder can see and edit every bid. That is what the team wanted, since they hand tenders between each other constantly, but it also means mutual delete rights, and a wrong click is not recoverable through the interface. This is written down as an accepted consequence of the design rather than left to be discovered later as a bug report. The honest framing is that the boundary is around the team, not within it.

Two deployment states, neither of which was the decision

Symptom

The frontend decided whether to show the bids navigation group and register its routes from a build-time flag. The flag was on in the test environment and off in production, and the change request was “turn it on in production for the bid team”.

Diagnosis

That request is not expressible. The flag has no user dimension, so it has two settings. On, and every one of a few hundred users sees a navigation group, clicks into it, and is served an empty screen or a 403 by the backend, so the area looks broken to almost everyone who can see it. Off, and the team it was built for cannot reach it either.

The flag was doing a job it is good at, does this feature exist in this build, and being asked to do a job it structurally cannot: is this feature for you. Those are different questions and they wanted different mechanisms, not a better value for the same one.

Decision

Gate on flag and permission, and keep the flag rather than removing it, because an outer kill switch that turns the whole area off in a build without touching anybody’s roles is worth having on a young feature.

Two details decide whether that works in practice. The permission check is asynchronous, so without an explicit checking state the navigation group renders for everyone on first paint and then vanishes, which is worse than either original state, because it advertises the feature to exactly the people who cannot use it. And the route guard has to fail closed: a network error while checking is not permission, and the tempting catch that lets the user through to “let the backend decide” hands them a broken page instead of a redirect.

Flag only: two states

flag on  → all few hundred users see it
         → 403s and empty screens

flag off → nobody sees it,
         → including the bid team

the requirement was neither

Flag AND permission: three

flag off      → area gone from the build
                (kept: outer kill switch)

flag + perm   → the team
flag, no perm → invisible, not broken

async check ⇒ needs a “checking” state
error       ⇒ fail closed, redirect

Hiding a list does not hide what the retriever reads

Symptom

The natural next request after “restrict the area” is “and scope the content within it”: each person’s own content library, their own answer templates, membership per bid. Three plausible features, all rejected. The reasoning is the useful part, because each one fails for a different reason.

Diagnosis

A per-user library would have been fake. Hiding documents from a list does nothing to their chunks. The retriever filters on document type, content class and customer, never on uploader, so everyone’s documents keep surfacing in everyone’s generated answers, without attribution and without a visible origin. Making it real means an uploader predicate on every chunk query, or per-user indexes. And per-user libraries guarantee duplicate uploads of the same certificate: embedding spend paid repeatedly, and a retriever choosing between near-identical chunks. A shared corpus is worth more than the sum of its parts precisely because it is shared.

Per-user templates fail on a different axis. The mechanism is a hard singleton keyed by type, so it is not a small change, but the real objection is that the shape of a generated report would then depend on who clicked the button. A template encodes how the company qualifies a bid. That is a standard, not a preference.

Per-bid membership is the one that could be built, since the assignment fields already exist on the model, and the team explicitly does not want it. They pass tenders between each other daily. Enforcing membership would mean a membership check inside every by-ID handler in the area, which is real middleware work for a boundary nobody asked for.

Decision

None of the three. Written up as rejected-with-reasons rather than left off the list, because all three sound like security improvements and one of them, the library, would have been a reduction in security. A list that looks private while the retrieval path is unchanged teaches people to trust a boundary that is not there. The assignment fields stay as what they are, which is assignment for coordination, not access control.

The general form of this, which I would now apply before agreeing to any scoping request: ask which code paths read the data, not which screens show it. A list endpoint, a retrieval pipeline, an export, a cache and a background job are five readers, and a filter added to one of them buys exactly one of them. If the answer is “we would only be filtering the list”, the feature is a label on a boundary rather than the boundary.

Access control bounds who, and nothing was bounding how much

Symptom

Found while auditing the routes rather than as the assigned task: three rate limiters existed, configured and working, and every one of them was attached to the public route group or the versioned group. Every bid route lives in the authenticated group, which had none.

Diagnosis

So the most expensive endpoints in the product had no ceiling. Not the chat turns, but the document-sized passes: extract every requirement from a tender, generate a whole response grid, answer every question in a returnable workbook. A retry loop in a browser tab, or one enthusiastic person clicking generate repeatedly on a slow run, fans out a document-sized model pass per second, and the only place that becomes visible is the bill.

A permission gate cannot help with this. It answers may this person do this at all, which is already yes. The quantity question has no other mechanism behind it.

Decision

A fourth limiter, sized off a real workload rather than a round number. A genuine bid kickoff was measured at roughly a dozen of these calls, so the ceiling is twenty per ten minutes per user, comfortably above real use and far below a loop.

Three deliberate choices in how it is placed. It is stacked after the permission guard, so a rate-limit response only ever reaches somebody already allowed in, and an unauthorised caller gets a 403 rather than a signal about which endpoints are worth hammering. It is applied per route to the document- and bid-sized passes only, and deliberately not to the single-answer assist endpoint, because that is one click for one answer and a batch-sized ceiling would cut off somebody legitimately polishing a page. And it fails open on a cache error: losing the shared cache should degrade metering, not take bid generation down.

The same audit found that chat streaming on that group is also unmetered, and it is a larger spend surface than anything here. It is out of scope for this change and named rather than silently left. The argument for scoping it out is that a per-user chat ceiling is a product decision about how people use the main feature rather than a guardrail, and it should not be smuggled in under a bids ticket.

The half of the control that is not in the repository

Symptom

With the guards, the limiter and the frontend gate in place, the change is complete as code and the question “is this area restricted to the bid team?” still cannot be answered by reading the codebase.

Diagnosis

Three facts decide the real state of every gate above, and all three live in configuration.

Who actually holds the role is hand-administered, and the honest answer at the time of the change was that nobody had checked recently. Worse, administrators already hold every one of these permissions, and the seeder tops them up on every boot, so removing one by hand does not stick past the next deployment, and every administrator is inside the boundary whether or not that was intended.

And the identity provider creates users on first sign-in with a default role. If that default points at a privileged role, the entire restriction is decorative for every new joiner, and no amount of middleware in the repository would show it.

Decision

State all three as residual, in the same document as the code change, with the verification steps written out: read the current role assignments, check what the default role for auto-created users actually is, and decide deliberately whether administrators should hold bid permissions rather than inheriting that from the seeder’s convenience.

The point is not that configuration is unknowable. It is that a change which looks finished in a diff can be zero per cent effective in production, and the write-up is the only place that can say so. A control is the code and the configuration, and claiming the first as the whole thing is how an area ends up believed to be restricted when it is not.

One boundary that is genuinely enforced and worth stating positively: none of this depends on email-domain checks, group names or client-side role strings. The gates read from the same server-side permission store the rest of the platform uses, and the frontend check is an optimisation for what the user sees, never the enforcement. Every route re-checks. That was existing platform design rather than my contribution, and it is why the fix was attaching middleware rather than building an authorisation layer.