Notifications
Clear all
Topic starter
09/06/2026 11:02 pm
TL;DR: Shift-left development pushes authorization closer to developers, but scaling complexity creates hidden debt in fine-grained access control, according to Cerbos’ Civo Navigate talk. The core lesson is that authorization tooling must stay simple, fast, secure, extensible, scalable, and reliable or teams will keep rebuilding the same governance gaps.
NHIMG editorial — based on content published by Cerbos: a recap of Emre Baran's talk on building developer tools in a shift-left world
Questions worth separating out
Q: How should security teams govern authorization in fast-scaling software environments?
A: They should centralise policy intent, reduce duplicated access logic, and make enforcement easy enough that developers do not rebuild it locally.
Q: Why does shift-left development create authorization risk?
A: Shift-left development increases authorization risk because control decisions move closer to product teams before the architecture has stabilised.
Q: What breaks when authorization is rebuilt inside each service?
A: Consistency breaks first, then visibility and reviewability.
Practitioner guidance
- Map authorization logic before the next scale jump Document where fine-grained permissions are enforced today, including application code, service middleware, and shared libraries.
- Treat developer experience as part of security design Test whether developers can implement authorization without bypassing the shared control plane.
- Standardise policy expression across teams Use a common policy model so product, data, and platform teams do not invent separate access rules for similar decisions.
What's in the full article
Cerbos' full blog post covers the developer-tooling details this post intentionally leaves at the governance level:
- The six design principles Emre Baran used to evaluate developer tools, including speed, extensibility, and reliability.
- The full train-crash scaling metaphor and how it maps to growing product teams and microservices complexity.
- Concrete examples of simple API design from developer platforms that reduce integration friction.
- The open-source rationale behind the tool and why inspectability matters for developer adoption.
👉 Read Cerbos' talk recap on shift-left authorization and developer tools →
Shift-left authorization and the governance gap teams miss?
Explore further
10/06/2026 1:14 am
Shift-left authorization only works when policy can survive scale. The talk points to a recurring identity problem: authorization is easy to sketch at MVP stage and difficult to preserve once teams, roles, and services multiply. Fine-grained access control is not just a code concern, it is a governance concern because policy drift becomes structural as the application surface expands. The implication is that access decisions need a durable operating model, not just embedded logic.
A few things that frame the scale:
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to the Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which is why fragmented access governance becomes a scale problem, not just an ops problem.
A question worth separating out:
Q: How do teams know whether authorization tooling is working well?
A: They should look for low duplication, fast integration, stable enforcement under load, and few local bypasses. A healthy authorization model is one that developers can adopt without recreating logic in application code. If teams keep inventing custom checks, the platform is not governing access effectively.
👉 Read our full editorial: Shift-left authorization exposes the scaling gap in developer tools
