10 min read · Published 2026-11-01 · Updated 2026-11-01 · Perminator
A bot is another member of the server with a role you did not design carefully, invited by an OAuth screen that asks for more than the bot uses. A webhook is a URL that can post into a channel under any name and avatar. Both are ordinary tools. Both are also the way servers are emptied on a weeknight. This is what to grant, what to refuse, and what to check after you click Authorize.
A bot joins as a member
When a bot is invited it receives a managed role. That role has a position in the hierarchy, and the same rules apply to it as to a person. It can only kick, ban, time out, rename, or assign roles below its own role. It cannot act on the owner. If "the bot is broken," the hierarchy is the first place to look, not a second invite with Administrator ticked. The diagnostic steps are in when a permission does nothing .
Do not accept Administrator as the default
Bot directories request Administrator because it avoids support tickets, not because the bot needs to bypass every channel lock. Administrator lets the bot read the mod log, the tickets, and any channel you hid from the people who installed it. It also lets the bot edit roles and channels under its position. If the bot's account or its hosting is compromised, that is the blast radius.
Decline the invite and ask the developer which flags the bot actually checks. A music bot needs Connect and Speak in voice channels. A logging bot needs View Audit Log and Send Messages in a log channel. A moderation bot needs the moderation flags and a role in the right place. Almost none of them need Administrator, Manage Server, and Manage Webhooks together.
A practical grant for common bots
Start from zero and add the row that matches the job. If a bot does two jobs, give it two roles only if you are willing to maintain both. One role with the union of the permissions is easier to audit.
Job
Grant
Do not grant
Welcome message
Send Messages in the welcome channel
Manage Roles, Administrator, Manage Server
Reaction or level roles
Manage Roles, and a role position above only the cosmetic roles it assigns
Kick, Ban, Timeout, Manage Messages. Manage Roles only if it must assign a mute or jail role.
Administrator, Manage Server, Manage Webhooks
Logging
View Audit Log, View Channel and Send Messages in the log channel
Manage Messages in the public channels, Administrator
Music or voice
Connect and Speak in the voice channels it uses
Manage Roles, Kick, Ban, Manage Channels
Tickets
Manage Channels only if it truly creates and deletes ticket channels, scoped by where you place its role
Administrator, Mention Everyone, Manage Server
Who is allowed to add the next bot
Inviting a bot with roles and permissions requires Manage Server. That flag also covers the server name, discovery, and other settings, so it is a poor fit for "the person who installs fun bots." Keep Manage Server on admin only. If a moderator wants a bot, an admin invites it, strips the requested permissions, places the role, and writes down what it was for.
Remove bots you no longer use. An abandoned bot with Manage Roles is still a role in your hierarchy, and you will not hear about it when the developer's account is breached.
Webhooks
A webhook posts into one channel. Whoever holds Manage Webhooks can create one, and anyone with the webhook URL can post as any name and avatar, including your own, until the webhook is deleted. There is no second permission for "post as the webhook." The URL is the credential.
Grant Manage Webhooks only to admins. Do not grant it to moderators so they can plug in a Twitter or Twitch feed. An admin can create the webhook, and the feed can live without the moderator holding the flag. Store webhook URLs the way you would store a password: not in a public channel, not in a screenshot, not in a bot's welcome message.
If a channel has been used for impersonation, delete the webhooks on that channel from Integrations, not just the messages. Deleting messages leaves the URL working.
User-installed apps
Use External Apps is separate from bots you invited. It controls whether apps a member installed on their own account may post public replies in your server. With the permission off, those apps can still run, but the replies are ephemeral — visible to the person who invoked them, not to the channel. It does not affect apps you have installed on the server yourself.
Leave Use External Apps off on @everyone until you have a reason to let personal apps speak in public channels. It is a newer flag, and a lot of servers still have it on because it arrived as part of a default set.
Require 2FA does not cover bots
Server Settings → Safety Setup → Require 2FA for moderator actions forces human accounts to enable two-factor authentication before they can kick, ban, or manage the server. It does not put a prompt in front of a bot token. A bot with Ban Members can ban while your moderators cannot, if they have not turned on 2FA yet.
Turn the setting on anyway. It stops a stolen moderator password from being enough. It does not replace a careful bot role. Treat the bot's permissions as the permissions of a staff member who cannot enable 2FA.
The ten minutes after you invite one
After Authorize, open the role list and drag the new role to the position you decided before the invite, not to wherever Discord dropped it. Open the role's permissions and remove anything you did not mean to grant. Send a test command in a channel the bot should see and in one it should not. Check Integrations for a webhook you did not expect, which some bots create as part of setup.
If the test fails, do not re-invite with Administrator. Use the troubleshooting guide and fix the specific miss. Write the bot's name, its job, and its permissions in the same note as your staff ladder so the next admin does not have to reverse-engineer it.
