Discord permissions explained

Rule 1: permissions add up

A member holds the union of the permissions of all their roles. If one role allows something, they can do it — even if ten other roles do not.

The direct, counter-intuitive consequence: adding a role never removes a right. Creating a “Restricted” role that allows nothing restricts nobody. To remove a right you must go through channel permissions (rule 3).

That is also why one badly set role cancels out everything else: someone only has to carry it.

Rule 2: hierarchy decides who can act on whom

Roles are ordered, highest to lowest, in server settings. That order changes nothing about the permissions themselves — it decides who can act on whom.

A member can only sanction, rename or manage members whose highest role sits strictly below theirs. At equal height, the action is refused.

The same rule applies to bots, and it is the first cause of “the bot does nothing”: if the bot role sits below the role it must grant, or below the member it must sanction, Discord refuses — whatever permissions it holds. Giving the bot Administrator changes nothing here.

The server owner escapes this rule: they can do anything to anyone, whatever the role list says.

Rule 3: channel overrides win

Every channel can override permissions, role by role and even member by member. Overrides have three states: allow (✓), not set (/) and deny (✗).

The evaluation order is: role permissions add up, then channel overrides apply on top. An explicit channel-level deny wins over any allow coming from a role.

It is the only way to take a right away from someone, and it is also where leaks hide: an override set six months ago on a private channel is invisible from the roles page.

1. For a private channel: deny View Channel to @everyone, then allow it for the relevant role.
2. Always prefer denying on @everyone over denying on each role: it is the only method that stays correct when you create a new role.
3. Leave not set everything you want neither to allow nor deny. A ✗ placed without reason eventually blocks someone, long after, with nobody remembering why.

The two permissions that deserve special care

• Administrator — grants EVERYTHING and ignores every channel override. An administrator sees your private channels, whatever their permissions. One or two accounts, no more, and never on a role that can be obtained automatically.
• Manage Roles — allows granting and editing roles below its own. It is an escalation permission: whoever gets it can give themselves the rest.

The test before adding a permission to a role that is granted automatically, bought, or earned by level: am I fine with the next account created today getting it within the minute?

The three classic failures

• “The bot won’t grant the role” → the target role sits above the bot role. Move the bot up.
• “This member sees a channel they shouldn’t” → they carry a role with Administrator, or a channel override explicitly allows them.
• “I removed the right and they still have it” → another of their roles grants it. Permissions add up: find the offending role rather than stacking denies.

How Kuratos helps

Kuratos does not replace Discord permissions — it builds on them. The Automatic roles module hands out the roles you defined, never widening their rights.

The thing to watch is the same as for any bot: the “Kuratos” role must sit above every role it grants or member it sanctions. Nothing warns you at configuration time; the button simply exists and does nothing.