RBAC Matrix Builder
Build a role-based access control matrix — add roles as rows and permissions as columns, then toggle who gets what in the grid. Analyze it for over-provisioned roles, separation-of-duties conflicts, near-duplicate roles to merge and permissions granted to everyone. Start from a SaaS or finance template and export to CSV or Markdown. Everything runs in your browser; nothing is uploaded.
Access matrix
6 roles × 9 permissions| Role \ Permission | |||||||||
|---|---|---|---|---|---|---|---|---|---|
Separation-of-duties rules
Each rule is a pair of permissions no single role should hold together. Matching is by case-insensitive text, so approve matches any permission containing "approve". A role holding both halves is flagged below.
Built and analyzed entirely in your browser — the matrix is never uploaded and no network calls are made. Safe for a real access model you are not ready to share.
What this tool is
- A free, in-browser RBAC (role-based access control) matrix builder: add roles as rows, resources or permissions as columns, and toggle which role gets which permission in a grid.
- Analyze the matrix to flag over-provisioned roles, separation-of-duties (SoD) conflicts from a configurable conflict list, near-duplicate roles that are candidates to merge, and permissions granted to everyone that could become a default.
- Starter templates for a SaaS application and a finance (purchase-to-pay) workflow give you a realistic matrix to edit instead of a blank grid.
- Export the finished matrix as CSV (for a spreadsheet) or Markdown (for a ticket, wiki or design doc).
- Everything runs client-side in your browser — no account, no upload, no network calls. Your role model never leaves the page.
What is role-based access control?
Role-based access control (RBAC) is the most common way to manage who can do what in a system. Instead of granting permissions to individual users one at a time, you grant permissions to roles — named bundles that match a job function — and then assign users to roles. A user inherits every permission of the roles they hold. The payoff is scale and clarity: you manage a few dozen roles instead of thousands of per-user grants, and an access review becomes a short, readable list rather than an unbounded one.
Roles vs permissions
A permission is the smallest unit of access: one action on one resource — read invoices, approve payment, delete workspace. A role is a set of permissions grouped to fit a job, such as Support Agent or Billing Admin. Users get roles; roles carry permissions. In the matrix, roles are the rows and permissions are the columns, and a mark in a cell means that role holds that permission. That grid — roles against permissions — is the access control matrix.
Least privilege
Least privilege says each role should hold only the permissions it actually needs. The security value is blast-radius containment: a compromised account can only reach what its roles could already reach, so a tight role limits the damage of any single failure. In practice, roles drift — grants get added for a one-off task and never removed. The analysis here flags over-provisioned roles: a role holding an outlier-high share of all permissions, which is where least-privilege cleanup usually starts.
Separation of duties
Separation of duties (SoD) is the rule that no single role can complete an entire sensitive process alone. The textbook case is finance: whoever can create a vendor must not also approve a payment, because together those two powers let one person invent a supplier and pay it. The same pattern is author versus approve, or request versus fulfill. This tool checks each role against a configurable list of conflicting permission pairs and flags any role that holds both halves, so you can split the duties across two roles.
How to read the analysis: over-provisioned roles point at least-privilege cleanup; SoD conflicts point at toxic permission combinations in one role; near-duplicate roles are merge candidates that cut role sprawl; and a permission everyone holds is a candidate to make a baseline default rather than a per-role grant. The checks are practical review aids that map to common access-review findings — not a certification against any one framework.
Frequently asked questions
What is RBAC (role-based access control)?
Role-based access control, or RBAC, is an authorization model where permissions are not granted to individual users directly but to roles, and users are assigned roles. A "role" is a named bundle of permissions that matches a job function — for example Billing Admin, Support Agent or Auditor — and a "permission" is a single allowed action on a resource, such as "read invoices" or "delete workspace". Because access is granted through roles, you manage a handful of roles instead of thousands of individual grants, and you can see at a glance what any job function can do. An RBAC matrix is the grid that lays this out: roles down the side, permissions across the top, and a mark in each cell where that role holds that permission.
What is the difference between a role and a permission?
A permission is the smallest unit of access: one action on one resource, like "approve payment", "export data" or "rotate secrets". A role is a collection of permissions grouped to fit a job. Users get roles; roles carry permissions; permissions gate actions. Keeping the two separate is the whole point of RBAC — when a job changes you adjust one role rather than re-granting permissions to every person who does that job, and when you review access you read a short list of roles instead of an unbounded list of per-user grants. In the matrix, roles are the rows and permissions are the columns.
What is the principle of least privilege?
Least privilege means every role (and every user) should hold only the permissions it genuinely needs to do its job, and nothing more. The security value is that a compromised account, an insider mistake or a stolen token can only reach what that role could already reach — so a tightly scoped role limits the blast radius of any single failure. In an RBAC matrix, violations of least privilege show up as over-provisioned roles: a role carrying a large, outlier share of all the permissions, which usually means it has accumulated grants it no longer needs. This tool flags those roles so you can trim them.
What is separation of duties, and how does this tool check it?
Separation of duties (SoD), also called segregation of duties, is the control that no single role should be able to carry out an entire sensitive process on its own. The classic example is finance: the person who can create a vendor should not also be able to approve a payment to that vendor, because together those two powers let one person set up a fake supplier and pay it. Other examples are author versus approve, or request versus fulfill. This tool checks SoD against a configurable list of conflicting permission pairs: for each role, if that role holds both halves of a conflicting pair, it is flagged as an SoD violation so you can split the duties across two roles.
Is the matrix sent anywhere, and is this an official RBAC standard?
Nothing is sent anywhere. The builder, the analysis and both exports run entirely in your browser with no network calls, so your role and permission model stays on your machine. The analysis is a practical review aid — least-privilege, separation-of-duties, duplicate-role and over-broad-permission heuristics that map to common access-review findings — not a certification against a specific standard such as NIST RBAC or an auditor framework. Use it to clean up a model quickly and to prepare for an access review, then validate against whatever policy or framework your organization is held to.