Challenge
Role-based access control looked simple until it didn’t. Human Managed’s team could see where RBAC would break first: nested roles, product packaging per client, and authorization logic scattered through API code. Every change meant editing source, rebuilding, pushing through dev and test, then production—slow, brittle, and hard to reason about.
Building a full attribute-based access control (ABAC) engine in-house was technically possible; the Chief Engineer for identity and APIs tried—and concluded it would burn too much engineering time for a startup-scale team. They needed fine-grained, client-tailored access without turning authorization into a permanent science project.
What they needed was a clear decision at the API layer—allow or deny—driven by policies their team could own, review in Git, and change without redeploying the whole platform.
Approach
Human Managed evaluated the market, circled back to Cerbos, and standardized on policies written in YAML with Google Common Expression Language (CEL) where expressions add power. Cerbos runs as a single binary, deploys with their CD pipeline (including Argo CD, manifests, and DNS), and sits behind a thin wrapper in their API framework so the rest of engineering barely touches it—correct policies in Git, and the enforcement path stays consistent.
The API builds a Cerbos request from the user’s token plus metadata loaded from the backend (they had moved to opaque tokens, which made attaching the right attributes straightforward). Cerbos returns a boolean; the API honors it. Troubleshooting stayed bounded: logs, policy tests in CI, and community support when something was unclear.
Impact
Authorization work shrank from a development cycle to a policy edit. The team describes changing permissions as roughly a five-minute task and tracing a bad decision as the same order of effort—time back for product work instead of permission archaeology.
Operational impact
Authorization centralized in policy instead of duplicated
if/elsechains across servicesEngineering and operations rarely need to operate Cerbos day to day; policy authors use documented validation flows
Time and cost
Roughly two weeks from production insertion (policies, CD, infrastructure, API wrapper, testing)—after earlier experiments and proof-of-concepts spread over a longer calendar period
Policy updates propagate in about a minute in their setup—no full redeploy for every rule tweak
Strategic value
Room to package capabilities per client without predicting every role combination in advance
A path that scales with the I.DE.A. framework (Intelligence, Decision, Action) without trapping decisions in code
Je Sum Yip, Chief Engineer (APIs for identity and authorization), described the shift in plain terms: feed conditions and attributes in, get true or false out — easier to explain across the organization than a lecture on ABAC theory.
Cerbos’s team responsiveness on Slack and quick turnaround on reported policy-caching issues reinforced confidence for a long-term dependency. Early documentation was a hurdle; that improved over subsequent releases.
The honest caveat from the same interview: understand what Cerbos is (a decision engine you call with context), not a drop-in database or web-app plugin. Once that mental model lands, integration choices get simpler.
