What Wardnox stores, and what it never touches.

Last updated 17 September 2026. Wardnox, contactable at [email protected].

Who decides what, and why it matters to you

Two different things happen under one name, and the difference decides who you ask when you want something changed.

Inside a Discord server, the administrator decides and we carry it out. They choose whether Wardnox is installed at all, which detectors run, what the thresholds are, whether messages are stored, how long anything is kept, and whether the AI features are on. We act on that configuration. If you are a member of a server and want to know why a message of yours was flagged, or want it removed, the server’s administrators are the people who can answer, because we hold the data on their instructions.

For our own account and website, we decide. Signing in to the dashboard, billing, the whitelist form, our own security logging: those are ours, and you can come straight to us about them.

The text of an ordinary message is never stored

The overwhelming majority of traffic is scanned entirely in memory and its text is written nowhere. Message text is kept only where a detector actually found something, truncated, for a retention window the administrator sets. Turning message-content storage off altogether is a fully supported configuration rather than a degraded mode. Detection quality is unaffected, because scanning happens before any write.

Two honest qualifications. An administrator can switch on logging of allowed messages, which is off by default and is meant for tuning a new configuration; while it is on, every scanned message is stored with its text. And some optional features record something about an ordinary message without keeping what it said: levelling counts each member’s messages, the conversation feature records that it considered answering, and invite tracking keeps a join and leave history. All three are off unless your administrator turns them on.

Never stored at all

• Direct messages. There is no DM intent; Wardnox reads guild messages only.
• Voice and typing. Never read, never recorded.
• Presence. Not read unless you turn on status screening, which is off by default. That one feature reads custom status text so a scam parked in a profile can be caught. The status is never stored; only which of your own configured phrases matched.
• Discord access tokens in our database. They live in a sealed, encrypted cookie and are revoked with Discord on sign-out.
• Attachment contents. Only the filename, extension, declared MIME type and size are examined. Files are never downloaded.
• Passwords. There are none. Sign-in is Discord OAuth.
• Card details. Payment happens on Stripe’s own pages. We never see a card number.

Secrets are redacted before they are written

When a seed phrase or private key is caught, the matched value is replaced with a visible marker rather than removed silently, the finding’s metadata is dropped wholesale, and content retention is suppressed for that event even when storage is switched on. This happens before the database write and before the log embed is built. A security log that republished the seed phrase it just caught would defeat the point of catching it.

Nothing goes to a third party by default

The AI features, meaning scam analysis, conversation and the knowledge base, are off until an administrator of your server switches them on, and each also depends on the provider being configured on our side. Both have to be true before a single byte goes anywhere.

Your plan permitting a feature is not the same as that feature running. Subscribing to a paid plan, or being inside the fourteen day trial, does not switch any of these on. An entitlement decides what you are allowed to enable; it never enables anything for you.

The company involved is OpenRouter

Worth naming precisely, because our own settings make it easy to get wrong. The model names you see in configuration belong to Anthropic and OpenAI, but Wardnox does not contact either company. Every AI request goes to OpenRouter, which routes it onward to whichever provider serves that model. OpenRouter is the only AI company we have a connection with, and their terms are the ones that govern what happens to a request.

We do not ask OpenRouter to exclude requests from training or to avoid retaining them. Whatever their account-level policy is, that is what applies. We would rather say that plainly than imply a protection we have not arranged.

What each feature actually sends

• Scam analysis. A truncated, normalised projection of the message text, the hostnames of any links in it, and the names of the rules that already fired. No user ID, no username, no channel, no server name, and no other message. It only runs on messages already scoring in a middle band; clearly harmless and clearly malicious ones are decided without it. An administrator can also switch on a setting that replaces the message text entirely, leaving only hostnames and rule names.
• Knowledge search. The text of the question, so it can be matched against your own documentation. Also the documents themselves, once, when they are indexed.
• Conversation. The most, by a wide margin. See below.

The conversation feature is the exception

It would be misleading to fold it in with the others. Answering a question means sending the model enough of the conversation to understand it, so the recent messages in that channel go with it, up to a dozen, each labelled with the display name of whoever wrote it. That includes people who were talking in the channel without addressing the bot. The name of your server goes too.

There is no way to strip that and still have a bot that can hold a conversation, so the control is which channels it is allowed into, and whether it is on at all. A server that enables this should say so to its members, and our guidance to administrators says exactly that. Discord user IDs are never sent.

Besides OpenRouter, three other companies are involved in running Wardnox at all: Discord, which is the platform itself; Railway, which runs our services and hosts the database; and Cloudflare, which serves this website. Stripe handles payment if you buy a plan, and we never see a card number. Some of them process data outside the European Economic Area; where that is so, the transfer relies on the mechanisms in that provider’s own terms, linked above.

If we add another, this list changes with it. Ask us at [email protected] if you want to be told beforehand.

Signing in, and the cookies that involves

Sign-in is Discord OAuth. We store no password and keep no server-side session table. Your Discord access token is sealed inside an encrypted cookie rather than written to our database, and it is revoked with Discord when you sign out.

• Session. Holds the sealed sign-in. Seven days.
• CSRF token. Pairs with the session to stop other sites acting as you. Seven days.
• Sign-in state. Ten minutes, deleted the moment sign-in completes.
• Access gate. While the dashboard is invitation-only, a cookie recording that the shared password was entered. It contains no identifier and is the same value for everybody.

All four are strictly necessary for the service to work. There are no analytics cookies, no advertising cookies and no third-party cookies, which is why this site shows you no cookie banner: there is nothing to ask permission for.

IP addresses

Correcting something the earlier version of this page implied. We do not store IP addresses against Discord members or their messages, and the whitelist form keeps none. But when an administrator changes a setting in the dashboard, the audit log records their IP address and browser user agent alongside what they changed, and that entry is kept for as long as the audit log is, a year by default. It is there so a server can see who altered its security configuration.

Separately, our infrastructure and security providers process IP addresses in the ordinary course of routing requests and blocking abuse, and our own request logs record them.

Automated decisions

Wardnox can delete a message, time a member out, kick them or ban them, automatically, according to the thresholds the server’s administrator configured. Every decision records the reasons behind it.

Automated detection can be wrong. If you were actioned in a server and think it was a mistake, the server’s moderators are the people to ask. They set the rules and they can reverse it. Write to us if your complaint is about how Wardnox itself handled your data rather than about a moderation decision.

Retention

• Security events: 90 days by default
• Violations: 365 days by default
• Audit log, including the administrator IP addresses above: 365 days by default
• Deletion records, where that feature is on: 30 days by default
• Conversation records: replies follow the security event window; records of a message the bot chose not to answer are deleted after fourteen days, or sooner if your window is shorter

Violations and the audit log are configurable between 1 and 3,650 days on every plan. Security events are too, with one exception: raising them above your plan’s history window is refused. That window is seven days on Free, thirty on Guard, ninety on Pro and a year on Scale, and it is also how far back the dashboard will show you.

Keeping less is always allowed, on every plan, at any time. A limit that stopped you holding fewer records would be indefensible, so there is not one. Moving to a smaller plan never shortens a window you had already set either; it only stops you raising it further.

An hourly job enforces whatever is set, and it keeps running for servers that have removed the bot. That is worth stating because until recently it did not: the sweep skipped departed servers, so records that were days from expiring stayed indefinitely. It was fixed on 17 September 2026.

Some things have no expiry, and they are worth naming rather than leaving to be discovered. Punishments, levelling counters, invite history, tickets, analytics counters and records of AI spend last until the server’s record is deleted. Configuration snapshots have no retention setting either, though automatic ones are trimmed to the most recent thirty. Billing records are kept for as long as accounting obligations require.

Optional anonymisation

Identifiers on security events can be hashed with a guild-scoped salt. The same person hashes consistently within a server, so per-user analytics keep working, but not across servers, so anonymised data from two deployments cannot be correlated. This covers security events specifically, not every table that holds an identifier.

Deletion

Deleting a server’s record cascades through every table scoped to it. Billing history is the exception and is kept, because accounting obligations require it. Removing the bot from a server soft-deletes instead, so that re-inviting it restores the rules the administrator wrote. Retention keeps running in the meantime, but the record itself persists until somebody asks us to remove it.

There is currently no self-service export or deletion endpoint. For anything beyond the retention settings in the dashboard, write to us and we will do it.

Your rights

You can ask for a copy of your data, ask for it to be corrected or deleted, ask us to restrict or stop a particular use, ask for it in a portable form, and withdraw consent where we relied on it. You can also complain to the data protection authority for the country you live or work in, and you do not have to raise it with us first.

Which of us to ask depends on the data. For your Wardnox account, billing or the whitelist, write to [email protected]. For data from inside a Discord server, such as messages, moderation records and levelling, the server’s administrators decided what was collected, so start with them; we will help them answer you. We may need to check you are who you say you are before acting on a request, particularly one to delete.

Younger members

Wardnox is a tool for people running Discord servers, not a service marketed to children. Discord communities can and do include minors, and an administrator switching on a feature that records something about members is making that decision on their behalf. That is worth thinking about before enabling levelling, conversation or deletion tracking in a server with a young membership.

Security

Everything travels over TLS. Sign-in tokens are encrypted, not merely signed. Secrets are redacted from logs and from stored findings. Access to production is limited to the people who operate the service. Backups are taken nightly and verified.

No service is perfectly secure and we will not claim otherwise. If you find a weakness, [email protected] reaches us and we would rather hear from you than not.

The whitelist form on this site

This site is a static export and runs no analytics, no tracking pixels and no third-party scripts. The only thing it collects is what you type into the whitelist form: your email address and which page you submitted it from. No IP address, no user agent, no fingerprint. It is used to tell you when your server can be added, and for nothing else. Ask us and we will delete it.

Changes to this notice

This will change as the product does. The date at the top changes with it, and anything that materially affects what happens to your data will be said before it takes effect rather than after.

Join the whitelist