Protection Commands

Guild Protection has no punishment threshold, on purpose

The first unauthorized destructive action from anyone not on the whitelist gets an instant ban. Not a warning, not a strike count: zero tolerance. That’s a deliberate design choice, not a missing feature: a compromised admin account or a malicious bot deleting channels doesn’t give you time to accumulate evidence, and staff you actually trust are meant to be on the whitelist from the start, not discovered to be trustworthy after the fact.

Whitelist membership is treated as owner-equivalent trust, which is why managing it requires the server owner or an extra-owner role, not just Manage Server; a whitelisted user is fully exempt from Guild Protection’s response, so that list is only as safe as who’s allowed to edit it.

Detection runs on two paths at once

A fast path reacts directly to gateway events (channel and role creation or deletion, bans, kicks, webhook and server updates) before Discord’s audit log has necessarily caught up. A slower, broader path reads the audit log itself and covers every monitored event type. Both feed the same detection and ban logic, so which one catches a given incident first doesn’t change the outcome, only the reaction time.

It tries to undo the damage, not just stop it

After banning the offender, Guild Protection attempts real recovery: unbanning anyone the offender banned, deleting channels they created (a common raid pattern is spam-channel flooding), and recreating channels or roles they deleted. Recovery actions are tracked individually, so if a revert genuinely fails partway through, the alert says so specifically rather than reporting a blanket “all clear.”

It needs permission to actually see what happened

Detection depends on reading Discord’s audit log to work out who actually did what. Without the View Audit Log permission, protection doesn’t error loudly; it just can’t attribute actions to an actor, and degrades silently. The dashboard’s Guild Protection page shows whether that permission is currently readable; if protection ever seems to be doing nothing, that’s the first thing worth checking.

Anti-alt detection is a separate system that lives on the same page

Blocking or flagging new accounts under a minimum age (l?antialt) isn’t gated by Guild Protection at all: it only needs Manage Server, not the owner-level trust the whitelist requires, and it runs independently at join time rather than reacting to destructive actions. The two features share a settings page for convenience, not an access model or a detection pipeline.

Commands