Features
Everything an administrator can reach.
Wardnox is a security platform first and a community layer second. The community layer runs behind the same gate, which is why the bot will answer a question but never a scam.
Authoring
Rules you wrote, and can explain.
Three rule types, each scoped as narrowly as you like, each recording why it exists.
Word rules
Several ways to match, with word boundaries that understand accented and non-Latin text rather than assuming plain ASCII. Phrase rules tolerate the punctuation and spacing somebody puts between words to break them up, without ever becoming slow to evaluate.
Regex rules
Checked for dangerous constructions before they save, run isolated and time bounded, and testable in the dashboard against whole multi-line text rather than one line at a time.
Domain rules
Allow or block, with or without subdomains, resolving what a domain genuinely is rather than comparing the end of a string. A block always wins over an allow, because a stale allow entry nobody cleaned up should not be the thing that lets something through.
Phrase groups
Named sets with a weight, a severity and an emitted reason code. The reason code is load-bearing: it is what a combination bonus keys off when it looks for two things happening together.
Every rule carries notes
A field for why the rule exists. Six months later, that is the difference between tuning it and deleting it out of caution.
Scoped how you need
Include and exclude by channel and by role, monitor-only, or flagged to run even against trusted accounts.
Scope
Different rooms, different rules.
A support channel and a general channel are not the same risk, and should not share a threshold.
Channel policies
Inherit, watch only, off, strict, or fully custom. Each can set its own sensitivity, its own link policy, which detectors apply, and how much weight to give the room.
Category policies cover what does not exist yet
Policy is inherited outwards, so a setting on a category covers the channels created inside it later. That is the only workable answer for a ticket system, where the channels do not exist yet when you configure it.
Trust roles, not people
A role entry survives staff turnover; a user entry does not. Trust can also be given an expiry date.
Security profiles
Low, normal, high and lockdown are patches over the defaults rather than separate formats, so picking one then loosening a single setting does not silently revert everything else.
Members
The gate, and what happens after it.
Verification, greetings and conversation all run behind the same security engine.
Verification you can pitch at the right level
A range of challenges, ordered by how much they ask of a member, from a single click up to something a script will not get through. Pick the lightest one that solves your problem. Nothing about the expected answer is stored server side, so a restart never strands somebody mid-verification.
Tuned for the people, not the theatre
The point is to stop automated joins without punishing the humans behind them. A challenge that real members repeatedly fail and give up on has cost you the community it was meant to protect.
Welcome after the gate
Greetings are sent after verification passes, so a join-raid cannot flood a channel with welcomes for a hundred accounts that never got in.
Conversation, off by default
A server that installed an anti-scam bot did not ask for a chatbot. When enabled, it replies only to messages the engine has already cleared, so a scam is removed rather than answered.
Project knowledge
Index your docs by paste or site crawl, and the bot answers from them. The model was chosen on a fabrication benchmark rather than price: a bot that confidently sends members to a channel that does not exist is training them to follow instructions from a bot.
It never DMs a member first
Someone who is actioned gets no direct message, deliberately, so they cannot learn exactly what triggered it and work around it.
Operations
Answering “what happened, and why”.
Every decision is a record you can read, attribute and reverse.
The arithmetic, rendered
Both the dashboard and the Discord log embed show the score derivation line by line, including a line for every detector that hit its ceiling and what it would otherwise have scored.
Moderator actions in the log
False positive, trust, ignore, timeout, kick, ban, and allow or block the domain, all from the log entry itself. Marking a false positive also attributes it to every rule that fired, so rule performance stays honest.
Per-rule false-positive rates
A rule getting a few wrong is normal. A rule getting many wrong is not a rule to soften, it is a rule to rewrite or delete, and the dashboard tells you which of yours is which.
The playground
Runs your real rules against real text through the same engine, returning the full normalisation ladder, every parsed URL and the complete score derivation. It cannot reach Discord.
Config snapshots
Taken automatically before every settings change, profile switch and import. Restoring is itself snapshotted, so a restore can be undone.
Backups that are verified, not assumed
Nightly, off-platform, and checked twice: a custom-format archive keeps its table of contents at the front, so a file truncated to its first 200 KB still lists every table and exits zero. The archive is also restored and its rows counted. An untested backup is a hypothesis.
Start with the parts you need.
Almost all of this is off until you turn it on. Join the whitelist and we will get in touch when your server can be added.