Are Discord admin bots safe? A permissions checklist
What a bot with Administrator can do, why kicking it undoes nothing, and a checklist for auditing the bots in your server.
The honest answer is that a Discord bot is exactly as dangerous as the permissions you hand it, and most people hand over far more than the bot needs because the invite screen makes that the path of least resistance.
This is a practical checklist rather than a warning. Nothing here is about any particular bot; it is about the properties to check on any of them.
What a bot with Administrator can do
Administrator is not a large set of permissions. It is an exemption from the permission system. A bot with it:
- Reads every channel, including the ones you locked. Channel overwrites do not apply to Administrator, so a
View Channeldeny on your staff channel means nothing. - Deletes any channel or category, and the messages in them.
- Creates, edits, and deletes any role below its own position, including changing what those roles can do.
- Bans, kicks, and times out any member below its own position.
- Changes server settings, the vanity URL, the AutoMod rules, and the integrations.
- Creates invite links and webhooks anywhere.
The only two things it still cannot do are act on the server owner, and act on roles or members positioned above its own role. Which means: when a bot has Administrator, its position in the role list is the entire security boundary.
Why "just kick the bot" does not undo it
People treat removal as an undo. It is not. Removal stops future actions and reverses nothing.
Deleted things stay deleted. Channels, messages, roles, and emoji do not come back. Discord has no server-level undelete.
Webhooks outlive the bot. A webhook is a URL that posts into a channel and does not belong to the bot that made it. Kicking the bot does not delete its webhooks. Anyone holding that URL can keep posting into your channel indefinitely, and the messages will look like they came from whatever name and avatar the webhook was given. This is the single most-missed item in a post-incident cleanup.
Invites outlive the bot. Any invite link it created keeps working until you revoke it.
Bans stay banned. Unbanning is manual, one at a time, and you need to know who was banned. The audit log has it, but only within its retention window.
Data it read is already read. If a bot could see your private channels, it has already seen them. Removing access afterwards does not unsee anything.
Permission changes persist. If it edited a role's permissions, that role is still edited.
The practical consequence: the decision that matters is the one you make on the invite screen, not the one you make afterwards.
The pre-invite checklist
1. Read the permission list on the authorisation screen
Discord shows you exactly what the bot is asking for before you click Authorize. Most people skim it. Read it, and specifically look for these six, which are the ones that turn a bot into an effective admin:
- Administrator (everything, bypasses overwrites)
- Manage Server (settings, AutoMod, integrations, welcome screen)
- Manage Roles (role permissions and channel overwrites both)
- Manage Channels (create, edit, and delete channels)
- Manage Webhooks (persistent access that survives removal)
- Mention Everyone (pings your entire member list)
If the list contains Administrator and the bot's own documentation does not explain why, that is the point to stop and ask.
2. Scope the invite link yourself
The permissions a bot requests live in the permissions= number in its invite URL. You can edit it. If the bot's own site offers a permissions calculator or a scoped invite link, use it. If not, invite with a smaller set and grant more if something actually fails.
You can also fix this after the fact: Server Settings, Roles, find the bot's role, and uncheck what it does not need. If the bot breaks, you have learned exactly which permission it needed, which is better information than "it works".
3. Check whether it is verified, and know what that means
A verified app has a checkmark. Verification is required for an app to scale past 100 servers, and it involves Discord confirming the developer's identity and reviewing the app.
What it means: someone real is behind it, and the app cleared Discord's review at that scale.
What it does not mean: that the code is audited, that the bot is well built, or that the developer's infrastructure is secure. Verification is a floor, not a guarantee. Treat an unverified bot in a large server as a question worth asking, and a verified bot as still requiring the rest of this list.
4. Ask which privileged intents it uses
Three gateway intents are privileged and gated by Discord: Message Content, Server Members, and Presence. Apps above Discord's user threshold have to apply and be approved for them.
Message Content is the one that matters most for privacy. A bot holding it can read the text of every message in every channel it can see. A bot without it only receives message content for messages that mention it, replies to it, or DM it.
This is a real dividing line and worth asking about directly. Plenty of bots need Message Content for legitimate reasons (prefix commands and keyword filtering both require it). Plenty of others hold it because it was easy to turn on. If a bot does not need to read your members' conversations, it should not be able to.
5. Find out what it stores and where
Look for a privacy policy. You are looking for four things:
- Does it store message content, or only IDs and counts?
- Does it store member data, and for how long after you remove the bot?
- Where does your data go if you stop using it, and can you get it out?
- Is there a support channel where a human answers?
A bot with no privacy policy and no contact address is a bot with no accountability.
6. Check how it confirms destructive actions
This is the property that separates a well-built admin bot from a dangerous one, and it is easy to test.
The pattern to look for: confirmation bound to the specific target, not a blanket permission. "Allow this bot to delete channels" granted once, forever, is a weak model. "Delete #old-general, which contains 1,400 messages. Confirm or deny." shown for that exact channel, every time, is a strong one.
Same for anything that opens access. Granting @everyone a permission it does not already have, or clearing an @everyone deny, is the change that quietly exposes a private channel to your whole server. It deserves its own confirmation, separate from any standing approval.
7. Position the bot's role deliberately
Put bot roles below your staff roles. Always. A bot cannot manage roles above its own or act on members whose highest role is above its own, so this one drag-and-drop keeps a misbehaving or compromised bot away from your admins.
The exception people make is "but then it cannot assign the Moderator role". Correct, and that is usually the right outcome. If a bot genuinely needs to hand out a staff role, position it just above that specific role, not at the top.
More on how this works in Discord permissions explained.
8. Test it in a throwaway server first
Free, fast, and it answers questions the documentation does not. Make an empty server, invite the bot, and try the destructive things: ask it to delete a channel, ask it to give someone a role, ask it to change permissions. Watch what it asks you before acting. Five minutes here tells you more than an hour of reading.
9. Ask who else can command it
An underrated question. If the bot takes instructions from anyone who can type, then every member has the bot's permissions by proxy. A member with no Manage Roles can ask the bot to change permissions, and the bot will do it.
The property to look for is that the bot checks the asking member's permissions and role position before acting, not just its own. Ask, or test it with a second account holding no roles.
10. Consider what happens when it is unavailable
Not a security question, but it belongs on the same list. If your only path to banning someone runs through a bot command, you have a moderation dependency. Make sure your moderators can act by hand.
How to audit the bots already in your server
Twenty minutes, once. Do it now rather than after something happens.
1. List them. Server Settings, Integrations shows every app in the server, its commands, and lets you restrict which roles and channels each command applies to. Also scan the member list for bot tags; an app can be present without commands.
2. Read each bot's permissions. Server Settings, Roles, and open each bot role. Note every one holding Administrator, Manage Server, Manage Roles, Manage Channels, Manage Webhooks, or Mention Everyone. For each, ask whether you know why.
3. Check role positions. Every bot role should sit below your staff roles. Fix any that do not.
4. Audit webhooks per channel. This is the step everyone skips. Open each channel's Edit Channel, Integrations, Webhooks and look at what is there. Delete any webhook you cannot account for, especially ones created by bots you no longer use. Webhooks are the persistence mechanism that survives removal.
5. Check invites. Server Settings, Invites. Revoke anything unfamiliar or permanent that you did not create.
6. Read the audit log. Server Settings, Audit Log, filtered by each bot. You are looking for actions you did not expect: role permission edits, channel deletions, permission overwrite changes. Discord's audit log retention is limited, so this catches recent activity, not history.
7. Remove what you are not using. An unused bot with Manage Roles is a permission surface for nothing. If you are consolidating, this guide covers doing it without breaking things.
8. Turn on the 2FA requirement for moderation. Server Settings, Safety Setup. It forces moderation actions to come from accounts with two-factor authentication, which limits what one compromised moderator account can do.
If you think something went wrong
In order:
- Remove the bot's permissions first, before removing the bot. If you kick it immediately you lose the ability to see what it had.
- Read the audit log and write down what it did.
- Delete every webhook in every channel you cannot account for.
- Revoke invites you did not create.
- Then kick the bot.
- Rebuild what was deleted. Assume anything it could see was seen.
The pattern worth looking for
None of this is unique to any one bot. The properties that make an admin bot safe to run are the same everywhere: it asks for the specific permissions its actions need rather than a blanket exemption, it checks whether you are allowed to do the thing before doing it for you, and it confirms destructive and access-widening changes against the exact target each time.
Bond, which can audit these settings for you, is built to that shape: it never requests Administrator, every action maps to a specific Discord permission and to the requesting member's own permissions and role position, deleting a channel or category gets a confirmation naming that resolved target even when the tool is otherwise allowed, and widening @everyone access gets its own separate confirmation that no standing approval satisfies. It also does not hold the Message Content intent, so it cannot read the text of messages that do not mention it.
Whatever you run, hold it to those three properties, and check the webhooks.