The Manual

Roles & permissions

Which permissions a Discord bot actually needs

Which permissions a Discord bot actually needs — a permission-by-feature table, the three riskier than they look, and why intents are not permissions.

Time
7 min
Topic
Roles & permissions
Published
8 September 2026

Grant permissions by job, not by default. Most bots need View Channel, Send Messages, Embed Links and Read Message History, plus one or two more for whatever they actually do. Administrator is never a technical requirement — it is a shortcut past working out which four permissions the bot wanted, and it costs far more than it saves.

This page is the table you can work from, then the parts of the model that make permissions behave in ways people do not expect.

The three-layer model

Every “why can the bot not do this” question resolves against three layers, in this order.

1. Server permissions. What the bot’s role grants across the whole server. Set at Server Settings, then Roles.

2. Channel overwrites. Per-channel allow and deny, and they beat the server default. A red cross here defeats a green tick there. This is the layer that produces silent failures, because the role page still shows the permission as granted.

3. Role position. Not a permission at all, but it gates every role operation. Discord states it plainly: “A bot can grant roles to other users that are of a lower position than its own highest role.” A bot with every permission and a bottom-of-the-list role cannot hand out anything.

One exception cuts across all three: Discord’s documentation notes that “ADMINISTRATOR overrides any potential permission overwrites, so there is nothing to do here.” That is convenient and it is exactly why it is dangerous — see why you should not give a bot Administrator.

Role hierarchy, explained properly covers layer three in full.

Which permission does each feature need?

Work down this table for the features you actually use and grant nothing else. It covers what a general-purpose bot does; the exact list for your bot will be on its own documentation.

The bot does thisIt needs
Replies to a commandView Channel, Send Messages
Posts an embedEmbed Links
Posts a generated image or cardAttach Files
Reads back past messagesRead Message History
Deletes messages, purgesManage Messages
Pins a messageManage Messages
Reaction-role panelsManage Roles, Add Reactions, Read Message History
Button or dropdown role panelsManage Roles
Grants any role at allManage Roles, and a role position above the granted role
Kicks membersKick Members
Bans and unbansBan Members
Times members outModerate Members
Renames membersManage Nicknames
Creates ticket channelsManage Channels, Manage Messages
Creates temporary voice roomsManage Channels, Move Members
Logs with a webhookManage Webhooks in the log channel
Shows who performed an actionView Audit Log
Manages Discord’s AutoMod rulesManage Server
Resolves who invited a memberManage Server
Slowmode, locking a channelManage Channels

Two rows on that list are worth pausing on, because they are the two people most often grant without knowing why the bot asked.

View Audit Log is what turns “a channel was deleted” into “Dave deleted a channel”. Any bot that reports an executor on its log embeds needs it, and Discord requires the VIEW_AUDIT_LOG permission to read those entries at all. It is a read-only permission and it is a reasonable grant.

Manage Server is not. It is genuinely required for two narrow jobs — managing Discord’s AutoMod rules, where the documentation states that users “are required to have the MANAGE_GUILD permission to access all Auto Moderation resources”, and reading the server’s invite list to work out who invited a new member. It also lets the holder change the server name, region, invites and integrations. Grant it when the bot does one of those two jobs, and not as a convenience.

Permissions that are riskier than they look

Ranked by how much damage a compromised or badly written bot could do with each.

PermissionWhat it really allows
AdministratorEverything, including bypassing every channel restriction. See the separate article.
Manage RolesEditing and granting any role below its own — including permissions on those roles
Manage ChannelsDeleting every channel in the server. There is no undo.
Manage WebhooksCreating a webhook that can post as anyone, and reading existing webhook URLs
Ban MembersRemoving anyone below it in the hierarchy, in bulk
Manage ServerRenaming the server, changing invites, adding and removing integrations
Mention EveryonePinging the entire server, and bypassing channel-level mention restrictions

None of these is unreasonable in itself — a moderation bot genuinely needs Ban Members, a ticket bot genuinely needs Manage Channels. The question is whether this bot needs this permission for something you asked it to do.

Intents are not permissions

This is the distinction that explains a large share of confused permission debugging, and almost nothing explains it.

Permissions decide what a bot may do in your server. You control them.

Intents decide what a bot is allowed to receive from Discord. The bot’s developers control them, and you cannot change them from your server at all.

Discord gates three intents as privileged: GUILD_PRESENCES, GUILD_MEMBERS and MESSAGE_CONTENT. Its documentation states that “For verified apps (required for apps in 100+ guilds), the intent must also be approved after the verification process to use the intent.”

The practical consequences:

  • A bot without GUILD_MEMBERS never learns that anyone joined, so welcome messages and auto-roles do nothing no matter what you grant it.
  • A bot without MESSAGE_CONTENT cannot read what messages say, so prefix commands and word filters stop, while slash commands are unaffected.
  • No permission you grant fixes either. If every join-driven feature is dead at once, this is why.

The two-factor requirement

Rare, invisible and worth knowing about before it costs you an afternoon.

Discord’s permission documentation states: “These permissions require the owner account to use two-factor authentication when used on a guild that has server-wide 2FA enabled.” The list includes Kick Members, Ban Members and Manage Roles.

So a server with the 2FA moderation requirement turned on refuses those actions from a bot whose owner account does not have 2FA enabled. The symptom is every moderation action failing at once while everything else works, and only the bot’s developer can resolve it.

How to audit what a bot already has

Do this once for every bot in your server. It takes ten minutes and it is the single most useful security exercise available to a server owner.

  1. Server Settings, then Roles. Find each bot’s role. Read its permission list and ask, per permission, which feature you use needs it.
  2. Check the position. A bot’s role should be as low as it can be while still sitting above the roles it manages. High is not safer; high is more dangerous.
  3. Server Settings, then Integrations. This lists every installed app, including ones added by someone who has since left. Remove what you do not recognise.
  4. Check the channel overwrites on your most sensitive channels. A bot with server-wide View Channel can be denied at channel level, and that is a legitimate way to keep it out of staff discussions.
  5. Repeat after a permissions change. A bot re-invited with a wider scope gets a new permission set, and it does not tell you what changed.

Configuring a bot without granting Administrator to a person

The mirror image of the same problem, and it deserves naming. Discord’s own permission model is coarse: to let a moderator configure one bot feature, you generally have to give them Manage Server or Administrator, which also lets them change everything else.

Some bots solve this on their own side. Vetox ships an Access Control layer that narrows which dashboard sections a given role or user may open — 40 grantable sections across 11 groups, enforced server-side on every API request rather than only in the sidebar. With it on, an administrator who is not on the list sees only the overview page. It has a self-protection switch so nobody can grant themselves more access, and it is available from the Max plan.

That decouples “may configure the auto-moderation rules” from “may delete the server”, which is the right shape for a staff team past a handful of people. Where a bot offers something equivalent, use it before you widen anyone’s Discord permissions.

Common questions

What is the minimum permission set for a general-purpose bot? View Channel, Send Messages, Embed Links, Read Message History. That is enough for a bot to talk. Add Manage Roles if it hands out roles, Manage Messages if it deletes them, and the moderation permissions only if it moderates.

The bot asks for Administrator in its invite link. Is that normal? It is common and it is avoidable. Most invite links are generated with a permission calculator, and you can generate a narrower one yourself from the bot’s application ID. If the bot genuinely will not work without it, that is a decision to make deliberately rather than by clicking through.

Does a channel override let me keep a bot out of a private channel? Yes — deny View Channel for the bot’s role on that channel. The exception is a bot with Administrator, which overrides overwrites entirely.

Why does the bot’s role say Manage Roles but it still cannot assign one? Position. The role it is trying to grant sits above the bot’s own highest role. Why your bot cannot assign a role covers that and the four other causes, and Missing Permissions errors covers the error message it produces.

Sources and verification

Checked

  1. Discord developer docs — Permissions (opens in a new tab)
  2. Discord developer docs — Gateway intents (opens in a new tab)
  3. Discord developer docs — Auto Moderation (opens in a new tab)
  4. Discord developer docs — Audit log (opens in a new tab)

How we verify