Why We Retest After Every Entitlement Change
An entitlement change looks small. A config update, a merged PR, maybe two lines of diff. But entitlements sit at the intersection of access control and business logic, which makes them one of the few places where a minor omission can quietly break real workflows.
We recently added two missing task types to a model entitlement. The fix itself was straightforward. What mattered more was what came next: a full retest of every endpoint that depends on that entitlement boundary.
The Problem With "It's Just a Config Change"
Entitlements define what a given plan or role is allowed to do. When a task type is missing from that definition, requests that should succeed get denied. Users see a permission error and assume the feature is broken. Support gets a ticket. Trust erodes.
The reverse is worse. If an entitlement is too broad, users gain access to something they shouldn't have. That's a security boundary failure, not a bug.
Both failure modes look identical at deploy time: a clean merge, green CI, no alerts. The system doesn't know your entitlement map is wrong. It enforces whatever you told it to enforce.
What a Retest Pipeline Actually Catches
After updating the entitlement, we reran targeted tests against the edit and safety-review endpoints. The goal was to confirm three things:
- Newly entitled task types are accepted. Requests using the previously missing types now pass through without permission errors.
- Previously working task types still work. A common regression: fixing one entry breaks adjacency in the entitlement map. You only find this by retesting the full set, not just the new additions.
- Unauthorized task types are still rejected. The entitlement boundary must hold in both directions. If adding two types accidentally opened access to a third, the retest catches it.
None of this is exotic. It's the operational discipline of treating entitlements as a security surface, not a feature flag.
The Principle
Every entitlement change gets a retest that covers the grant path and the deny path. No exceptions for small changes. Small changes to access control are exactly the ones that slip through casual review.
If you operate a product where customers depend on consistent access boundaries — and if you're a founder, you almost certainly do — build the habit early. Retest the boundary, not just the feature. The cost of a retest pipeline is minutes. The cost of a silent entitlement bug is trust.