Raid Defense
Kicks accounts that are too new to be trusted, and detects a join-rate spike to trigger a lockdown, mass-kick, or mass-timeout of everyone who just joined.
Overview
Two independent triggers run on every member join.
New-Account Filter
If Minimum Account Age is set (days, 0 = off), any account younger than that is kicked immediately. This always kicks, regardless of whatever "Action on Raid" is configured below. A "๐ถ New Account Kicked" entry logs the member and their account age. That's the only log entry it produces, the generic member-kicked log is skipped for it so the same departure isn't logged twice. It also doesn't trigger a Leave message (see Welcome & Leave). Members kicked this way don't count toward the join-spike tracker.
Join-Spike Detection
Aegis tracks every join in a rolling window. If the number of joins within Join Window seconds (default 30, range 5โ120) reaches Join Threshold (default 10, range 3โ100), it fires once. The log resets afterward so it won't re-trigger on every subsequent join of the same wave.
On trigger, Aegis pings the server owner directly with a "๐จ Raid Detected" alert, then runs Action on Raid
| Action | What happens |
|---|---|
| Lockdown (default) | Removes Send Messages from @everyone on every text/announcement channel. Stays locked until manually ended. |
| Kick | Kicks exactly the non-bot accounts that made up the spike. |
| Timeout | Times out (fixed 10 minutes, not configurable) exactly the non-bot accounts that made up the spike. |
The alert is posted the moment the spike is detected, before anyone is removed, so a large wave doesn't delay the notification. It's then edited with the result.
Reporting
Kick and Timeout report how many of how many accounts were actually dealt with, for example "Kicked 4 of 6". Any account Discord refused to remove is listed by name with the reason it gave, most often a permissions or role-position problem. If that happens, check that Aegis has Kick Members and sits above those members in the role list; until it does, those accounts are still in the server.
Clean-up
Accounts removed by a raid sweep take their mess with them. The welcome cards and join logs they produced on the way in are deleted, and no leave log or goodbye card is posted for them. A column of welcome and goodbye messages for accounts kicked seconds later is exactly the noise raid defense exists to prevent.
Clearing runs as a 20-second window rather than a single pass. A join log waits a few seconds before it posts and a welcome card has to be drawn first, so at the moment a sweep finishes most of what needs clearing hasn't been sent yet. Anything that lands inside the window is removed as it arrives. The alert reports a running count while the window is open and a final one once it closes, including when the answer is that there was nothing to clear.
This only applies to accounts the sweep actually removed. Anyone Discord refused to remove is still in the server, so their join log stays, and anything posted for members who were already there is left alone.
There's no automatic "raid over" expiry. Lockdown mode stays active until a moderator manually ends it, from the dashboard's Raid Defense panel (Start/End Lockdown button) or the same manual control.
Settings Summary
| Setting | Default |
|---|---|
| Minimum Account Age | 0 days (off) |
| Join Threshold | 10 joins |
| Join Window | 30 seconds |
| Action on Raid | Lockdown |
Honeypot Channel
A honeypot is bait: a channel nobody legitimate should ever post in. Self-bots and raiders work through every channel they can see and post in all of them, so anything that posts in the honeypot has identified itself. Whoever does is banned on sight, and the ban clears the last 24 hours of their messages, which usually removes the rest of the spam run with it.
Set it up by making a channel with an obvious name (#do-not-post is the usual choice), telling your members to leave it alone, and picking it on the dashboard. Then switch the honeypot on: the dashboard asks you to confirm first, spelling out exactly what will happen, because this is the one control that starts banning people on its own. Switching it off disarms it without losing the rest of the setup.
Who is never banned
- The server owner, always, whatever else is configured.
- Staff: anyone who can ban members, and administrators, while Never ban staff is on, which it is by default. Turning it off means a compromised staff account posting there is caught too.
- Anyone holding an exempt role you have listed.
- Bots and webhooks, always. A logger or bridge pointed at the wrong channel can never be banned by it.
A message from someone exempt is still deleted, so the channel stays empty and keeps looking like a channel nothing happens in.
Settings
| Setting | Default |
|---|---|
| Honeypot | Off |
| Honeypot Channel | None |
| Never ban staff | On |
| Exempt Roles | None |
| Log Channel | The Honeypot log event |
The honeypot has its own log event under Safety on the Logging page, so its bans can go somewhere separate from raid alerts. A honeypot ban posts that one entry and nothing else. The usual "Member banned" and "Member left" entries are suppressed for it, so one removal is not reported three times. Every ban Aegis could not carry out is logged too: if it lacks Ban Members, or the member sits above it in the role list, the log says so rather than the trap appearing to do nothing.
Logging
Raid alerts and new-account kicks post to the Raid Defense event on the Logging page; the honeypot has its own event beside it. The lockdown start/end itself is also captured under the "Channels" event, since it's implemented as a bulk permission-overwrite change.