Separation of permissions from code is the real scaling test

At a glance

What this is: This case study shows how Nook moved authorization out of application code so roles, permissions, and business-led access decisions could scale without tying control to developers.

Why it matters: It matters because IAM teams, product owners, and security architects need authorization models that can evolve with new user groups, sensitive data boundaries, and faster product growth.

By the numbers:

• Nook had about 30 weekly users at the time of the interview.

Context

Authorization becomes a scaling problem when roles, entitlements, and data visibility are trapped inside application code. In that model, every policy change depends on engineering cycles, which makes it harder for business owners to adjust access as products add new user types and new sensitive workflows.

Nook’s AP and AR platform needed business owners, accountants, finance staff, and operations users to hold different permissions over the same workflow. That is a classic access governance problem, not just an application design choice, because the organisation has to limit who can approve, execute, and view financial data as the product grows.

The article argues that separating permissions from code lets non-developers manage the business logic of access while developers keep shipping features. That starting position is common for fast-growing software teams, and it becomes more visible once the product starts serving distinct roles inside the same transaction flow.

Key questions

Q: What breaks when permission logic stays inside application code?

A: Hardcoded authorization quickly becomes scattered, duplicated, and inconsistent across services. Teams lose a single place to test policy changes, audit decisions, and prove who could access what at a given time. As rules expand beyond simple roles, code-based checks also become harder to change safely without introducing regressions or accidental overexposure.

Q: Why does separating authorization from code matter for scaling product teams?

A: It lets product and business owners evolve roles and entitlements without waiting for engineers to rewrite endpoints or redeploy logic. That matters when a platform needs to onboard new user groups, protect sensitive data, and keep approval rules aligned to business workflows instead of code ownership.

Q: How do teams know if authorization is being enforced consistently?

A: Look for a single policy source, shared entitlement semantics, and matching decisions across client, API, and service layers. If the same user or workload gets different outcomes in different runtimes, the policy model is already fragmented. Consistency testing should prove that policy intent survives deployment into every enforcement point.

Q: Who should own access rules in a growing platform?

A: Ownership should sit with the people who understand the business workflow and the data sensitivity, with engineering providing the technical enforcement layer. If the only practical path to changing roles runs through developers, business ownership of access is still too weak.

Technical breakdown

Why authorization embedded in code slows role growth

When roles and permissions live in application code, access logic becomes coupled to endpoint changes, framework conventions, and developer ownership. That makes authorization hard to adapt when a product needs to serve multiple business functions, because the control plane for access is scattered across the codebase instead of being managed as policy. In practical terms, even a monolith can accumulate hidden authorization complexity if every permission change requires code edits and release coordination. The result is not just slower delivery, but less visible governance over who can do what across the product lifecycle.

Practical implication: Keep authorization policy separate from application logic so access changes can be governed without forcing every policy update through engineering.

How centralized policy supports business-led access decisions

Centralized authorization lets a business owner or product operator define who can approve, execute, or merely view information without needing source-code access. That matters in finance workflows because different users may need access to the same record for different reasons, and the permission boundary must reflect business responsibility rather than technical convenience. A policy layer also makes it easier to express sensitive-data segmentation, such as payroll visibility versus payment approval, without scattering checks across services. This is where policy-as-code becomes a governance model, not just a developer pattern.

Practical implication: Model roles around business functions and keep the approval logic in a dedicated policy layer that non-developers can reason about.

Why separation of concerns improves auditability and change control

Separating permissions from code makes authorization decisions easier to test, update, and review independently of feature development. That reduces the risk that access rules become accidental side effects of application structure or a developer’s implementation style. It also gives teams a cleaner change history for authorization, which is useful when product, compliance, and security teams need to understand why a user group can or cannot perform an action. In practice, the benefit is governance clarity: access becomes a controlled product capability rather than an implicit behaviour hidden inside the build.

Practical implication: Treat permission changes as governed policy updates with their own review, testing, and release path.

NHI Mgmt Group analysis

Authorization tied to code is a scaling constraint, not just an implementation choice. When access decisions live inside the application layer, every new role expands the engineering burden and every policy change competes with feature delivery. That works for the earliest version of a product, but it becomes brittle once different business users need different views and actions over the same workflow. The practitioner conclusion is simple: if access must scale with the business, it needs its own governable control surface.

Separation of permissions from code is really a governance boundary. The important question is not whether developers can implement permissions, but whether business owners can safely define and adjust them without source-code access. That is especially relevant in financial workflows, where approval, execution, and visibility should not be collapsed into one role. The implication is that IAM and product governance meet in the same place, so ownership of access policy must be explicit.

Policy-as-code only matters when it decouples authority from release cadence. In this case, the value is not abstract elegance but operational flexibility: roles can change as user groups expand, without forcing a rewrite of the application. That changes how scaling should be judged in access control. The practitioner takeaway is to measure whether authorization can evolve independently of the codebase, not whether it merely exists inside it.

Role design should follow business responsibility, not framework defaults. The article shows that finance staff, accountants, operations users, and business owners needed distinct rights over the same payment process. That is a reminder that access models built around technical convenience tend to underfit real operating structures. The practitioner conclusion is to design for the business workflow first, then enforce it with a policy layer that can survive growth.

Named concept: authorization elasticity. This article’s core lesson is that access control must absorb new user types, new approval paths, and new visibility boundaries without becoming entangled in application code. That elasticity is what lets a small team serve more customers without turning authorization into a bespoke engineering project. The practitioner implication is to assess whether the authorization model can stretch as the product and its governance surface expand.

From our research library:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
• Read next: Authorisation Models Guide

What this signals

Authorization elasticity: access control has to expand as products add new user groups, approval paths, and visibility boundaries. If those changes require code edits, the access model is still acting like a development dependency rather than a governed business capability.

A growing product team should treat separation of permissions from code as a sign that authorization is becoming operable at scale. The real test is whether business owners can shape access safely without waiting on the engineering release train.

For practitioners

• Separate policy from application code Move roles, permissions, and approval logic into a dedicated authorization layer so business rules can change without source-code edits.
• Map access to business functions Define who can approve, execute, and view data based on workflow responsibility, not on which team happens to own the code.
• Give non-developers policy ownership Make sure product or finance owners can update permission logic without needing access to the engineering repository or deployment pipeline.
• Test sensitive-data segmentation Verify that payroll, invoice, and bank-feed visibility are separated cleanly, with each role receiving only the data it actually needs.
• Review authorization as a release artifact Treat policy changes as versioned, testable changes that are reviewed independently of feature code before they reach production.

Key takeaways

• Authorization becomes harder to govern when access rules are embedded in application code and tied to developer workflows.
• Nook’s example shows that separating permissions from code can support more user roles, finer data visibility, and broader workflow participation.
• The practical control is to move authorization into a governed policy layer that business owners can manage without source-code access.

Key terms

• Runner Elasticity: Runner elasticity is the ability to scale CI execution capacity up and down with build demand. In security-sensitive build systems, elasticity matters because it lets teams absorb spikes without sacrificing reproducibility, while still keeping the execution environment tightly controlled.
• Policy as Code: Policy as code stores authorization logic in version control and evaluates it through testable, reviewable rules. For agent governance, it makes runtime decisions reproducible and measurable, which is critical when actions can be triggered by untrusted content and executed at machine speed.
• Separation Of Concerns: Separation of concerns is an architectural principle that divides system responsibilities into clear boundaries. In this article, it means policy is established in one layer while traffic handling happens in another. That split reduces complexity, improves consistency, and makes large distributed systems easier to operate safely.
• Role-Based Access Control: A model that grants permissions by assigning identities to predefined roles. It works well when jobs are stable and access patterns are predictable, but it becomes brittle when exceptions pile up. In practice, role design must stay small enough to audit and broad enough to avoid endless custom variants.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.