What is the difference between an organization admin and a workspace admin?

An organization admin governs tenant-wide settings — identity, SSO/MFA policy, the role catalog, and which workspaces exist. A workspace admin manages membership, spaces and projects inside a single workspace and cannot reach into other workspaces or change org-level policy. Scoping the two roles this way keeps blast radius small: a workspace admin can move fast locally without holding keys to the whole tenant.

Why not just give everyone a broad role to avoid access friction?

Broad roles feel convenient but they defeat least privilege and separation of duties, widen the blast radius of a compromised account, and make audit logs meaningless because everyone could have done anything. It is better to grant narrowly and add scoped access on request; a good platform makes targeted grants cheap enough that broad roles are unnecessary.

How does RBAC interact with approval workflows?

RBAC decides who may perform or request an action; approval workflows decide whether a requested action proceeds. They are complementary. Separation of duties is usually enforced by combining them — a role can author or propose a change, but a different role must approve it before it takes effect, and both events are recorded in the audit log.

Should AI usage and coding agents be governed by the same roles?

Yes. AI provider configuration, API keys and coding agents are privileged capabilities. Configuring providers or budgets, adding a key, or letting an agent open a pull request should each require an appropriate scoped role, and the resulting actions should route through the same approval gates and audit trail as any other sensitive operation.

How RBAC should work across organizations, workspaces and projects

A practical guide to scoping role-based access control across an org→workspace→project hierarchy, applying least privilege and separation of duties, and designing durable role sets.

Estimated time: 9 min · Difficulty: intermediate

Overview

Explain how to design and reason about role-based access control that is scoped to a nested org→workspace→project hierarchy, so access stays least-privilege and auditable as teams scale.

Organization and workspace administrators designing access models, plus project managers, BAs, QA leads and developers who need to understand what their roles can and cannot do.

What RBAC is trying to solve

Role-based access control (RBAC) answers a deceptively simple question: who is allowed to do what, and where? Instead of granting permissions to individuals one at a time, RBAC groups permissions into roles that map to job functions — administrator, project manager, tester, developer, viewer — and then assigns people to roles. This makes access understandable, reviewable and repeatable as an organization grows.

In a software delivery platform the "where" matters as much as the "what". A test lead should be able to manage test plans in one project without touching finance's projects, and an organization administrator should govern tenant-wide settings without needing to be added to every project by hand. That is why access is best expressed against a hierarchy rather than a flat list.

Scope: the org → workspace → project hierarchy

A nested hierarchy — Organization → Workspace → Space → Project — gives you natural scopes to attach roles to. A grant made high in the tree can cascade downward; a grant made low stays contained.

Organization scope covers tenant-wide concerns: identity and SSO/MFA policy, the role catalog, workspace creation, and cross-cutting governance. Keep this membership small.
Workspace scope covers a business unit or product line: its spaces, projects and membership. A workspace admin operates freely inside their workspace and is invisible to others.
Project scope covers the delivery modules — Requirements, Planner, Testing and Defects — for one project. Most day-to-day roles live here.

The guiding rule is to grant at the lowest scope that does the job. Assigning someone a project role gives them exactly one project; assigning an org role because it was faster hands them the entire tenant. Scope discipline is what keeps a growing platform from drifting into everyone-can-see-everything.

Least privilege

Least privilege means each role carries only the permissions its function requires, and nothing "just in case." A BA drafting requirements does not need to configure AI budgets; a tester executing runs does not need to change organization security policy. Narrow roles limit the damage a mistake or a compromised account can cause, and they make audit logs meaningful — if a role couldn't perform an action, you can rule it out during an investigation.

Least privilege is a practice, not a one-time setup. Access should be reviewed periodically and whenever someone changes teams, because the most common failure mode is not over-granting on day one — it is forgetting to revoke.

Separation of duties

Separation of duties (SoD) ensures that no single person controls a sensitive action end to end. The classic pattern is author versus approver: the person who proposes a change should not be the person who approves it. In delivery workflows this shows up in several places — reviewing AI-generated test cases before they are saved, approving a coding agent's pull request before merge, or signing off on release readiness. RBAC provides the raw capability split (who can author, who can approve); approval workflows enforce the sequencing. Together they make sure privileged outcomes always involve at least two roles, and both actions are recorded.

Common role designs

Most teams converge on a small, layered set:

Administrators — org and workspace variants that manage settings and membership at their scope.
Managers / leads — project managers, test managers who plan, assign and report but do not administer the tenant.
Contributors — BAs, developers and testers who create and edit work within their module (requirements, plans, executions, defects).
Reviewers / approvers — a role that can approve but is distinct from the authoring role, satisfying SoD.
Viewers / auditors — read-only access for stakeholders and audit, with no ability to change state.

Design the roles first, then assign people. Resist creating a bespoke role per person; a handful of well-scoped roles is easier to reason about and review than dozens of near-duplicates.

How KYXO helps

KYXO models RBAC directly on its Organization → Workspace → Space → Project hierarchy, so you can grant access at the scope a role actually needs — organization-wide, a single workspace, or one project — instead of over-exposing the tenant. Tenant isolation, MFA and SSO, and audit logs back the role model, and privileged capabilities such as AI provider configuration, BYOK keys and model budgets and coding agents are governed by the same scoped roles rather than treated as exceptions. Separation of duties is reinforced by human approval gates — for example, reviewers approving work that a different role authored — and every grant and approval feeds the end-to-end audit trail so access decisions stay explainable over time.

Tips

Start from job functions, not from people — design a small set of roles first, then assign users to them.
Grant at the highest scope only when the role genuinely needs org-wide reach; prefer assigning at the workspace or project level.
Separate who authors work from who approves it — the same person should not be able to both request and approve a sensitive change.
Review access on a schedule and when people change teams; stale grants are the most common source of over-permission.
Treat AI providers, keys and coding agents as privileged resources governed by the same role model, not as an exception to it.

Frequently asked questions

What is the difference between an organization admin and a workspace admin?: An organization admin governs tenant-wide settings — identity, SSO/MFA policy, the role catalog, and which workspaces exist. A workspace admin manages membership, spaces and projects inside a single workspace and cannot reach into other workspaces or change org-level policy. Scoping the two roles this way keeps blast radius small: a workspace admin can move fast locally without holding keys to the whole tenant.
Why not just give everyone a broad role to avoid access friction?: Broad roles feel convenient but they defeat least privilege and separation of duties, widen the blast radius of a compromised account, and make audit logs meaningless because everyone could have done anything. It is better to grant narrowly and add scoped access on request; a good platform makes targeted grants cheap enough that broad roles are unnecessary.
How does RBAC interact with approval workflows?: RBAC decides who may perform or request an action; approval workflows decide whether a requested action proceeds. They are complementary. Separation of duties is usually enforced by combining them — a role can author or propose a change, but a different role must approve it before it takes effect, and both events are recorded in the audit log.
Should AI usage and coding agents be governed by the same roles?: Yes. AI provider configuration, API keys and coding agents are privileged capabilities. Configuring providers or budgets, adding a key, or letting an agent open a pull request should each require an appropriate scoped role, and the resulting actions should route through the same approval gates and audit trail as any other sensitive operation.