# Are Discord bots safe?

> Are Discord bots safe? Mostly yes — the risk is rarely the code but the permissions you grant, the invite link you clicked, and an app nobody reviews.

- Canonical: https://discordguides.blog/blog/are-discord-bots-safe
- Published: 2026-08-30
- Author: The Manual desk
- Facts checked: 2026-08-30
- Sources:
  - Discord developer docs — Gateway intents (https://docs.discord.com/developers/events/gateway) — checked 2026-08-30
  - Discord developer docs — Permissions (https://docs.discord.com/developers/topics/permissions) — checked 2026-08-30
  - Discord developer docs — Audit log (https://docs.discord.com/developers/resources/audit-log) — checked 2026-08-30
  - discord-api-docs discussion 4864 — restricting Administrator on invite (https://github.com/discord/discord-api-docs/discussions/4864) — checked 2026-08-30
- Publication: The Manual, an independent site not affiliated with Discord Inc.

---
Established bots from known vendors are safe enough to run a server on. The risk is almost never
the bot's code. It is the **permission set you grant**, the **invite link you clicked**, and the app
a former staff member added two years ago that nobody has reviewed since. All three are yours to
control.

This page covers what a bot can actually see, what Discord's verification does and does not
guarantee, and the checks worth running before and after you add one.

## What can a bot actually see?

Less than most people assume, and the limits are set by Discord rather than by the bot.

A bot receives events for the channels it can see. Beyond that, three categories of data are gated
behind **privileged intents**, which the bot's developers must request and Discord must approve.
Discord names them: `GUILD_PRESENCES`, `GUILD_MEMBERS` and `MESSAGE_CONTENT`.

| The bot wants                             | It needs                | You control it? |
| ----------------------------------------- | ----------------------- | --------------- |
| To read what your messages say            | `MESSAGE_CONTENT`       | No              |
| To know who joined, left or changed roles | `GUILD_MEMBERS`         | No              |
| To see member online status               | `GUILD_PRESENCES`       | No              |
| To see a specific channel at all          | View Channel permission | **Yes**         |

The last row is the one that matters to you. **Intents are the bot's developers' decision;
permissions are yours.** A bot with full message-content approval still cannot read a channel you
have denied it View Channel on — with one exception, covered below.

For apps at any scale this is reviewed. Discord's documentation states that "When an app has more
than 10,000 unique users who can see your app across all the servers it's in, it requires review
for continued access to Privileged Intents."

## What does the verified checkmark mean?

It means the app passed Discord's review process, and Discord requires it above a threshold: "For
verified apps (required for apps in 100+ guilds), the intent must also be approved after the
verification process to use the intent."

So a verified bot has been reviewed, has been approved for whichever privileged intents it holds,
and belongs to a developer Discord has identified.

**What it does not tell you** is equally worth stating:

- That the code has no bugs.
- That the bot's token will never leak.
- That the vendor will still exist in two years.
- That the permission set it asks for is appropriate for your server.

Verification is a reason to prefer one bot over an unknown one. It is not a reason to stop scoping
permissions.

## The five real risks, ranked

Ordered by how often each is actually what went wrong.

### 1. Over-permissioning

The biggest risk by a distance, and it is entirely self-inflicted. A bot with Administrator can
delete every channel, ban your whole staff team and read every private channel, because Discord's
own documentation notes that "ADMINISTRATOR overrides any potential permission overwrites."

It is common enough that Discord's developer community has argued about whether apps should be
allowed to request it in an invite link at all —
[discussion 4864](https://github.com/discord/discord-api-docs/discussions/4864) is worth reading for
both sides. [Why you should not give a bot Administrator](/blog/discord-administrator-permission-risk)
covers the reasoning and how to take it back safely.

### 2. The wrong invite link

A lookalike bot with a near-identical name and avatar is trivial to make, and the invite link is
where the substitution happens. Somebody posts "here's the bot" in a support thread, a staff member
clicks it, and a different application is now in your server.

**The rule is absolute: get the invite link from the bot's own website.** Not from a Discord
message, not from a search result, not from a listing site you reached through a search result.
Check the application ID matches the one on the vendor's site.

### 3. Abandoned apps

Server Settings, then Integrations, lists every app installed in your server. On any server more
than a year old, this list contains things nobody remembers adding, added by people who have since
left.

Each one still holds whatever permissions it was granted. Remove what you do not recognise. This is
the highest-value ten minutes in this article.

### 4. Token compromise

The realistic version of "the bot is malicious" is not a malicious developer — it is a leaked
token, a compromised dependency, or a breached host. The bot's behaviour changes without the
vendor's involvement.

You cannot prevent it. You can bound it, which is the whole argument for narrow permissions: a
compromised bot can only do what you granted.

### 5. A staff account, not a bot

Worth naming because the defences are the same and the frequency is higher. A moderator's account
with Manage Roles or Ban Members is as dangerous as a bot with them, and far more likely to be
phished.

Any control you put around bot power should apply to people too.

## Before you add a bot: seven checks

1. **Is there a real website?** With a privacy policy, terms and a way to contact someone.
2. **Is the invite link from that website?** Not from anywhere else.
3. **Does the application ID match?** Check it on the authorisation screen.
4. **What permissions is it asking for?** Read the list. If Administrator appears, ask why.
5. **Is there a support server with actual people in it?** An empty or absent one is a signal.
6. **Is it verified?** Not decisive, but a data point.
7. **Does its documentation state which permissions each feature needs?** A vendor that publishes
   this is a vendor that has thought about scoping, and it makes the narrow grant possible.

That last check separates the two kinds of vendor faster than anything else on the list.

## After you add a bot: the audit

Four things, once, and then on a schedule.

**Narrow the permissions.** Grant what its features need and nothing else.
[Which permissions a bot actually needs](/blog/discord-bot-permissions-explained) has a
feature-by-feature table you can work from.

**Lower the role.** A bot's role should sit as low as it can while still being above the roles it
manages. High is not safer.

**Deny it your sensitive channels.** A channel-level View Channel deny keeps a bot out of staff
discussion. It works on everything except a bot with Administrator.

**Put it in the calendar.** Six-monthly, walk the Integrations list and the bot roles again. Servers
accumulate apps the way desks accumulate cables.

## Watch what happens, not just who you trust

Trust does not scale and it does not survive a compromised token. What does scale is a record and a
limit.

**Discord's audit log** is the platform's own record, and it has a hard boundary: "All audit log
entries are stored for 45 days." That window is short enough that a dispute about last quarter has
no platform evidence behind it, and it is the structural reason serious servers run their own
logging.

Three mechanisms are worth having in place before you need them, and Vetox is a useful concrete
example of what each looks like because it ships all three on the free tier or close to it.

**A durable log of your own.** Vetox's logging covers **148 distinct event types**, each with its
own destination channel and colour, and every one of them is available on the free tier. What the
paid tiers add is the executor detail — resolving _who_ performed the action from the audit log —
plus webhook delivery and bulk channel setup, all from the Basic plan. The point of running one is
that it outlives Discord's 45 days.

**Rate limits on destructive actions.** Vetox's Protection watches the audit log and rate limits
destructive administrative actions across **20 rule types** — mass bans, mass kicks, channel
deletion, role deletion, dangerous-role grants, server renames, bot additions, webhook removal.
Per rule you set a threshold, a window, a punishment, whether the change is automatically undone,
and a whitelist. It is free on every tier, and it applies to humans and bots equally, which is the
point: it converts "do I trust this account" into "how much damage can any account do in sixty
seconds."

**A record of dashboard changes.** Bot configuration changes rarely leave a Discord audit-log entry,
because they happen on the bot's website. Vetox's Dashboard Watcher keeps an audit trail of them —
who changed which setting and when, retained for 500 entries or 90 days, free on every tier. It is
the answer to "who turned the filter off", which Discord cannot answer for you.

Those three sit alongside the join-time defences rather than replacing them.
[How to protect a server against raids](/blog/protect-against-raids) covers that other half, and it
is the half that matters when the account behaving badly is not a bot at all.

## Common questions

**Can a bot read my DMs?**
Not your DMs with other people. A bot can read a DM you send to _it_, and that is the whole of it.

**Can a bot see a channel I have denied it?**
No, unless it has Administrator, which overrides channel overwrites. That exception is the main
reason to avoid granting it.

**Is a self-hosted bot safer?**
Different, not safer. You remove the vendor from the trust chain and take on the hosting, the
updates and the token security yourself. For most servers that is a worse trade, not a better one.

**What happens to my data if I remove a bot?**
That is the vendor's policy, and it is a fair question to ask before you install rather than after.
A vendor with a published privacy policy and a stated retention period has answered it; one without
has not.

**How many bots is too many?**
There is no technical limit worth worrying about. The practical limit is how many you can audit.
Every bot is a permission set somebody has to review, and a stack nobody reviews is the actual
risk — not the count.