Policy-as-code authorization: what non-engineers can govern safely

At a glance

What this is: Cerbos argues that readable policy-as-code can move authorization changes from engineering-only workflows into shared review processes without removing control.

Why it matters: That matters because IAM teams, security leaders, and application owners increasingly need faster permission changes without turning authorization into an uncontrolled self-service free-for-all.

By the numbers:

• 30% of Supy's customers use this self-service capability.

👉 Read Cerbos' guide on policy-as-code authorization for non-engineers

Context

Authorization becomes a governance problem as soon as permissions change faster than engineers can safely code, test, and deploy them. In SaaS and enterprise environments, that usually means every new customer, compliance rule, or product tier creates another access exception that must be managed without turning access control into ad hoc scripting. Cerbos positions policy-as-code as a way to move that work into a readable policy layer that product and security teams can participate in.

The identity governance question is not whether non-engineers can edit policy. It is whether the organisation can preserve review, versioning, and enforcement discipline when more people touch authorization logic. In practice, that makes authorization part of broader IAM governance rather than a narrow application-development task. It also creates a clearer boundary between who proposes access rules and who approves them.

Key questions

Q: How should security teams let non-engineers participate in authorization safely?

A: Let non-engineers draft and discuss policy, but keep approval and publication under controlled workflow. Use versioned policy files, enforced review, and validation checks so business input improves responsiveness without turning authorization into unmanaged self-service. The safest model is shared authorship with clear separation of duties.

Q: Why does policy-as-code help with frequent permission changes?

A: It shortens the distance between a new business requirement and the access rule that enforces it. When policies are externalized, teams can adjust roles and conditions without rewriting application logic each time. That reduces bottlenecks, but only if change control remains strong.

Q: What breaks when authorization is embedded directly in application code?

A: Permission changes become slow, hard to review consistently, and easy to scatter across services. That increases the risk of inconsistent access rules, hidden exceptions, and engineering bottlenecks. Over time, the organisation loses a clean audit trail for who changed what and why.

Q: Who should approve changes to fine-grained access policies?

A: Approval should stay with the role that owns governance, not just the person who authored the edit. In practice that usually means a security, IAM, or delegated control owner reviews the change, while engineers validate technical impact before production publication.

Technical breakdown

YAML policy-as-code and CEL conditions for authorization

Cerbos expresses authorization in YAML, with conditions written in Google's Common Expression Language. That combination matters because policy text stays close enough to plain English for non-engineers to read, while still being structured enough for deterministic evaluation. The practical difference from embedded application logic is that rules are externalized, versioned, and reviewed separately from code. That reduces the gap between business intent and the actual access decision. It also makes permission changes easier to inspect after the fact, provided the organisation preserves policy history and approval context.

Practical implication: keep policy syntax readable, but treat policy review as a governed change process, not a casual content edit.

Git-based review and validation for authorization changes

Cerbos places policies in Git, so the same pull request workflow used for software changes can govern access rules. That creates separation of duties in process terms: one person can propose a policy, another can review it, and a validation layer can check it before distribution. This is important because readable policy alone does not prevent unsafe access. The control comes from the workflow around the file, not the file format itself. In identity terms, this is policy governance, not just policy authoring.

Practical implication: require pull-request approval, validation checks, and audit trails for every authorization change.

Centralized policy distribution without redeploying applications

Cerbos Hub distributes policy updates to PDP instances so changes can propagate without restarting services or redeploying application code. The architecture separates decision making from application runtime, which is useful when access rules change often across many services. Cerbos PDP evaluates requests statelessly, while the hub manages policy versioning, testing, and audit visibility. That reduces application sprawl, but it also concentrates governance responsibility in the policy plane. If that plane is weakly controlled, broad inconsistency can spread quickly across services.

Practical implication: treat the policy distribution layer as a critical governance control point and monitor it like production access infrastructure.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• BeyondTrust API key breach — compromised BeyondTrust API key led to unauthorized SaaS access.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Policy readability is a governance control, not just a usability feature. When authorization logic can be read by product and security teams, the organisation lowers the barrier to participation in access design. That does not eliminate engineering oversight; it changes where the decision work happens and who can meaningfully review it. For IAM programmes, the real value is shared understanding, not self-service freedom. The conclusion for practitioners is that readable policy can reduce bottlenecks only if approval discipline remains intact.

Externalized authorization collapses the gap between business change and access control. When permissions live outside application code, the access model can evolve with product tiers, customer exceptions, and compliance requirements without waiting on code releases. That is structurally useful for SaaS, regulated operations, and fast-moving product teams. It also means authorization governance becomes a configuration integrity problem across many services. Practitioners should treat policy drift as an IAM risk surface, not an engineering convenience.

Git-based policy governance creates an auditable control plane for access decisions. Moving policy changes through pull requests, validation, and distribution gives security teams a repeatable review path. The important point is that this is still governance by workflow, not governance by format. If the review path is weak, readable policy can still encode bad access decisions at scale. The practitioner implication is to align authorization changes with the same separation-of-duties expectations used for other privileged changes.

Fine-grained authorization will increasingly become a cross-functional operating model. As more teams participate in permission design, IAM stops being a late-stage engineering service and becomes part of product governance, security review, and customer lifecycle management. That widens organisational reach, but it also increases the need for policy ownership, clear approval boundaries, and consistent audit evidence. Teams should assume the bottleneck will move from implementation to governance unless they redesign the operating model accordingly.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• 45% of organisations cite lack of credential rotation as the top cause of NHI-related attacks, which shows how operational gaps turn into access risk, according to The State of Non-Human Identity Security.
• For the broader control perspective, use NHI Lifecycle Management Guide to map authorisation changes to lifecycle governance, review, and offboarding.

What this signals

Policy-as-code will keep spreading because it solves an operating-model problem, not just a tooling problem. The more teams need to participate in access design, the more valuable a readable and auditable policy layer becomes. The governance challenge is that shared authorship increases the blast radius of weak approval design, so organisations should pair policy readability with tighter publication controls and stronger evidence capture.

Identity programmes should expect authorization to move closer to product governance. That shift changes how IAM teams work with application owners, because permission changes become a recurring cross-functional decision rather than an occasional engineering ticket. Security teams will need clearer ownership boundaries, and they should align policy review with the same discipline they apply to other privileged changes. For background on controlled identity change management, see NHI Lifecycle Management Guide and NIST Cybersecurity Framework 2.0.

For practitioners

• Move authorization rules into versioned policy files Externalize access logic from application code so permissions can be reviewed, diffed, and rolled back like other controlled configuration changes. Keep policy ownership explicit and require change records for every edit.
• Require pull-request approval for every policy change Use a standard review workflow for policy edits, with separation of duties between the requester and approver. Pair that with automated validation so unsafe syntax or unintended access paths are caught before deployment.
• Define approval boundaries for non-engineer policy authors Allow product or security staff to draft policy, but limit who can approve and publish changes into production. This keeps shared authorship from becoming uncontrolled access administration.
• Monitor policy distribution as a privileged control plane Track who can distribute policies, where policy versions are deployed, and whether every PDP instance is running the expected revision. Treat distribution failures as governance incidents, not routine config drift.

Key takeaways

• Readable policy-as-code can widen participation in authorization without removing the need for governance.
• Embedding policy in Git creates a stronger audit path, but only if approval and validation are enforced.
• The main operational shift is from engineering bottleneck to controlled cross-functional ownership of access rules.

Key terms

• Policy-as-Code: Policy-as-code is the practice of writing access rules in version-controlled text files instead of burying them in application logic. It makes authorization easier to review, test, and audit, but it only works well when the surrounding change process is controlled and enforced.
• Fine-Grained Authorization: Fine-grained authorization means access decisions are based on specific conditions such as role, resource, action, or context rather than broad account-level permissions. It supports tighter control, but it also increases governance complexity because more rules must be maintained, reviewed, and evidenced.
• Policy Decision Point: A policy decision point is the component that evaluates a request against policy and returns allow or deny. In governed environments, it separates decision logic from the application, which improves consistency and auditability when the policy source and distribution path are tightly controlled.
• Separation Of Duties: Separation of duties is the control principle that splits request, review, and approval across different people or roles. In authorization governance, it reduces the chance that one author can both create and silently approve access changes, which is especially important when policies are editable by non-engineers.

Deepen your knowledge

Policy-as-code authorization and lifecycle governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is moving permission design closer to product and security ownership, the course is a strong fit.

This post draws on content published by Cerbos: policy-as-code authorization for non-engineers. Read the original.