Separation of permissions from code is the real scaling test

At a glance

What this is: This case study argues that centralized authorization, separated from application code, is the key control that lets a small finance platform scale roles, approvals, and data visibility without tying policy changes to developers.

Why it matters: It matters because IAM, PAM, and lifecycle teams all face the same governance tension: access rules must evolve faster than code releases if business users, approvers, and sensitive datasets are to scale safely.

By the numbers:

• One developer got 95% of the authorization work done in about 6 weeks.

👉 Read Cerbos' case study on centralized authorization for Nook

Context

Authorization in a finance workflow is the set of rules that determines who can approve, execute, or view sensitive transactions. In Nook’s case, the core problem was not sign-in, but how to model business roles so accountants, finance staff, operations teams, and owners could act without exposing payroll or bank data broadly.

The article frames this as a scaling issue for access governance rather than a coding convenience issue. When permissions live in the application layer, business rules move at developer speed; when they sit in a centralized policy layer, non-developers can govern access while engineering stays focused on product delivery.

Key questions

Q: How should teams separate authorization from application code in business apps?

A: Teams should move access rules into a centralized policy layer and keep the application focused on business logic. That lets security and product owners adjust roles, approvals, and visibility rules without rewriting endpoints. It also improves auditability because the entitlement model lives in one place instead of being duplicated across services.

Q: Why do fine-grained roles matter in finance and AP workflows?

A: Finance workflows mix owners, approvers, accountants, and operational reviewers, each with different responsibilities and data needs. Fine-grained roles prevent overexposure of payroll, bank details, and supplier records while still allowing the business process to function. Without that separation, organisations usually default to broad access or slow manual exceptions.

Q: What do organisations get wrong about authorization in early-stage products?

A: They often treat authorization as something to add later or embed directly in framework code. That creates developer dependency and makes role changes harder for the business to govern. The better approach is to treat authorization as a scalable control plane from the start, even in a monolith.

Q: How do centralized permissions help with scaling access governance?

A: Centralized permissions make it possible to add new user types, evolve approval flows, and keep sensitive data boundaries consistent as the product grows. They also reduce the risk that access logic fragments across endpoints, services, or developer-owned libraries. For governance teams, that consistency is what makes reviews and policy changes manageable.

Technical breakdown

Policy-as-code authorization for finance workflows

Policy-as-code means access decisions are expressed in a dedicated policy layer rather than scattered across endpoint logic. That separation lets teams define who can view invoices, approve payments, or access payroll without rewriting business logic for each role. In practice, it also reduces the coupling between product features and access control, which matters when the same platform must support multiple customer configurations and internal user types. The architectural value is not just cleaner code. It is the ability to change authorization rules independently of the core app, while keeping the decision logic testable and reviewable.

Practical implication: move authorization out of endpoint code and into a centrally managed policy layer that can evolve without redeploying the application.

Role design for AP, AR, and sensitive financial data

Accounts payable and accounts receivable systems rarely have a simple user model. Business owners may need ultimate control, finance teams may execute payments, external accountants may maintain books, and operations teams may only need invoice-level visibility. That is a classic role design problem, where the challenge is not just granting access but constraining what each role can see and do. Fine-grained authorization becomes essential when one workflow spans payment execution, payroll protection, and partial visibility into banking or supplier data. Without that granularity, organisations default to broad access and manual exceptions.

Practical implication: map business functions to distinct roles and separate view, approve, and execute permissions before onboarding broader user groups.

Business-owned permissions versus developer-owned access logic

One of the most important governance choices in the article is who owns permission changes. If access logic sits in code, developers effectively become the gatekeepers for every role change, policy tweak, and exception. If it sits in a dedicated authorization system, business owners can participate directly in shaping access boundaries. That matters for scale because authorization is not only a technical control. It is a product and governance control that must keep pace with customer needs, internal controls, and audit expectations. The more business users depend on the platform, the more that ownership model matters.

Practical implication: assign policy ownership to the business and security governance layer, with engineering enforcing integration and testing.

NHI Mgmt Group analysis

Separation of permissions from code is now an identity governance requirement, not an architecture preference. When access rules stay embedded in application code, the organisation makes every role change a software change and every business exception a developer dependency. That creates avoidable delay, weakens auditability, and pushes governance decisions into places business owners cannot inspect. The implication is straightforward: permission ownership has to be treated as a first-class governance domain, not a byproduct of backend implementation.

This is a classic access model problem, but the governance failure is broader than role mapping. Finance workflows need different entitlements for owners, approvers, accountants, payroll staff, and operational reviewers. If those distinctions are not separated cleanly, organisations end up overexposing sensitive data to preserve operational speed. The lesson for IAM and IGA teams is that functional complexity in business workflows is a signal that coarse access structures will fail first.

Policy-as-code is the named control pattern that makes scalable authorization possible. It decouples permission decisions from the release cycle and gives governance teams a reviewable place to define who can act on what. That matters for both human and non-human access models, because the same separation principle also supports service accounts and workflow identities. The practitioner takeaway is to treat centralized policy as the control plane for access, not the application itself.

Authorization ownership shifts the operating model for product teams as much as for security teams. When business users need to define roles, the access model must be understandable outside engineering. That changes review cadence, exception handling, and accountability boundaries. The broader implication is that modern identity programmes have to govern who may define access, not only who may receive it.

Scaled access control exposes the difference between functional access and sensitive-data visibility. The Nook example shows that not every user who touches a workflow should see all related financial information. That distinction is essential in IAM, PAM, and lifecycle design, because approval rights, execution rights, and data access rights are not interchangeable. Practitioners should use that separation as the basis for their entitlement model.

From our research:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• The governance pattern in Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs shows why lifecycle control must sit outside the application layer.

What this signals

Permission ownership is becoming a governance boundary, not just a developer convenience. When access logic lives outside the codebase, business teams can evolve entitlements without waiting on engineering cycles. That shifts IAM programmes toward policy administration, reviewability, and separation of duties, which is the real operational test for scalable authorisation.

Access models that distinguish approval from visibility will increasingly define resilient finance platforms. The fact that the same workflow can involve owners, accountants, payroll staff, and operations reviewers means coarse entitlements will fail early. Teams should expect more demand for policy layers that make those distinctions explicit and auditable.

Policy-as-code will matter beyond software teams. The control pattern is relevant wherever a business must govern access at scale, including NHI and service-account oversight, because the principle is the same: keep entitlement logic observable, reviewable, and separate from execution code.

For practitioners

• Separate authorization from the application codebase Place role and permission logic in a centralized policy layer so access changes can be reviewed and updated without editing endpoint code. This reduces engineering bottlenecks and makes access rules easier to audit.
• Model distinct business roles before onboarding new users Define separate entitlements for owners, finance staff, accountants, payroll teams, and operations reviewers before expanding access. Keep view, approve, and execute permissions independent where business risk differs.
• Give business owners policy visibility without giving them code access Ensure non-developers can inspect and help shape access rules through policy tooling while engineering owns deployment and test integrity. That keeps governance visible without compromising software control.
• Test authorization changes as part of the release cycle Treat permission updates like application changes, with policy tests that confirm sensitive datasets such as payroll and bank feeds remain properly restricted after each release.

Key takeaways

• The central governance issue is not whether users can sign in, but whether access rules can scale independently of application code.
• Nook’s example shows that fine-grained roles can expand user participation without exposing payroll, bank, or invoice data broadly.
• The strongest access-control model is the one that lets business owners govern permissions while engineering preserves testable policy enforcement.

Key terms

• Policy-as-code: Policy-as-code is the practice of expressing access rules in a dedicated, machine-readable policy layer rather than embedding them throughout application logic. It improves auditability, testability, and change control, especially when multiple roles, datasets, and approval paths must be managed consistently.
• Fine-grained authorization: Fine-grained authorization means different users can view, approve, or execute different actions based on their role and context. In finance systems, this is the difference between broad application access and carefully constrained rights over payments, invoices, payroll, and supplier records.
• Separation of duties: Separation of duties is the governance principle that no single role should control every high-risk step in a process. In access design, it prevents a user from both requesting and approving sensitive actions, which reduces fraud risk and supports cleaner audit trails.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Cerbos: Nook’s authorization case study. Read the original.