# 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.

- Canonical: https://discordguides.blog/blog/discord-bot-permissions-explained
- Published: 2026-09-08
- Author: The Manual desk
- Facts checked: 2026-08-30
- Sources:
  - Discord developer docs — Permissions (https://docs.discord.com/developers/topics/permissions) — checked 2026-08-30
  - Discord developer docs — Gateway intents (https://docs.discord.com/developers/events/gateway) — checked 2026-08-30
  - Discord developer docs — Auto Moderation (https://docs.discord.com/developers/resources/auto-moderation) — checked 2026-08-30
  - Discord developer docs — Audit log (https://docs.discord.com/developers/resources/audit-log) — checked 2026-08-30
- Publication: The Manual, an independent site not affiliated with Discord Inc.

---
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](/blog/discord-administrator-permission-risk).

[Role hierarchy, explained properly](/blog/discord-role-hierarchy) 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_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](/blog/discord-bot-cant-assign-role) covers that and the four
other causes, and [Missing Permissions errors](/blog/fix-missing-permissions-error) covers the
error message it produces.