Role-Based Access Control

Role-Based Access Control (RBAC) controls who can access tools and systems in your organization. It is designed for two everyday admin tasks:

• Give teams the right baseline access through roles.
• Share individual tools or systems with specific people when they need direct access.

RBAC applies consistently across the app, API, SDKs, schedules, and MCP. If a user or API key cannot access a tool or one of its required systems, superglue blocks the action instead of silently running it with broader organization access.

​

Permissions

Tools and systems use two resource permissions: Editor access always includes viewer access.

​

Roles

Every member has exactly one base role: The Member role cannot be renamed or deleted, but admins can configure which tools and systems it grants from Control Panel -> Access Rules. Admins can also create custom roles for teams, departments, or environments. A custom role can grant viewer or editor access to all tools/systems, or to specific tools/systems. Assign base and custom roles from Control Panel -> Organization. Configure what each role grants from Control Panel -> Access Rules -> Roles.

​

Effective Access

A user’s effective access is the combination of:

• Their base role.
• Any custom roles assigned to them.
• User-specific access from ownership, direct sharing, or admin edits in the Users tab.

Access is additive. If one role gives viewer access and another gives editor access, the user has editor access. There are no deny rules that subtract access granted somewhere else. When a user creates a tool or system, they keep owner-level editor access to it. Owner access is shown separately in the access UI and cannot be removed from Access Rules.

​

Tools And Required Systems

Tools depend on the systems they call. A user needs access to the tool and viewer access to each required system for the tool to be visible and runnable. When an admin adds a tool to a role in Access Rules, the UI also grants viewer access to any required systems that role does not already have. If a role has All tools, those tools are still subject to required system access. This is why a role should usually be reviewed in pairs:

• Tool Access decides which tools a user can see and run.
• System Access decides which systems those tools are allowed to call.

​

Direct Sharing

Editors, owners, and admins can share a saved tool or system with other organization members. Viewers cannot share. Use the Share button on a tool or system to give a person viewer or editor access without changing their team’s role. The dialog also shows which roles already include access, so it is clear whether someone has access directly or through a role. Tool sharing is run-ready: when a tool depends on systems, superglue includes the access needed for the recipient to run it. System access stays visible and manageable on the system itself.

​

User-Specific Access

Admins can review user-specific access from Control Panel -> Access Rules -> Users. The Users tab shows:

• Effective access: what the user can access after combining roles and user-specific access.
• Personal system access: systems granted directly to that user.
• Personal tool access: tools granted directly to that user.

Use this tab when you need to audit why a member can access something, grant a one-off exception, or remove direct access that is no longer needed.

​

Member Experience

Members only see the tools and systems they can access. When they have viewer access, the app shows a read-only experience: they can view and run/test the resource, but editing and sharing controls are disabled or hidden. When a member has editor access to a tool or system, they can share it with the teammates who need it. Admins do not need to handle every exception; roles set the durable guardrails, and editors can manage day-to-day collaboration on the resources they own or maintain.

​

Admin Workflow

For a healthy RBAC setup, admins should set durable guardrails and let resource owners handle day-to-day sharing:

1. Configure the Member role for the baseline access every member should have.
2. Create custom roles for durable team access, such as Sales, Support, or Finance.
3. Use editor permissions for members who should maintain resources and decide who else needs access.
4. Assign users to roles from Control Panel -> Organization.
5. Encourage editors and owners to use Share instead of routing every one-off access request through an admin.
6. Periodically review Access Rules -> Users to confirm direct access is still intentional.