Discord Server Security: AutoMod, Verification Levels and Raid Protection in Practice

Most Discord security advice is a list of bots. That is the wrong starting point. Begin with a threat model, because the four things that go wrong on a server need four different defences, and buying a bot before knowing which one you have is how servers end up with five overlapping tools and no coverage.

Four threats, not one

Spam bots post links at scale and leave. Join raids are coordinated floods of accounts arriving at once to overwhelm moderation. Compromised accounts are real members whose credentials were stolen, which makes them trusted and therefore more dangerous. Targeted harassment is a human problem that no filter solves and that requires a documented response.

The first two are largely automatable. The third needs detection plus a fast revocation path. The fourth needs people, policy and a clear escalation route. A security setup that only addresses the first two is common and gives a false sense of completeness.

Verification levels: the cheapest control you have

Discord offers five verification tiers. None requires nothing. Low requires a verified email. Medium requires a verified email plus an account at least five minutes old. High adds a ten-minute waiting period between joining the server and being able to interact. Highest requires a verified phone number.

The High tier is the interesting one for public communities. Discord describes its purpose plainly: the delay gives moderators time to respond to raids, meaning large numbers of malicious users joining at once. The cost is that legitimate new members also wait ten minutes, which is a real friction expense in a small server and a trivial one in a large one.

A reasonable default is Medium for a growing community and High once you are publicly discoverable or have been raided once. Highest, which requires a phone number, excludes a meaningful share of privacy-conscious users and should be reserved for servers with an ongoing, specific problem.

What AutoMod can and cannot do

AutoMod is Discord's native filtering layer and it is better than most third-party equivalents for the cases it covers. You get up to four keyword filters in total: one preset "commonly flagged words" list plus three custom filters holding up to a thousand keywords each. It also includes a spam content filter trained on messages users have reported, and a mention-spam rule that can flag messages exceeding a threshold of up to fifty mentions.

Three responses are available: block the message, send an alert to a logging channel, or time the member out. The combination that works for most servers is block plus alert for anything unambiguous, and alert-only for rules that need human judgement. Timing out on an automated rule is appropriate for mention spam and rarely for keywords, because a false positive that silences a real member is more costly than a message that reaches the channel for ninety seconds.

What AutoMod does not do is understand context. It matches patterns. Keyword lists therefore need a review cycle, because language moves and a list written a year ago is filtering words nobody uses while missing the ones they do.

Raid protection and the response window

Discord ships built-in raid and user-bot detection intended to stop coordinated joins as or before they happen. It is genuinely useful and it is not sufficient on its own, because the automated response is generic while your server's vulnerable surface is specific.

The layer that matters is your own response window. Before a raid happens, decide three things and write them down: who can raise verification level and lock channels, what "lock" means concretely in your server, and how members are told what is happening. A team that has answered those three questions in advance resolves a raid in minutes. A team that has not spends the incident arguing about permissions.

Logging is what makes the rest useful

Without a log, you cannot tell whether a filter is too aggressive, you cannot reconstruct an incident, and you cannot make a defensible moderation decision when a member disputes one. At minimum, log message deletions and edits, role changes, joins and leaves with account age, and every automated action with the rule that triggered it.

Account age at join is the single most predictive field in that list. A wave of accounts created within the same hour is the clearest raid signal available to you, and it is visible in a join log before it is visible in the channels.

The human layer is where the research points

A 2019 CSCW study by Jiang and colleagues interviewed twenty-five Discord moderators and found that the hardest problems were not the ones tools address. Real-time and voice-based moderation leaves no artefact to review, norms are enforced inconsistently across shifts, and moderation teams struggle specifically with scale — which is why they build their own bots against the Discord API rather than relying on off-the-shelf ones.

The practical implication is that a security setup is a team design problem as much as a configuration problem. Define what a warning is, when it escalates, who reviews appeals, and how decisions are recorded. Enforce two-factor authentication for anyone holding moderation permissions. Then automate the parts that are mechanical, and accept that the rest is judgement work that needs documentation rather than software.

Voice is the hard case

Every automated tool described so far operates on text. Voice channels produce no artefact: there is no message to delete, no log to review, and no way to verify a report after the fact. The 2019 CSCW study of Discord moderation identified this as a structural challenge rather than a tooling gap, and it has not changed since.

The practical responses are organisational. Keep the number of voice channels small enough that a moderator can plausibly be present in the busy ones. Give members a way to report something that just happened, with a timestamp and a channel, while it is still fresh. And accept that voice incidents are resolved on the balance of accounts rather than on evidence, which makes a written escalation policy more important, not less.

Compromised accounts

A member whose account has been taken over is the most damaging case, because they arrive with trust, roles and channel access. The signature is behavioural: an account that has been quiet for weeks suddenly posts an identical message with a link across several channels in under a minute.

Detection is straightforward if you log message content patterns and posting rate; the harder part is the response. Decide in advance that the first action is to remove roles rather than to ban, because the person on the other end is a member who is about to have a bad day and will need their access back. A ban destroys their message history and their standing; a role removal stops the damage and is reversible in seconds.

Appeals are part of the system

Any moderation system that can act automatically will occasionally act wrongly. Without a documented appeal path, a false positive turns into a public argument in your general channel, which costs far more attention than the original incident.

The minimum viable path is a single channel or form where a sanctioned member can state their case, a named person who reviews it, and a commitment to answer within a stated period. Publishing that path is itself a moderation tool: it moves the dispute out of the public channel and signals that decisions are reviewable, which reduces how aggressively people contest them.

Shift design and moderator burnout

The research on moderation teams consistently finds that the binding constraint is human rather than technical: volume rises with membership, coverage depends on time zones, and the people doing the work are usually volunteers. Teams fail not because they lack tools but because two people are covering twenty hours a day.

Three structural fixes help more than any bot. Recruit for time zones rather than for enthusiasm. Define what may wait until tomorrow, so nobody feels obliged to be permanently available. And keep decisions in a shared log so that a moderator coming on shift can see what happened without asking, which is the difference between a team and a group of individuals.

A raid runbook you can write in an hour

Write down, in this order: who is authorised to raise the verification level; the exact channels that get locked and the exact permission change that constitutes locking; where the team coordinates during an incident; what the members are told and in which channel; and who reviews the join log afterwards to remove accounts that got through.

Then rehearse it once. A five-minute walkthrough with the team, before anything happens, is what converts a document into a capability. Most servers discover during that walkthrough that exactly one person actually has the permission required for step one — which is the finding that makes the exercise worth the hour.