How I Made Blitzy More Secure In My First Week
Jun 30, 2026 • Alex Gardiner • 3 min read
Every engineering team has a backlog of unglamorous, yet necessary work. These projects do not end up in launch announcements or involve clever algorithms and fancy services. The category includes tasks like "we need to audit our auth layer," or "we should probably add pagination."
Role Based Access Control (RBAC) sits squarely in this category.
RBAC is a security model that controls what actions users can perform, rather than giving users blanket access to every endpoint. You define roles (like Admin or Member), assign permissions to those roles (like projects:delete or users:write), and then enforce those permissions at each point of action.
RBAC is basic security hygiene: the kind of work that gets added to a backlog, triaged every quarter, and then pushed aside… again and again.
The Challenge
When I joined Blitzy a couple of months ago, I had no familiarity with the codebase. I didn't know the conventions, the history behind design decisions, and I hadn't developed a sense of how permissions should map to actual user behavior in the product.
These mappings are actually the hardest part of RBAC. While the technical implementation is relatively straightforward, deciding whether a MEMBER should be allowed to delete a project, or whether access sharing should be gated to ADMIN and above, requires intuition that takes time to build.
With our backend service having hundreds of endpoints across many domains, the scale factor made the project feel even harder. With a manual approach, this would require days of discovery before starting implementation, and getting it wrong could be costly.
Risks include:
- Locking users out of features they rely on
- Or worse, leaving gaps that the access model was meant to close
Additionally, edge cases hiding beneath the surface make things tricky, as permissions aren't uniform across Blitzy's product. Some resources are owned by an entire organization, others belong to specific teams, and users can access things through multiple paths.
Adding RBAC is precisely the kind of task Blitzy is built for.
My Approach
Rather than working through RBAC manually, I delegated to Blitzy.
My prompt described a centralized architecture I had in mind, while instructing Blitzy to make judgement calls in areas where my knowledge ran thin. I wanted to encourage the platform to reason through unknowns rather than to work around them. This was an important moment for my early experience with Blitzy, as I realized that I wasn't limited by a lack of understanding.
Blitzy then generated an Agent Action Plan (AAP). Reviewing the AAP gave me a complete picture of every endpoint that needed enforcement and the specific permission decisions Blitzy made, given its knowledge of the codebase. This review process was of particular value as I wasn't just approving the plan, but also learning from it, as Blitzy surfaced new findings that I hadn't yet encountered.
Next, I started Code Generation and let Blitzy run over the course of a few days, in order to cover the vast scope of the AAP. Once complete, I reviewed the Project Guide to see what Blitzy built, the reasoning behind its decisions, and the areas it wanted me to review manually. That last part was especially useful for me as a newcomer, since I had a fully transparent report on the large set of code changes.
The Outcome
After finishing and merging the Blitzy project, the rollout completed with no incidents.
What made this possible was the structured handoff the Project Guide provided. Blitzy's flagged assumptions gave reviewers a head start, rather than requiring them to audit every decision from scratch.
For a project of this scope, a successful outcome is not guaranteed. With the combination of roles, subscription tiers, resource types, and more, there are a lot of ways to mess up. The fact that the feature shipped cleanly reflects on Blitzy's ability to reason carefully, navigate a large codebase, and apply changes with intention.
The Value
RBAC is necessary work that makes software systems safer. This project is exactly the kind that teams defer because the costs are disproportionate to business impact.
What Blitzy changes isn't just the speed at which work gets done, but whether it gets done at all.
A project that would have required weeks of discovery and deep product intuition became something I could initiate within days of joining and complete with confidence.
