RBAC & Permissions

RBAC Overview

SYNTHET's Role-Based Access Control (RBAC) system provides granular, capability-based permissions far exceeding Discord's built-in permission system. Control exactly what each Discord role can do with fine-grained policy management, audit trails, and emergency access controls.

What is RBAC?

Role-Based Access Control is a security model that defines what users can do based on their roles. Instead of granting permissions directly to users, permissions are assigned to roles, and users inherit permissions from their roles.

Traditional Permissions

Discord's built-in permissions are coarse: "Allow banned users" or "Allow moderating members". Limited granularity.

SYNTHET RBAC

Capability-based permissions: "Allow moderation.ban", "Allow economy.admin". Granular control over each action.

SYNTHET's RBAC system lets you define exactly which roles can perform which actions across all modules, with centralized management, audit trails, and emergency access controls.

Why Granular Permissions Matter

Fine-grained permissions protect your server in critical ways:

Principle of Least Privilege

Users get only the permissions they need for their role. A junior moderator can ban members but not delete channels. A bot can moderate but not access economy systems.

Damage Containment

If a moderator account is compromised, the attacker can only do what that role permits. They can't access economy, can't delete channels beyond their scope, can't grant new roles.

Audit Trail

Every permission check is logged. You can see exactly who tried to do what, when, and whether it was allowed. Critical for investigating incidents.

Operational Safety

Accidentally grant dangerous permissions once and your entire moderation system is at risk. SYNTHET's granular system means mistakes have limited blast radius.

How SYNTHET RBAC Differs from Discord Permissions

SYNTHET's system is purpose-built for fine-grained control beyond Discord's limitations:

Capability-Based vs Permission-Based

Discord: "Allow ban members" (everyone or no one, server-wide)

SYNTHET: "moderation.ban" capability can be: allowed for role A, denied for role B, limited to specific channels for role C, allowed with time limits, etc.

Scoped Permissions

Discord: Channel overrides exist but are limited to built-in permissions only

SYNTHET: Any capability can be scoped to GUILD, CATEGORY, or CHANNEL. A role can moderate #general but not #off-topic.

User-Level Overrides

Discord: Overrides are based on roles only. Exceptions require additional roles.

SYNTHET: Individual users can have capability exceptions independent of their roles. A user can have temporary elevated permissions without changing their role.

Risk-Based Capability Tiers

Discord: No distinction between low-risk and high-risk permissions at the system level

SYNTHET: Capabilities are assigned risk tiers (LOW, MED, HIGH, CRITICAL). Critical actions may require additional confirmation or multi-user approval.

Comprehensive Audit Trail

Discord: Audit log shows actions but not permission decisions

SYNTHET: Every permission check is logged: who, what capability, decision, reason code, timestamp. Queryable and searchable for debugging.

Key Concepts

Understanding these foundational concepts is essential to using SYNTHET RBAC effectively:

Policies

A Policy is the complete permission ruleset for your server. It defines:

  • •Which roles exist and their priority order
  • •Which capabilities each role can grant or deny
  • •Scope restrictions (server-wide, per-channel, per-category)
  • •Global settings (admin bypass, break-glass mode, etc.)

Policies are versioned, so you can roll back to a previous configuration if needed.

PolicyRoleBindings

Maps Discord roles to permission policies. When a user joins with Discord role "Moderator", SYNTHET checks what capabilities the Moderator PolicyRoleBinding grants.

Example: Discord role "Moderator" (ID: 12345) is bound to PolicyRoleBinding "moderator_policy" which allows {moderation.ban, moderation.mute, moderation.warn}.

CapabilityGrants

Defines what a role can do. Each grant specifies:

  • •Capability: e.g., "moderation.ban", "economy.admin", "rbac.manage"
  • •Effect: ALLOW or DENY
  • •Scope (optional): GUILD-wide, CATEGORY-specific, or CHANNEL-specific

Overrides

User-specific exceptions to role-based permissions. An override allows (or denies) a specific capability for a specific user, regardless of their roles.

Example: User "Alice" normally can't access RBAC management, but you grant her a temporary "rbac.manage" override for 24 hours while setting up new policies.

Scopes

Defines where a permission applies:

  • •GUILD: Server-wide permission
  • •CATEGORY: Permission applies only to channels in that category
  • •CHANNEL: Permission applies only to that specific channel

Risk Tiers

Every capability is assigned a risk level:

  • •LOW: Safe operations like viewing information (e.g., "moderation.view_logs")
  • •MED: Moderate impact operations (e.g., "moderation.warn", "economy.adjust")
  • •HIGH: Significant impact operations (e.g., "moderation.mute", "moderation.ban")
  • •CRITICAL: Destructive operations (e.g., "moderation.nuke", "rbac.manage", data deletion)

Policy System

Policies are versioned configurations that define all RBAC rules for your server:

Policy Versions

Every change to your policy creates a new version. You can view historical versions, compare changes, and rollback to previous configurations. Versions are timestamped and tracked with who made changes.

Policy Templates

SYNTHET provides starter policy templates:

  • •Permissive: Trusts all roles broadly. Good starting point for small servers.
  • •Balanced: Standard tier-based permissions. Recommended for most servers.
  • •Strict: Minimal permissions by default, explicit grants only. Good for security-conscious servers.
  • •Lockdown: Emergency mode, minimal permissions. Use during incidents.

Admin Controls

SYNTHET provides emergency and administrative controls:

Admin Bypass

Server administrators (members with the "Administrator" Discord permission) can optionally bypass RBAC checks entirely.

This setting is configurable: Enable it for flexibility, disable it to enforce RBAC on everyone including admins. Disabled is more secure.

Break-Glass Mode

An emergency access mode accessible only to the server owner. If RBAC is misconfigured and everyone is locked out of critical actions, the owner can toggle break-glass to temporarily grant all permissions.

Every break-glass activation is logged and can be reviewed later. Intended for emergency situations only.

Discord Gate Requirement

Option to require users pass Discord's built-in permission checks before SYNTHET evaluates RBAC. Acts as a secondary gate. If a user doesn't have Discord's "ban members" permission, SYNTHET won't even check RBAC grants for ban capability.

Audit Trail

Every RBAC decision is logged for compliance and security:

What Gets Logged

For each permission check:

  • •Who made the request (user ID, username)
  • •Which capability was requested (e.g., "moderation.ban")
  • •Final decision (ALLOW or DENY)
  • •Reason code (which grant matched, admin bypass, break-glass, etc.)
  • •Request source (WEB, BOT, API)
  • •Exact timestamp with millisecond precision

Retention & Cleanup

Audit logs are retained for a configurable period (default: 90 days). After expiration, logs are automatically deleted. This balances security auditing with storage efficiency.

Querying Logs

Search audit logs by user, capability, decision, date range, and source. Export logs for analysis or compliance reporting.

How Permission Checks Work

When a user attempts an action, SYNTHET evaluates their permissions:

  1. 1. Check OverridesUser-level overrides take precedence. If user has an override for this capability, apply it and log the result.
  2. 2. Check Admin BypassIf adminBypassEnabled is true and user is a server admin, grant permission (if not explicitly overridden).
  3. 3. Check Break-GlassIf break-glass mode is active, grant permission.
  4. 4. Evaluate GrantsFor each role the user has, check grants in priority order. Evaluate scopes (GUILD, CATEGORY, CHANNEL). DENY wins at same priority; higher priority overrides lower.
  5. 5. Check DefaultIf no grant found, check if capability is defaultPublic (default-allowed).
  6. 6. Log ResultLog the decision with reason code and return ALLOW or DENY.

Tip: The Simulator tool lets you test this exact process without affecting real users. Input a user and capability to see the decision path.

RBAC Best Practices

  • 1.Start strict, relax over time: Begin with Strict policy template, then grant capabilities as you discover what roles need.
  • 2.Use role hierarchy: Create a clear role structure (Junior Mod → Senior Mod → Admin → Owner). Enforce via priority ordering.
  • 3.Scope permissions: Don't grant GUILD-wide when CHANNEL-specific works. Limits blast radius if role is compromised.
  • 4.Review audit logs regularly: Check who accessed what permissions. Patterns reveal suspicious activity.
  • 5.Use overrides for temporary access: Don't change role permissions permanently for one-time needs. Grant temporary overrides instead.
  • 6.Disable admin bypass if possible: Enforce RBAC on everyone. Creates accountability and prevents accidents from overprivileged admins.
  • 7.Test with Simulator: Before granting critical permissions, test with the Simulator to verify expected behavior.
  • 8.Document your policy: Keep notes on why each role has what grants. Helps debugging and onboarding new admins.
← Security DashboardPolicy Setup →