Privacy
What Wardnox stores, and what it never touches.
Wardnox is self-hosted. There is no Wardnox-operated service, no telemetry and no phone-home. Whoever runs the deployment is the data controller, not us.
Clean messages are never stored
The overwhelming majority of traffic is scanned entirely in memory and written nowhere. Only messages that produced a security event are kept, 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.
Never stored at all
- Direct messages. There is no DM intent; Wardnox reads guild messages only.
- Voice, presence and typing. Never read, never recorded.
- Discord access tokens at rest. They live in a sealed 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.
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 leaves the deployment by default
There are four optional outbound paths, and each needs an environment variable and a server setting before a single byte goes anywhere: link resolution, threat intelligence, AI analysis, and the conversation and knowledge features.
When they are enabled, what leaves is URLs, a truncated projection of the message text, and the reasons that already fired. What does not leave: user IDs, usernames, channel IDs, guild IDs, or any other Discord identifier. Reputation lookups are read only and never submit a URL for scanning, because submitting would publish a link from a private server to a public analysis service.
Retention
- Security events: 90 days by default
- Violations: 365 days by default
- Audit log: 365 days by default
- Conversation records: follow the security event window
All are configurable between 1 and 3,650 days, and an hourly job enforces them. One honest exception: configuration snapshots have no retention setting and are not purged automatically.
Optional anonymisation
User identifiers 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.
Deletion
Deleting a guild record cascades through every guild-scoped table. Removing the bot from a server soft-deletes instead, so that re-inviting it restores the rules the administrator wrote. There is currently no built-in per-user subject-access-request export endpoint.
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.