Role-Based Access Control

!

Enterprise feature — RBAC is available on superglue Enterprise plans. Contact us to learn more.

superglue RBAC controls which organization resources each user can access and what they can do with them. The same access rules apply across the dashboard, agent, API, SDKs, schedules, and MCP servers.

superglue RBAC fundamentals

superglue uses an allowlist model based on resource grants. A user can access a resource when at least one grant gives them the required permission. Grants can cover a specific resource or all current and future resources of one type.

The resources governed by RBAC are:

Resource	What access controls
Tools	Who can find, run, change, and share saved tools
Systems	Who can view, use, test, and change connected-system configurations
Credentials	Who can use or maintain a saved credential set for a connected system
Playbooks	Who can view, use, change, and share reusable agent playbooks

How users receive access

Resource grants reach users in three ways:

• Roles: Admins grant access to the Member role or custom roles and assign users to those roles.
• Direct sharing: A resource can be shared with a specific user for an individual exception.
• Ownership: The creator of a resource retains owner access so they can continue to manage it.

Roles provide durable team-level access. Direct sharing handles one-off collaboration without changing a team’s role. Ownership protects the creator’s ability to manage their resource and cannot be removed from Access Rules.

Effective access is additive

superglue combines every grant that applies to a user: their base role, custom roles, direct shares, and ownership. The most permissive grant wins. If one source grants Viewer and another grants Editor, the user’s effective access is Editor.

There are no deny rules that override an existing grant. Removing one grant only removes access if the user has no equal or stronger grant from another source.

Viewer and Editor permissions

Permission	What it means
Viewer	Can find and use the resource, such as running a tool or using a credential, but cannot edit it
Editor	Includes Viewer access and allows the resource to be changed; applicable sharing and management actions are also enabled

Credential access is deliberately narrower: Viewer allows a credential set to be used, while Editor allows its name and secret values to be updated. Only credential owners and admins can change who the credential is shared with.

Access follows resource dependencies

A grant to one resource does not silently grant access to everything it depends on. To run a tool, a user needs:

1. Viewer access to the tool.
2. Viewer access to every system the tool calls.
3. Access to a usable credential set for those systems.

When a tool is shared, superglue also grants the recipient the missing Viewer access to its required systems. Credentials are never shared automatically; the recipient must use their own credential set or receive a separate credential grant.

If any required access is missing, superglue blocks the action instead of running it with broader organization access.

Configure roles and role-level access

Every organization member has one base role:

Base role	What it means
Admin	Full organization access, including users, roles, resource access, API keys, and settings. This role is fixed.
Member	Standard team-member access. Admins configure the resources and permissions granted to everyone with this role.

Admins can also create custom roles for teams, departments, or responsibilities. Users can have multiple custom roles in addition to their base role.

Open Access Rules from the sidebar to configure roles. For each resource type, an admin can grant Viewer or Editor access to either:

• All current and future resources of that type.
• A selected set of tools, systems, credentials, or playbooks.

Assign base and custom roles from Organization. The Admin role is read-only, while the Member role’s resource access and custom roles can be configured under Access Rules.

Share individual resources

Direct sharing adds user-specific access without changing role-level rules. Use the Share action on a tool, system, credential, or playbook to grant Viewer or Editor access to an organization member. The dialog also shows access inherited from roles and ownership, making it clear why each person can access the resource.

For tools, sharing is run-ready at the configuration level: required-system access is included when needed. Credential access remains separate so secret-bearing resources are only shared deliberately.

Review effective access by user

Admins can open Access Rules → Users to review the effective access of an individual member. The view combines role-level access, direct shares, and ownership and identifies the source of each permission.

Use this view to:

• Understand why a member can access a resource.
• Add, change, or remove a direct share.
• Confirm whether a role or ownership still grants access after a direct share is removed.

Role-derived access is changed on the role, while ownership is not editable from Access Rules. This keeps the source of each permission explicit.

Member experience

Members only see the resources they can access. Viewer access provides a read-only configuration experience while still allowing the resource to be used. Editing and management controls require Editor access and are otherwise hidden or disabled.

Recommended admin workflow

1. Configure the Member role as the safe baseline for every organization member.
2. Create custom roles for durable team access, such as Sales, Support, Finance, or Data Operations.
3. Grant access only to the resources each role needs.
4. Assign users to base and custom roles from Organization.
5. Use direct sharing for individual exceptions instead of broadening a role unnecessarily.
6. Periodically review Access Rules → Users to confirm direct access is still intentional.