Security

Detects and instantly responds to mass destructive actions — channel deletions, role deletions, mass bans, and permission escalation.

What It Detects#

Detection Flow#

Response Actions#

Whitelist#

Add trusted user IDs or role IDs so bots or senior admins performing legitimate bulk operations don't trigger anti-nuke.

How a Reading Is Scored#

Every monitored action is normalised into one event with an actor, then scored. The score is the worst action in the incident, not a sum: four channel renames must not outrank one channel deletion, and a busy server must not look like a dangerous one. A detected burst raises the floor for that action type, because a mass action is a different act from a single one.

The score is not a black box: the dashboard shows which signals fired, their weights and the confidence cap, and the same composition is written into the incident timeline and the log line in debug mode.

Containment, Recovery and the Audit Trail#

• Containment is separated from punishment. The engine decides; one containment module performs every Discord call, so roles, quarantine, lockdown and the case/log entry happen in a single ordered, auditable place — and the same per-guild queue means a burst cannot interleave two attackers' actions.
• Roles are removed, permission-locked, then restored from a trusted snapshot. Permission lockdown is set per server as targeted (the default — only the roles the attack touched), full, or off, and it reads its trusted state from the same Server Recovery snapshot the Restore page shows rather than a second permission store that could disagree with it. Releasing a lockdown is an authorised dashboard action, never something the bot does by itself.
• Every containment is recoverable. Recovery runs before a quarantine is released, restores the resources the attack changed, and reports FULL / PARTIAL / FAILED with the real reason per item — never a silent skip. Recovery is idempotent, so re-running it does not double-apply.
• Every containment writes a case and a mod-log entry (the anti_nuke event), so it sits in the same audit trail as a moderator's own action.

Dry Run, Test Mode and Attack Replay#

• Test mode runs a scenario through the real pipeline against your configuration and reports the action it would have taken. It is pure, so it works even while the bot is offline, and the "actual action" is always simulation only.
• Attack replay re-scores a recorded incident against your current settings and flags a regression — the way to check a threshold change before it matters.
• Dry run keeps detection, scoring, logging and alerts, and skips every action with a dry-run reason recorded on the incident.

Trusted Actors, Maintenance Mode and Startup#

• Trusted users and roles are always logged, never contained — the exemption is recorded with its reason instead of being invisible.
• Maintenance mode suspends containment for a duration (capped at 24 hours) so a planned reorganisation is not mistaken for an attack. It expires by itself, and detection and logging continue while it is on.
• Azra's own actions are never attacker activity. Operations the bot performs are marked at the source and skipped, so Azra cannot accuse itself of a nuke.
• A restart recovers open incidents: quarantines released, lockdowns lifted, resources restored, permission and role-hierarchy health verified and alerted, and a baseline taken for any server that never had one.

Detect → Score → Confirm → Contain → Monitor → Recover → Report. A raid is judged on several independent signals — never on a join count alone — and every containment action is reversible.

How a Raid Is Scored#

Azra watches rolling 10-second, 30-second, 1-minute and 5-minute windows plus an adaptive baseline built from your server's own history, so "unusual for this server" is what raises a reading. Two scores come out of it:

Incident signals and default weights#

The weights deliberately sum to more than 100 and the score saturates, so no single signal can walk into a containment band on its own.

Protection Modes#

Risk Bands and Response Levels#

Each band asks for a minimum response, and the engine never acts above the level it was granted:

Containment Is Reversible by Design#

• Before anything changes, Azra records a protection snapshot of the channels, permissions and settings it is about to touch. Recovery restores exactly that.
• Quarantine releases the members it isolated on suspicion alone. Anyone still above the high account-risk band (61+) stays quarantined for a human to review, and the report says how many.
• Recovery starts only after the server has stayed quiet for the recovery cooldown, so a second wave cannot arrive mid-restore.
• Open incidents and lockdowns are re-armed at startup: a restart mid-raid restores the snapshots and lifts any lockdown whose incident has already closed.

Dry Run, Test Mode and Debug#

• Dry run — detection, scoring, logging and staff alerts all run; every action is skipped, with the reason it would have acted recorded on the incident. Start here.
• Test Mode — runs the whole scenario catalogue against your thresholds and shows the expected action beside the action that would have been taken. Nothing is ever executed.
• Debug — prints the score composition (which signals fired, their weights and the confidence cap) on the incident and in the log line.

Incidents and Member Verdicts#

A raid is one incident, not a stream of separate alerts: it gets an id, a state, a timeline and a per-member verdict table (risk, account age, action taken, verification state). Related waves inside the window join the same incident rather than opening new ones. The dashboard's Incidents section lists state, risk, start, duration and join count, and opens the full timeline.

What Raid Protection Deliberately Does Not Do#

• It never deletes or punishes for messages. Message, mention and duplicate-content bursts are scored as raid signals, but enforcement stays with Auto Moderation — so the two systems cannot double-punish the same message.
• It never bans on heuristics. Kick and ban sit behind critical risk plus high confidence; everything below that is reversible containment.
• The live counters live in the bot process. The dashboard shows the incident row the engine keeps rewriting (about every 5 seconds) rather than a live socket feed.

Configuration#

What Happens During a Raid#

The lockdown timer is persisted: a restart while a lockdown is active recovers it from the database and keeps counting, and a restart mid-incident re-arms the incident that was already open rather than opening a second one.

Force new members to solve an image CAPTCHA before they can participate in your server.

Verification Flow#

Setup#

1. 1

   Let Azra build the gate — or map your own assets

   Open Dashboard → Security → Captcha and press Create & map the whole setup. Azra creates (or reuses, if they already exist) a Verification category with a public #verification channel, a private #verification-logs channel that only admins and moderators can see, and the Unverified and Verified roles. Prefer your own? Pick them in the dropdowns instead — any of the four can be re-pointed at any time. You don't need to set up channel permissions yourself: the bot hides every channel and category from the Unverified role automatically (see below).

2. 2

   Review, then press Save changes

   Everything the wizard produced is shown in the pickers but nothing is live until you save. The Captcha Verification toggle cannot be switched on while the Unverified role, Verified role or Captcha Channel is missing — the dashboard says which one is still needed.

3. 3

   Post the verification panel

   Use the Post Panel button to post the persistent "Start Verification" panel in your captcha channel. Every result — verified, manually approved, rejected, timed out — is written to your log channel.

Configuration Options#

Automatically identifies and removes bot-like accounts before they can cause harm.

When enabled, the system runs silently in the background on every new member join. Accounts identified as bots are acted on automatically — no manual review needed.

Configuration#

Catches coordinated spam attacks where the same message is pasted across several channels — or repeated over and over — inside a few seconds.

Messages are matched by content hash, so case and whitespace differences don't evade detection. The Configure window has its own Save changes button and confirms with a “Settings Saved” notice — nothing is live until it is saved.

Who is exempt#

• Messages shorter than 4 characters are never tracked — “ok” and a lone emoji are conversation, not spam.
• Members who can Manage Messages, and administrators, are exempt: staff routinely paste the same announcement into several channels on purpose. Test with an ordinary account.

The audit trail#

Every incident is logged with the member, how many duplicates landed in how many channels, the action taken, the exact text that was pasted and the channels it was pasted into. Delivery is routed on the Logging page (Dashboard → Logging) under the Copy-Paste Guard event — a moderation event, so with no route of its own it falls back to your mod/AutoMod log. The same records appear in the Configure window's Recent Events list.

Snapshot + backup + difference detection + recovery preview + selective, emergency or full restore + rollback + validation. Nothing is ever changed without showing you what will change, and nothing is ever deleted.

What a Snapshot Captures#

A manual or dashboard snapshot is a comprehensive backup — not just channels and roles:

Each snapshot also stores metadata for integrity: a version, the bot version, owner ID, per-category counts, byte size, and a SHA-256 checksum. A snapshot that omits a section says so in its own metadata (omitted) instead of showing zeroes that would read as "up to date".

Snapshot Types#

auto, pre_nuke and pre_restore snapshots stay lightweight on purpose — they run at busy moments (on join, mid-attack, mid-recovery) and skip the REST-backed sections (AutoMod, events, invites, webhooks) rather than writing empty lists. A manual snapshot is the deep one, and it includes the member map (who holds which roles) by default — a full membership read, which is exactly the kind of work only an occasional, deliberate backup should do.

Keeping Snapshots#

• 5 snapshots are kept per server, and the oldest auto makes way for a new one first. A pinned snapshot sits outside that limit and is never auto-deleted — pin the one you took before a restructure and it stays until you release it.
• Automated snapshots run on a schedule you choose per server, so a server that is never restructured still has a recent known-good point to compare against.
• Every restore is rate-limited by a cooldown, shown on the page before you press anything.

Recovery Preview — Nothing Changes Before You See It#

Every Restore button opens a preview first. It is read-only: Azra captures the live server, diffs it against the snapshot and reports what is missing (in the snapshot, not in the server), what changed (present in both, different settings) and what is extra (in the server now, not in the snapshot). Extra objects are counted and named — and never deleted.

The Recovery Pipeline#

1. Preview — read-only diff of the snapshot against the live server.
2. Approve — you pick the mode and the scopes; the page posts the exact list you agreed to.
3. Safety snapshot — a pre_restore snapshot is taken before the first write, and the restore aborts if it cannot be taken.
4. Restore — the engine walks the scopes in a fixed order, one handler per scope.
5. Validation — the server is re-read and the same diff is run again.
6. Report — per-section restored / partial / failed, plus everything that cannot be restored, named.
7. Rollback — one click restores the safety snapshot from step 3.

Objects are rebuilt in this order, because Discord decides it: roles → channels and categories (with positions) → permissions → server settings → AutoMod → events → emojis and stickers → members (and nicknames). Settings come after channels because a settings restore has to resolve the AFK, system and rules channels a channel restore may just have created; AutoMod follows both because its exemptions name roles and channels; member roles are last because they need the roles, the hierarchy and the channels to exist. Restoring settings "first" would write empty channel ids and still look like a success.

After a Restore — Validation, Report and Rollback#

The validation report is derived from the server after the restore rather than from the engine's own summary, so a restore that reported success while something did not come back is caught. Each section lands in one of four states:

• ✅ Restored — recreated or re-applied
• ✳️ Partial — some items restored, others refused by Discord (rate limits, missing permissions, emoji slots full)
• ↩️ Reference only — captured for the record but not recreatable by a bot (invites, webhook tokens, the vanity URL)
• ⏭️ Skipped — e.g. a role above the bot, a managed role, or a scheduled event whose start time has passed

Every restore keeps its history — who ran it, which scopes, which safety snapshot it came from and the validation result — and Rollback restores the safety snapshot in one click. A run is bounded (500 member changes and 200 role moves) so a large server cannot be hammered: the remainder is counted and reported, and running it again finds the first pass's work already done.

What a Restore Will Never Do#

• It never deletes. An object that exists now and not in the snapshot is reported as extra and left exactly as it is.
• Member roles are add-only. A role somebody gained after the snapshot is not taken away — the removal is reported, never applied, because that would punish them for work they did afterwards.
• A member who has left is a number, not a queue entry. Discord has no API for adding a user to a server, so they are counted and listed so their roles can be applied if they return.
• Roles are re-mapped to their new ids. A role recreated in the same run has a new id, and an assignment of a dead id is silently ignored by Discord — which is how a "successful" recovery leaves everybody without roles.
• It never touches message content. Messages are never stored.

What Cannot Be Restored#

Deletion Log (12-hour Window)#

Every deleted channel, role, and ban is kept in a short-term recovery log with a 12-hour window. You can manually recover individual items within that window even without a full snapshot restore.

Automatically kicks accounts that are too new before they can interact with the server. Role assignment is handled by the Captcha system.

How It Works#

Turning It On — the activation gate#

Flipping the Verification switch on the Security page does not enable anything by itself: it opens a setup window, because an age gate with no threshold is switched on and doing nothing. The window already contains a sensible default — 3 days — so the fast path is to look at it and press Confirm & Enable. The feature only goes live on that press.

1. Minimum account age — the default 3 days, or any value from 1 to 365. Azra never stores a threshold of 0: the switch is what turns the gate off.
2. Create Verification Logs Channel (optional, off by default) — when you turn this on, Azra creates a private #verification-logs channel (visible to admins and moderators only, adopted rather than duplicated if one already exists) and maps it for you. Leave it off to pick a channel you already have, or none.
3. Confirm & Enable — writes the configuration and puts the gate live. Dismiss the window before confirming and the switch goes back to where it was; nothing is half-enabled.

Configuration#