Notifications
Clear all
Topic starter
10/06/2026 10:57 pm
TL;DR: GitHub-style authorization can be modeled with SpiceDB and relationship-based access control, reducing complex org, team, and repository permissions to schema-driven checks that update as relationships change, according to Authzed. The practical lesson is that authorization design should be expressed in relationships and inheritance rules, not scattered across application logic.
NHIMG editorial — based on content published by Authzed: modelling GitHub-style authorization with SpiceDB and AuthZed Cloud
Questions worth separating out
Q: How should security teams model nested application permissions without hardcoding every rule?
A: Use relationship-based access control to represent users, groups, teams, and resources as linked objects, then derive permissions from those links at query time.
Q: Why do inherited permissions create more risk than direct role assignments?
A: Inherited permissions can expand access through parent objects, team membership, or ownership links without a new direct grant being obvious to reviewers.
Q: How do organisations prevent stale access when teams or repositories change?
A: Tie access updates to relationship writes and deletes whenever the underlying business state changes.
Practitioner guidance
- Model authorization as relationships, not only roles Map the real subject-to-resource paths in your application, including team membership, parent object traversal, and ownership inheritance.
- Trace every inherited permission path Inventory which upstream objects can grant access to downstream resources, then test the effective permission set after every schema change.
- Write and delete tuples on every state change Create the relationship record when access is granted, and remove it when access is revoked, a team changes, or a resource is created under a parent object.
What's in the full article
Authzed's full article covers the operational detail this post intentionally leaves for the source:
- Complete SpiceDB schema examples for users, organisations, teams, and repositories
- Concrete relationship tuples and permission checks for GitHub-style operations
- AuthZed Cloud setup steps for deploying and testing the permission system
- CLI examples that show how permission checks behave in practice
👉 Read Authzed's article on modelling GitHub-style authorization with SpiceDB →
GitHub permissions and ReBAC: what IAM teams should model first?
Explore further
12/06/2026 4:42 am
GitHub-style authorization is a relationship problem, not a role-list problem. The article shows that effective access is produced by links between users, teams, repositories, and organisations, not by isolated role labels. That is why ReBAC is structurally better suited than flat role mapping for nested administration, delegated control, and inherited privileges. Practitioners should treat authorization design as graph design, not just policy configuration.
A few things that frame the scale:
- 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts, according to The 2024 Non-Human Identity Security Report.
- 35.6% of organisations cite managing consistent access across hybrid and multi-cloud environments as their top NHI security challenge.
A question worth separating out:
Q: What should IAM architects watch for when adding finer-grained permissions?
A: Add granularity only when there is a genuine decision difference between actions. If every user who can manage one setting can manage another, separate permissions just create schema clutter and long-term maintenance cost. Split permissions when the product or governance model actually requires a different control boundary.
👉 Read our full editorial: GitHub-style authorization models expose the cost of permission sprawl
