AUTHORIZE
AUTHORIZE · LEGAL

Privacy Policy

Last revised: 10 October 2026 · This policy explains how the current starter operates, including its limitations.

Support and privacy inquiries: Authorize Discord support

1. Overview and scope

This Privacy Policy explains how the Authorize Discord verification bot and its companion website handle information when someone interacts with the service.

The policy covers server verification, dashboard sign-in, anti-raid controls, security records, flags, the global flag search, and appeal handling.

Authorize is an independent application and is not operated by or endorsed by Discord.

This document describes the current starter implementation, not capabilities that may be added in a later update.

  • Some features are controlled by the Discord server owner and vary from one community to another.
  • Some data is supplied by Discord when a bot or application has access to it.
  • Website sign-in and Discord bot functions may process different categories of data.
  • Details about hypothetical future features do not mean those features are currently deployed.
  • The operator should keep this page updated whenever the data handling changes.

2. Current implementation: quick reference

Authorize currently uses Discord OAuth2 for website login and Discord API access for bot and server functionality.

The application stores configuration, limited account identifiers, verification attempts, security events, and flag and appeal records in an SQLite database.

The website now records visitor IP addresses in its application database for security diagnostics, with no automatic expiry under the default configuration; the operator is responsible for reviewing and deleting records when required.

IP matching and cross-account IP correlation are NOT active in this release.

  • Member risk checks currently use signals such as account age and server join patterns.
  • Staff-configured verification failure limits can create server-local flags.
  • Global security flags can currently be created and removed by the Authorize bot owner.
  • Global security flags are not automatically generated from IP matches.
  • Appeals currently receive manual owner review; there is no live automatic AI appeal reviewer.
  • Verification works by Discord button, a mixed challenge, or a website challenge when configured.
  • Server managers can upload verification panel images (PNG, JPEG, GIF, WebP). Images are saved in local server storage and attached to Discord messages when published. Replacing or deleting the image removes the active local copy; previously published Discord attachments may remain.

3. The information visible to Authorize

Discord may supply Discord user IDs, display names, usernames, guild memberships and permissions needed to operate the bot.

The bot may also access account creation dates, join events, assigned roles, server and channel IDs, and messages in accessible channels when monitoring is enabled.

Access depends on Discord permissions and granted intents.

  • Discord user IDs identify accounts across interactions with the application.
  • Usernames and display names may change and are not permanent identifiers.
  • Server IDs identify the Discord servers using the service.
  • Channel IDs are used to send configured verification panels or security logs.
  • Role IDs determine which roles are assigned or removed after successful verification.
  • Member counts may be shown to authorized dashboard users.
  • The application does not obtain Discord login passwords.

4. Discord OAuth2 sign-in

Discord login sends users to Discord to authorize a limited OAuth2 interaction.

The website requests the identity and guild list permissions needed for account identification and dashboard navigation.

The app uses the returned identity to establish a signed website session.

  • The current website session stores a Discord user ID and display name.
  • Session anti-forgery values protect form submissions and OAuth login callbacks.
  • The application uses a browser session cookie to maintain sign-in state.
  • The code does not store a visitor's Discord password.
  • The app should not expose client secrets or bot tokens in web pages.
  • Leaving or logging out ends the local application session, subject to browser cookie behavior.

5. Server configuration information

Authorize stores settings that let a Discord server owner configure verification and protections.

Some of those settings relate to the roles and channels of a server rather than to individual people.

  • Verification method selection is saved per server.
  • Verified and unverified role IDs may be saved for role assignment.
  • Verification message titles, descriptions, colors, and image links may be saved.
  • Welcome-message options and log-channel IDs may be saved.
  • Join limits, join windows, and cooldown settings may be saved.
  • Anti-raid and AutoMod thresholds may be saved.
  • Authorized dashboard role and user grants may be saved.

6. Verification attempts and challenges

The application may record a success or failure when a person attempts verification.

Records help enforce cooldowns and configured security responses.

  • A recorded attempt includes the relevant server ID and user ID.
  • The outcome indicates whether verification was successful.
  • Failure reasons may include an incorrect or expired challenge.
  • The time of the attempt is recorded as a timestamp.
  • Repeated failed attempts may trigger a cooldown.
  • Server settings can create a local flag after a configured number of failures.
  • Temporary challenges have a limited lifetime; successful challenges are deleted from the active challenge table.

7. Discord verification and role changes

Successful verification can enqueue a task for the bot to update a member's Discord roles.

Role management requires the bot to have the appropriate Discord permissions and role hierarchy position.

  • The application records whether a verification step was accepted.
  • The bot may add verified roles selected by a server owner.
  • The bot may remove roles selected by a server owner.
  • A verification event can appear in server security history.
  • A failed role change may create an operational error record.
  • Verification records are not evidence of a person's real-world identity.

8. Anti-raid signals and account age

Authorize can compare the timing of server join events to a configured threshold.

It may also examine the age of a Discord account when the server has configured age-related checks.

These are risk indicators, not proof of malicious intent.

  • Join spikes may trigger an additional verification requirement.
  • A temporary lockdown can be applied to a server.
  • Recently created accounts may receive a local flag for extra verification.
  • Staff may receive security alerts if configured.
  • False positives can occur during legitimate community events.
  • Account age by itself is not a basis for an automatic global flag in this release.

9. Message moderation signals

When server owners enable the available AutoMod behavior and grant the required permissions, the bot can inspect accessible message activity for anti-spam purposes.

The current code uses short windows of message activity to identify configured patterns rather than advertising a complete message archive.

  • The bot may process message metadata to enforce rate limits.
  • It may process message content where Discord permits that access.
  • It may take configured moderation actions such as alerts or message deletion.
  • Incident records may mention the relevant member ID and the reason for action.
  • Different servers may enable or disable these features independently.
  • Server owners should tell their members when automated moderation is active.

10. Local security flags

A local flag applies to a single server and does not automatically represent a platform-wide finding.

Flags may be created because of repeated failed challenges or a suspiciously new account where the rule is enabled.

  • A local flag stores the server ID and Discord user ID.
  • It includes a reason for the flag.
  • It includes an action mode such as alert or extra verification.
  • A created timestamp may be stored.
  • An optional expiration timestamp may be stored.
  • Server-local flags should not be described as proven wrongdoing.
  • Server-specific staff access to flags is subject to configured dashboard permissions.

11. Global flags and visibility

The Authorize bot owner can create global flag records using the private owner dashboard.

The current site lets Discord-authenticated visitors search confirmed flags by username or Discord user ID.

A flag is not a criminal finding, identity proof, or necessarily an accurate claim.

  • A global flag record may include a Discord user ID and username.
  • A flag also includes a category, reason, status, source, and creation timestamp.
  • Basic search results show account name, Discord ID, category, and status.
  • Internal reasons and investigation notes are not meant for open search results.
  • Local server flags are not automatically copied into the global directory.
  • Global flag decisions should be supported by reliable records and kept under review.

12. Account correlation and suspected alts

The current version does not identify accounts through shared IP addresses.

Any later correlation feature would require a new implementation, a clear notice, a documented lawful basis, and suitable protections.

  • One household may have several legitimate Discord accounts.
  • Schools, workplaces, mobile networks, and VPN users may share outward-facing IP addresses.
  • A matching IP does not establish that two accounts belong to one person.
  • New-account status and failed verification are similarly imperfect indicators.
  • The current system may request additional verification based on configured server-local signals.
  • Suspected alternates should not be automatically publicly identified from a weak match.

13. IP addresses: current behavior

The Authorize website records IP addresses for page visits for abuse prevention and troubleshooting. These entries are stored in the visitor_ip_visits table and retained until deleted when the default 0-day (unlimited) setting is used; operators can set a finite retention period.

Discord does not supply member IP addresses to a bot through its ordinary API.

Infrastructure outside the application, such as a reverse proxy or hosting provider, may create separate network access logs under its own settings.

  • The bot owner can access a private Website IP Visits page at /owner/visitors; access requires the configured bot owner Discord ID.
  • Website visit records include IP address, page path without query string, first and latest timestamp, grouped visit count, and the Discord ID only when logged in.
  • The application does not currently join accounts using IP addresses.
  • Recognized bot-owner sessions are excluded from application visitor IP logging. This exception cannot reliably identify owner traffic before login.
  • The OAuth login and callback routes are excluded from application visitor IP logging; the hosting provider may keep separate logs.
  • The operator must inspect actual hosting logs before making any claims about infrastructure IP retention.

14. Visitor IP logs: security purposes, retention, and safeguards

The current website collects site visitor IPs for security monitoring, rate-abuse investigation, and troubleshooting. It does not automatically merge Discord accounts based on IP matches.

The application keeps no passwords, OAuth callback query strings, or full browser headers in these visit records.

Records for the same IP, page and account in a minute are grouped to limit storage. With the default unlimited setting, rows are not automatically removed; an operator may delete matching IP records or configure a finite retention period.

  • Visitor logs contain the network IP address supplied by the connection, an optional signed-in Discord ID, the requested path, UTC timestamps and a page-view count.
  • Visitor IP records come from website HTTP traffic, NOT from the Discord API. A Discord bot cannot see the IP used inside Discord.
  • Detailed website IP logs are only visible to the configured bot owner through the private owner page.
  • Visitor logs have no automatic expiry by default (VISITOR_LOG_RETENTION_DAYS=0). A positive value configures automatic cleanup after that many days (maximum 3650). Records may be deleted sooner in response to valid privacy requests or security needs.
  • A shared IP is NOT proof that accounts are connected, and current visitor IP logs do not automatically create a local or global flag.
  • Website visitor IP logging can occur before Discord login. No Discord ID is attached to those anonymous visits.
  • User rights and appropriate deletion channels must continue to apply.

15. Owner accounts and access exceptions

The owner control center uses a configured Discord ID to restrict access to administrative functions.

That access restriction does not guarantee exemption from hosting-company network logs.

  • The current `/owner` route compares the logged-in ID with BOT_OWNER_ID.
  • The application distinguishes owner access from server-specific dashboard permissions.
  • A server owner cannot see Authorize-wide owner tools solely because they own a Discord server.
  • Website activity by an owner may still be visible to external infrastructure in normal network operations.
  • Access control is not a replacement for secure credentials and multi-factor authentication.

16. Website sessions and cookies

Authorize uses a session cookie to keep track of signed-in users and temporary form state.

The cookie is part of the web application's authentication process.

  • Session contents are integrity-protected using the application's secret key.
  • Cookies use HttpOnly and SameSite settings in the present configuration.
  • The Secure attribute depends on use of an HTTPS base URL.
  • Discord OAuth login state helps detect invalid callback attempts.
  • Clearing cookies or switching hostnames may invalidate a login attempt.
  • The project does not currently include a separate behavioral-advertising cookie system.

17. Security events and audit records

Security events support troubleshooting and help permitted administrators understand the server's defenses.

Records can include the event type, relevant server and user identifiers, a short description, and a timestamp.

  • Security events may record successful and failed verification.
  • They may record raid detections or temporary lockdowns.
  • They may record local flags and global flag operations.
  • They may record moderator commands or configuration changes.
  • They may record appeal creation and appeal decisions.
  • They may record when a person exports a log report.
  • Audit logs do not guarantee a complete history of all Discord activity.

18. Appeals and reviews

A member can submit an appeal for a confirmed global flag associated with their Discord ID.

The present version stores the submitted text, the account ID, flag ID, status, and a later review decision.

  • Members may provide explanations through the website form.
  • Appeals are currently reviewed by the Authorize bot owner.
  • The live starter does not run an automatic AI reviewer.
  • The system does not currently provide evidence file uploads for global appeals.
  • The appeal history may remain in the database after a decision.
  • Appeal outcomes may be recorded in security events.
  • The operator should provide a way to correct mistakes or request human review.

19. AI and automated decision-making

Authorize does not currently transmit appeal text to an external AI reviewer.

If AI appeal handling is added, the site must disclose the provider, data categories, safeguards, and review options before use.

  • Automated recommendations are not the same as verified evidence.
  • AI-generated summaries may be inaccurate.
  • An AI decision should not be treated as proof of identity or misconduct.
  • Members should be able to challenge harmful or incorrect outcomes.
  • High-impact decisions may need a human review and an assessment under applicable privacy law.

20. Dashboard permissions

The bot operator and individual server owners have distinct access levels.

A server owner may be able to grant dashboard access to selected user IDs or Discord roles.

  • The private bot-owner dashboard is protected using the configured BOT_OWNER_ID.
  • Server-specific access is checked against Discord guild membership and saved grants.
  • Permissions may control settings, verification, logs, flags, and other dashboard areas.
  • A person removed from a server may lose access to its dashboard.
  • Authorized staff must use their access only for legitimate community management.
  • The application operator is responsible for protecting privileged sign-in credentials.

21. Exports and downloaded records

Administrators with permitted access can export selected activity records in supported formats.

The current starter supports JSON and CSV export of certain server event records.

  • A downloaded export may contain Discord user IDs and event details.
  • Whoever downloads an export may create an additional copy outside Authorize.
  • Recipients must protect downloads from unnecessary disclosure.
  • Re-sharing security records without a legitimate purpose may violate privacy expectations or law.
  • PDF exports are not enabled in this starter merely because they appeared in planning discussions.

22. Retention and deletion in the starter

The SQLite database saves many non-visit records without an automatic general retention schedule in the current starter. Visitor IP logs are not automatically deleted when their retention setting is 0; operators must establish and observe any required deletion schedule.

That is an implementation limitation, not permission to keep personal data forever.

  • Temporary verification challenges expire after a short period.
  • Local flags can have an expiration value when configured.
  • Expired local flags may remain as database rows until cleaned up separately.
  • The starter does not automatically delete every old event or verification attempt, and visitor IP logs persist until deleted when the default unlimited retention setting is active.
  • Removed global flags may remain in database history unless an authorized deletion process removes them.
  • The operator must assess and document a valid legal basis, necessity, data-subject rights, and appropriate retention limits before public deployment. Indefinite IP retention may be unlawful in some jurisdictions.
  • Personal data should not be retained longer than genuinely needed for the purpose.

23. Requests to access, correct, or delete information

Depending on applicable law, people may be able to request access, correction, deletion, restriction, or information about data handling.

Requests should include enough detail to identify the relevant Discord account without sharing a password or secret token.

  • The operator should provide a working privacy contact method.
  • Requesters may be asked to authenticate ownership of the relevant Discord account.
  • The operator should avoid sharing another person's private security records.
  • Records kept solely for necessary legal or security reasons may require case-by-case review.
  • Inaccurate confirmed flags should be corrected or removed when appropriate.
  • Future deletion mechanisms should also address backups and exported copies where feasible.

25. Third-party services

Authorize relies on Discord to provide identity and messaging functions.

The operator may also use a hosting provider to run the website and database.

  • Discord's own privacy policy applies separately to Discord's services.
  • Hosting providers may process network connection logs to operate their infrastructure.
  • This starter does not currently forward appeal text to an AI provider.
  • External integrations added later require disclosure before use.
  • Service providers should be chosen with attention to security and data handling.

26. Security safeguards

The project includes protections such as login-state checks, restricted dashboard routes, and anti-forgery form tokens.

These mechanisms reduce some risks but do not guarantee that the service is free from vulnerabilities.

  • The bot token and client secret belong in server-side environment variables.
  • Passwords, OAuth secrets, and private access tokens must not be shared publicly.
  • Privileged routes should be used over HTTPS before a public launch.
  • Database backups and exports require access controls.
  • Hosting logs and reverse-proxy settings must be reviewed separately.
  • Security patches and dependency updates remain the operator's responsibility.

27. Children's privacy and community safety

Authorize may be installed in servers where younger Discord users participate.

The operator should avoid collecting data that is unnecessary for safe account verification.

  • Authorize does not need real-world names to verify a Discord membership.
  • The application does not ask members for passwords or payment-card details.
  • Excessive profiling or public accusations can affect vulnerable people.
  • Server operators should use extra care when configuring monitoring for communities with minors.
  • Legal age requirements and regional privacy obligations may apply.

28. Changes to the Privacy Policy

This policy must change when Authorize changes what it collects, stores, shares, or deletes.

Material changes should be communicated appropriately before new processing begins.

  • Update the effective date when publishing a revised notice.
  • Do not describe future features as currently running.
  • Explain new processors or transfers before enabling them.
  • IP logging is now active on website GET page visits, with a visible footer disclosure, a private owner review page, manual deletion tools, and unlimited default retention.
  • Preserve records of decisions when privacy terms materially change.

29. Operator details and contact

The identity and contact method of the actual Authorize operator should be supplied before the website is made public.

The project starter cannot infer the legal name, business address, or contact email of its operator.

  • A contact address should receive privacy and data-deletion inquiries.
  • The operator should describe relevant hosting and retention arrangements.
  • People should not have to publish private information to make a rights request.
  • Discord account ownership can be used as one way to verify an inquiry.
  • An unconfigured contact field means this notice is not ready for public use.