How we protect your bot token

When you use BotShade, the thing you probably care about most is your bot token. If it leaks, your bot can be hijacked and your server can be wrecked. So we want to be straightforward about where we keep it, how it’s stored, how far we protect it — and what we’ve decided not to do.

Security writing tends to turn into a dry list of conclusions. In this article we try to share the why behind each design decision as well.

In this article:

• What a bot token is, exactly
• What happens when you hand it to us
• How it’s stored
• How bots stay separated
• How we protect it in transit
• Who can touch the token
• If something happens
• Things we deliberately don’t do
• What we can’t cover, and what we’d ask of you

What a bot token is, exactly

A bot token is a long string Discord hands you when you create a bot in the Developer Portal. It’s how a bot identifies itself to Discord — effectively, a password that belongs to the bot itself.

Anyone holding the token can do anything the bot is allowed to do: send messages, assign roles, ban members, change server settings — all of it, within the bot’s permissions. That’s why the token is called out as the single most sensitive piece of information for any Discord bot.

Using a bot platform like BotShade means handing this token to a service. Wanting to know what happens to it, and how it’s protected, is a completely fair thing to ask.

What happens when you hand it to us

The moment you paste the token into the dashboard and hit save, the following happens, in order:

1. The token is sent from your browser to BotShade over an encrypted connection.
2. Server-side, we check it with Discord once to verify that the token is valid and to learn which bot it belongs to.
3. Once verified, the token is encrypted on the spot before it is stored.
4. The plaintext token is discarded as soon as the request is done.

The string of dots you see in the input box can’t be recovered after saving. What the dashboard shows from that point on is only the minimum needed for you to recognize which bot it is — typically the last four characters.

How it’s stored

Every bot token we hold is stored encrypted. Getting hold of the stored value alone is not enough to read the token.

The key needed to decrypt it is managed separately from the encrypted values, under strict control and with narrowly limited access. The idea is classic defense in depth: if one layer is breached, the other still holds.

How bots stay separated

BotShade looks after bots for a lot of people. What matters most here is making sure someone else’s bot can never reach your bot’s token or data.

A bot’s processing can only reach that bot’s own data. We don’t rely on application code alone for this; the separation is enforced by the system underneath as well.

The point is to leave as little room as possible for a code bug or a bad release to accidentally expose another bot’s data. Application code changes every day, and protections are safer when they live somewhere that rarely changes.

How we protect it in transit

There are roughly three paths a token travels:

• Your browser ↔ the BotShade dashboard
• BotShade ↔ Discord
• Service-to-service traffic inside BotShade

All of them are encrypted. We also have protections in place against suspicious requests and floods of traffic, and important requests are checked to confirm that they are genuine and haven’t been tampered with before we act on them.

Eavesdropping, impersonation, and tampering are each handled by a separate layer, all running at the same time.

Who can touch the token

Straight answer: we don’t reach for the decrypted token. The decryption path isn’t wired into our day-to-day operations at all, so dashboard development and support work simply don’t sit in front of a plaintext token. We don’t want to, and we don’t.

What we may touch is the ciphertext itself — the encrypted blob as it lives in storage — for things like integrity checks and tamper detection. That’s about confirming “is this the same value, is it intact” without ever decrypting it. It’s not about reading the contents.

Administrative operations performed on the operations side are recorded: who did what, and when.

If something happens

There is no such thing as perfect defense. So what happens when something does go wrong matters just as much.

• Suspicious access and unusual sign-in patterns are surfaced and reviewed.
• If a token may have leaked, we notify the affected user.
• You can regenerate your token from the dashboard at any time; the old one is invalidated immediately.
• Security reports are accepted at help@botshade.com. We respond in good faith to every report made in good faith (see Responsible Disclosure).

We tell users about token regeneration as their “emergency exit.” If something feels off, the right first move is to regenerate and invalidate the old token — that alone stops the spread of damage in most scenarios.

Things we deliberately don’t do

A design is defined as much by what it refuses to do as by what it does. Some of the things we’ve explicitly decided not to do at BotShade:

• We don’t write tokens to logs. Not in error logs, debug logs, metrics, or traces — not the token itself and not any substring of it.
• We don’t ask for your token in support tickets or chats. We will never ask you to share your token with us for support purposes. If a message arrives asking you to do so, it isn’t from us.
• We don’t display the token outside the dashboard. Not in email, not in a Discord message, not via any external integration. The plaintext token doesn’t leave the dashboard surface.
• We don’t spread the means of decryption around. Where the key can be used, and who can use it, is kept to what is strictly necessary, rather than left available “just in case.”

These “things we don’t do” aren’t a paper policy. They are baked into both the code and the way we run operations.

What we can’t cover, and what we’d ask of you

We try to be honest about where our coverage ends. The following are things we can’t fully protect against on our side:

• A user accidentally committing the token to a public repository.
• A dashboard login account being taken over by a third party.
• A user’s device itself being compromised by malware.

The best way to harden the second and third is to strengthen how you sign in to the dashboard. The BotShade dashboard has no password of its own — you sign in with an external account (Discord, Google, and so on), or with a passkey.

So what we’d ask of you is:

• Enable two-factor authentication (2FA) on the account you sign in with — Discord, Google, etc. Since BotShade has no password itself, the strength of the front door is whatever the strength of that linked account is.
• If you can, register a passkey. Passkeys are bound to the device and are resistant to phishing.

For the first risk (accidentally committing a token to a public repository, and so on), the fastest response is to go to Discord’s Developer Portal and hit “Reset Token” — the old token is invalidated on the spot. Re-register the new one on the BotShade dashboard, and your bot keeps running.

Security doesn’t work as a one-sided effort. It only adds up to “minimum damage” when both sides — ours and yours — do their part. We will keep doing ours, honestly.

One more note: we don’t publish the specific makeup of our defenses or the names of the products we use, because that information would help attackers. Thank you for understanding.