GitHub-style authorization models expose the cost of permission sprawl

At a glance

What this is: This is a technical explainer on modelling GitHub-style permissions with Relationship-Based Access Control, showing how repository, team, and organization access can be expressed as relationships and computed permissions.

Why it matters: It matters because IAM teams need authorization patterns that scale across human, NHI, and delegated access models without hardcoding role logic into every application path.

👉 Read Authzed's article on modelling GitHub-style authorization with SpiceDB

Context

GitHub-style authorization gets hard because permissions do not sit in one flat layer. They flow through users, teams, repositories, and organization ownership, which means a simple role list cannot capture the real access model. That is the same structural problem IAM teams face when access needs inherit across nested resources and changing relationships.

In this pattern, the question is not just who has a role, but how that role propagates through the object graph. Relationship-based access control models the links between subjects and resources directly, which makes it a useful fit for complex application authorization and delegated admin scenarios. The same logic applies when teams need to govern service access, repo administration, or cross-object privilege inheritance.

For practitioners, the key issue is keeping authorization decisions aligned with the current state of the system. If relationships are not written and revoked correctly, the permission graph can drift from reality even when the schema looks sound.

Key questions

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. This keeps authorization aligned with the live state of the system and reduces brittle application logic. The key is to model the actual inheritance paths, not just the labels attached to users.

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. That makes the true access path harder to see and easier to forget during audits. Teams should review upstream relationships, not only the final role shown on the resource.

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. If a user joins or leaves a team, or a repository is created under an organisation, the tuple store must change at the same time. That is what keeps effective permissions accurate as the system evolves.

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.

Technical breakdown

Relationship-based access control for nested permissions

ReBAC models access as relationships between objects and subjects, then evaluates permissions by traversing those relationships. In the GitHub-style example, a repository does not just know whether a user is a writer. It can inherit access through a team membership, an organisation owner link, or a parent object traversal. That makes the schema closer to the business model than a simple RBAC table, because it can express who can do what across nested resources without duplicating rules in application code.

Practical implication: model access paths explicitly so inherited permissions are visible, testable, and revocable.

Permission inheritance through roles and arrows

The article’s central mechanism is permission composition. A permission like clone can include multiple roles, and an arrow traversal can pull authority from a related object such as the owning organisation. That means a change in one upstream relation can alter effective access across many downstream objects. The technical benefit is fewer hand-coded conditions. The technical risk is that hidden inheritance can surprise teams if they do not understand which upstream relation is actually granting access.

Practical implication: document every inheritance path and test effective permissions after each schema change.

State changes must write relationship tuples

In this model, the schema defines structure, but relationship tuples define live state. When a user joins a team, a repo is created, or access is revoked, the application must create or delete the corresponding tuple so checks reflect reality. If a relationship is missing, permission checks can fail silently even though the rest of the schema is correct. That is why authorization is not just a policy problem. It is also a data consistency problem between identity state and the permission graph.

Practical implication: tie every access change to an automated tuple write or delete in the same workflow.

Breaches seen in the wild

• Emerald Whale breach — exposed Git config files led to 15K secrets stolen and 10K repo compromises.
• GitLocker GitHub extortion campaign — GitLocker used stolen credentials to hijack GitHub repositories.

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

NHI Mgmt Group analysis

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.

Permission inheritance is the real governance surface in complex apps. The meaningful question is not whether a user is a writer or admin, but which upstream object grants that ability and how far the inheritance travels. Once privileges flow through parent objects, team membership, or organization ownership, the risk shifts from explicit assignment to hidden expansion. Practitioners should audit inherited access paths as carefully as direct grants.

Granularity should follow distinct decision needs, not schema ambition. The post’s point about avoiding unnecessary permission splits is operationally sound: if two actions always move together, one permission is enough. Over-granular schemas create maintenance debt, but under-granular schemas create overreach. Practitioners should design around real business distinctions, then split permissions only when a separate control decision is actually needed.

Access tuple hygiene is part of authorization security. The model only works if relationship data stays synchronized with real-world state changes. Missing object links, stale team memberships, or unrevoked access tuples can leave the schema logically correct but operationally wrong. Practitioners should govern relationship writes and deletes as security-critical events, not routine application updates.

From our research:

• 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.
• Authorization models that span workloads, service accounts, and delegation chains need lifecycle discipline as well as policy logic, which is why the Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs is the natural next step.

What this signals

Relationship graphs will become a standard governance pattern for complex applications. As organisations push more access decisions into dynamic services, the old habit of hardcoding authorization logic will keep breaking under change pressure. Teams should expect access design to move closer to schema-first governance, especially where teams, owners, and resources are deeply nested.

The operational signal is that authorization review will increasingly focus on inherited access, not just direct entitlements. That shifts programme attention toward tuple hygiene, object ownership, and the quality of relationship updates across change workflows.

For practitioners

• 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. Keep the schema close to the business model so effective permissions can be reasoned about without reading application code.
• 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. The aim is to make hidden privilege expansion visible before it reaches production.
• 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. Keep tuple updates in the same workflow as the business event that changed access.
• Keep permission granularity tied to actual decision points Only split permissions when users need different authorization outcomes in practice. If two actions always share the same access boundary, one permission is usually enough, but watch roadmap changes that will require a future split.

Key takeaways

• This post shows that complex authorization is governed best as a relationship graph, not a static role table.
• The practical risk is inherited access drift, where upstream objects silently expand or preserve downstream privileges.
• Practitioners should align schema design, tuple updates, and permission granularity with real business decision points.

Key terms

• Relationship-Based Access Control: A model that determines access by evaluating relationships between subjects and resources. Instead of assigning permissions only through static roles, the system computes effective access from linked objects, such as team membership or ownership paths. This makes it well suited to nested, delegated, and hierarchical authorization patterns.
• Permission Inheritance: The practice of allowing access on one object to flow into related objects through defined traversal rules. It reduces duplicate configuration, but it also creates hidden privilege paths that must be understood and reviewed. In complex systems, inheritance is often the real source of effective access.
• Relationship Tuple: A stored record that connects a resource, a relation, and a subject in the authorization graph. Relationship tuples are the live data that make schema rules meaningful, because access checks depend on them being current. If tuples are stale or missing, effective permissions no longer match the real system state.

Deepen your knowledge

Relationship-based access control and authorization design are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are designing nested access models or delegated permissions, it is worth exploring.

This post draws on content published by Authzed: modelling GitHub-style authorization with SpiceDB and AuthZed Cloud. Read the original.