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 this | It needs |
|---|---|
| Replies to a command | View Channel, Send Messages |
| Posts an embed | Embed Links |
| Posts a generated image or card | Attach Files |
| Reads back past messages | Read Message History |
| Deletes messages, purges | Manage Messages |
| Pins a message | Manage Messages |
| Reaction-role panels | Manage Roles, Add Reactions, Read Message History |
| Button or dropdown role panels | Manage Roles |
| Grants any role at all | Manage Roles, and a role position above the granted role |
| Kicks members | Kick Members |
| Bans and unbans | Ban Members |
| Times members out | Moderate Members |
| Renames members | Manage Nicknames |
| Creates ticket channels | Manage Channels, Manage Messages |
| Creates temporary voice rooms | Manage Channels, Move Members |
| Logs with a webhook | Manage Webhooks in the log channel |
| Shows who performed an action | View Audit Log |
| Manages Discord’s AutoMod rules | Manage Server |
| Resolves who invited a member | Manage Server |
| Slowmode, locking a channel | Manage 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.
| Permission | What it really allows |
|---|---|
| Administrator | Everything, including bypassing every channel restriction. See the separate article. |
| Manage Roles | Editing and granting any role below its own — including permissions on those roles |
| Manage Channels | Deleting every channel in the server. There is no undo. |
| Manage Webhooks | Creating a webhook that can post as anyone, and reading existing webhook URLs |
| Ban Members | Removing anyone below it in the hierarchy, in bulk |
| Manage Server | Renaming the server, changing invites, adding and removing integrations |
| Mention Everyone | Pinging 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_MEMBERSnever learns that anyone joined, so welcome messages and auto-roles do nothing no matter what you grant it. - A bot without
MESSAGE_CONTENTcannot 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.
- Server Settings, then Roles. Find each bot’s role. Read its permission list and ask, per permission, which feature you use needs it.
- 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.
- Server Settings, then Integrations. This lists every installed app, including ones added by someone who has since left. Remove what you do not recognise.
- 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.
- 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