Hi, community 😊 Hope the week’s going well! We just published a guide on who owns authorization in a large engineering organization, and part of the answer is a file you probably already have,

CODEOWNERS

. When authorization rules are scattered through application code, ownership turns into an org chart argument. The identity team’s job ends once the user is logged in, every product team writes its own permission checks, and security has no single place to review any of it. Once the rules live as policies in one repository, the question has a literal answer.

CODEOWNERS

says which team owns which policy, the pull request history shows who approved each change, and CI shows the policy was tested before it shipped. The guide builds the rest of the ownership model around that. A platform team runs the service that makes each allow or deny decision and keeps the audit logs, product teams own the policies for what they build, security owns the standard and the review, and the identity team keeps the user attributes those decisions rely on accurate. It also covers how to try this on one workflow first, like a support tool that needs write access to production, so the first team sees a permission change go out as a policy commit rather than a code deploy. Full write-up here: cerbos.dev/blog/who-owns-authorization-in-large-engineering-organization