1. Agreement and application
These terms govern access to Authorize, including its Discord bot, website, verification flows, server security settings, and connected administrative tools.
Using Authorize means using a third-party application that operates alongside Discord.
The terms describe the available starter implementation and do not promise functionality that has not yet been built.
- The bot can only act where it has the relevant Discord permissions.
- Discord's own rules and agreements continue to apply independently.
- Server owners may set additional rules for their individual communities.
- Features can behave differently depending on a server's configured settings.
- Use of the service must comply with applicable laws.
2. Definitions
A server owner is the Discord account owning a Discord guild where Authorize is installed.
An authorized dashboard user is a person granted access by a relevant server owner or by the application operator.
- A member is a Discord user who belongs to a participating server.
- Verification is a process that checks an account interaction, not civil identity.
- A local flag is a security note that applies to one participating server.
- A global flag is a cross-server record created and managed by the Authorize operator.
- An appeal is a request for a flag or restriction to be reviewed.
- The operator is the person or organization actually providing Authorize.
3. Eligibility and Discord accounts
You need a legitimate Discord account to use functionality requiring Discord authentication.
You must follow Discord's account rules and relevant minimum-age requirements.
- Do not access another person's account without their authorization.
- Do not submit false identity information to obtain dashboard privileges.
- Do not impersonate an administrator or server owner.
- Do not share OAuth credentials, bot secrets, or account passwords.
- You are responsible for securing access to accounts you control.
4. Installation and authorization
A server owner or another person with sufficient Discord permissions may invite Authorize to a server.
The installer must understand the roles and permissions requested during setup.
- Do not install Authorize in a server without appropriate authority.
- Review the bot's permissions before granting them.
- Role actions can fail if the bot's role is too low in Discord's hierarchy.
- Server-level settings apply only to the selected Discord server unless a feature explicitly uses global records.
- Removing the bot may not automatically erase records in the web database.
5. Verification features
Authorize can provide button, challenge, or website-based verification depending on how a server has been configured.
Verification is an account-access workflow and cannot establish a person's legal identity.
- Button verification may assign configured Discord roles when allowed.
- Mixed challenges may ask users to enter a code or answer a simple question.
- Website verification requires a Discord login in the current design.
- Challenge links and forms should be used only on trusted Authorize pages.
- Some accounts may be asked to complete additional verification because of configured risk controls.
- Server owners must avoid using verification to request unnecessary personal details.
6. Member role operations
Successful verification can result in one or more role changes within a Discord server.
The exact action depends on settings chosen by the server owner and on Discord's permissions model.
- A verified role may be added after a successful challenge.
- A pre-verification role may be removed if configured.
- Role updates may take a short time because they are queued.
- The app cannot bypass Discord's role hierarchy limitations.
- Server owners are responsible for selecting appropriate roles.
7. Verification failures and cooldowns
Server owners can configure retry limits and temporary cooldown behavior.
A failed verification attempt is not automatically proof of a malicious account.
- Incorrect responses can be recorded as failed attempts.
- Expired challenges may require the user to start again.
- Repeated failures may cause a configured cooldown.
- Some repeated failures can create a local security flag.
- Users should be told how to appeal a mistaken restriction.
- Server owners should not configure unreasonable restrictions that unfairly punish mistakes.
8. Anti-raid monitoring
Authorize can watch server join patterns and apply configured temporary protections.
An unexpected join spike may be caused by a legitimate event, promotion, or community migration.
- Join-rate rules can trigger staff alerts.
- Temporary lockdowns can require stronger verification.
- Account-age rules may request additional checks.
- Thresholds should be chosen based on the server's ordinary activity.
- Monitoring cannot guarantee that raids will be stopped.
- Server owners remain responsible for their moderation decisions.
9. Automated moderation
Certain message anti-spam and moderation controls are available when enabled and permitted.
These controls are not a substitute for human judgment.
- Administrators should review any configured moderation threshold.
- Users must not spam commands or exploit message-processing features.
- Automated deletion or timeout actions may produce false positives.
- Moderation actions remain subject to Discord permissions.
- The operator may modify or suspend dangerous automation.
10. Flagging and risk classifications
Security flags reflect specified observations or allegations rather than conclusive proof.
Users and server administrators must not treat a flag as a definitive statement about character or criminal behavior.
- A local flag affects only a particular server.
- A global flag may be visible in Authorize's Discord-authenticated search.
- Category names include raiding, spam/scam, suspicious alt, verification abuse, and server nuking.
- A person's Discord username alone may be insufficient for identity matching.
- The operator should correct or remove inaccurate flags when appropriate.
- Arbitrary or retaliatory flagging is not an acceptable use of the system.
11. Global flag database
The Authorize owner may maintain a database of confirmed global flag records.
Confirmed flag searches currently display limited account and category information to users logged in through Discord.
- Search access does not authorize harassment or contact with flagged users.
- Users must not scrape or republish the directory at scale.
- A flag may become outdated if usernames or circumstances change.
- Search results may omit private reasons or evidence.
- Global flags are not automatically derived from IP matches in the starter.
- Incorrect claims can be challenged through the available appeal process.
12. Local flags and suspected alternate accounts
A server-specific flag may be used to request more verification or alert permitted staff.
A suspected alternate account is a security assessment, not a verified real-world connection.
- Many legitimate members operate more than one Discord account.
- Account age and repeated verification failures can be misleading signals.
- The current version does not identify alternates by IP address.
- Operators should avoid exposing unverified suspicions as public facts.
- Members should have a meaningful way to contest an incorrect finding.
13. Appeals
A member may submit an appeal for a confirmed global flag associated with their account.
Submitting an appeal does not guarantee approval or any specific review timeframe.
- Appeals must be written accurately and without abusive content.
- Do not submit forged screenshots or fraudulent statements.
- The current version uses manual operator review.
- Automatic AI reviews are not part of the live starter.
- Authorized reviewers may accept or deny an appeal using the dashboard.
- Approved appeals may change a flag's status.
14. AI-assisted reviews planned for later
The project may add AI assistance in the future, but that functionality is not part of the current release.
Any such feature should be evaluated for error rates and fair review outcomes before launch.
- Automated reasoning may produce inaccurate summaries.
- A person must not be considered dangerous solely because an algorithm says so.
- Human review should be available for disputed decisions.
- External processing of appeal evidence would need a revised privacy notice.
- Operators should review applicable legal restrictions before enabling fully automated actions.
15. Dashboard login and authorization
The website uses Discord OAuth2 to identify a user seeking dashboard access.
Only appropriately authorized people may access private server settings and security controls.
- A server owner may have full access to their own server's dashboard.
- A server owner can grant certain dashboard permissions to roles or user IDs.
- Granted staff must use that access only for authorized server management.
- The private Authorize owner panel is restricted to the configured BOT_OWNER_ID.
- Attempting to bypass permission checks is prohibited.
- Discord account access may be revoked or changed independently of Authorize.
16. Owner administrative tools
The private owner panel may contain data from multiple participating Discord servers.
Its functions must be used for legitimate service operation and security administration.
- Global flags should have documented reasons.
- Operator actions may be recorded in audit logs.
- Owner privileges must not be shared casually with third parties.
- A server owner does not automatically gain access to global owner controls.
- Sensitive records should not be disclosed outside an authorized investigation.
17. Server-owner responsibilities
Each server owner is responsible for how they use Authorize inside their community.
The operator supplies tools but does not automatically approve every server-specific moderation choice.
- Choose permissions that match actual staff responsibilities.
- Review the impact of stricter verification rules before enabling them.
- Keep member-facing rules and notices accurate.
- Explain any local flagging or appeal procedure.
- Avoid collecting unrelated personal data through custom panel messages.
- Ensure that staff with dashboard access are trusted and trained.
18. Staff access and delegated permissions
Owners may delegate specific dashboard capabilities to staff in the current system.
Delegation does not transfer ultimate responsibility for server decisions.
- Grant the minimum access needed for a staff member's tasks.
- Remove grants when a team member leaves or changes roles.
- Do not share exported security records without a legitimate purpose.
- Do not attempt to view server information outside authorized access.
- Keep role and user grants under periodic review.
19. Website sessions and security
You are responsible for protecting your Discord account and local browser session.
Authorize has session integrity and request validation protections, but no website can guarantee perfect security.
- Use the actual application URL before authorizing Discord login.
- Do not share authentication codes or credentials.
- Log out on devices you do not control.
- A session may expire, or a login may need to be restarted after cookie changes.
- The operator may restrict access in response to clear security abuse.
20. IP address information and accuracy
The website records visitors' IP addresses for security monitoring and diagnostic purposes. Detailed logs are restricted to the bot owner and stored without automatic expiry by default, subject to operator deletion and applicable privacy law.
The Discord API does not give bots the IP addresses of server members.
- The service must not claim to detect matching IPs when the feature is absent.
- Normal web hosting providers may maintain their own access logs.
- Website IP logging is active on GET page visits, while automated cross-account IP matching and enforcement are not active.
- Matching network addresses do not conclusively identify account owners.
- The operator should consider legal and ethical risks before any IP-based correlation.
21. Privacy and data-handling obligations
Use of Authorize is also subject to its Privacy Policy and relevant laws.
Users and administrators should understand what records the application stores.
- Do not attempt to obtain another user's private security records.
- Do not use the service to collect passwords or other sensitive credentials.
- Privacy or deletion requests should be directed to the application operator.
- Website IP visit logs do not expire automatically when the default unlimited mode is enabled. The operator must delete them when legally required; other data categories also need appropriate retention and deletion policies.
- Data handling may change only with an appropriately updated privacy notice.
22. Exporting and sharing reports
Certain records can be exported by users with suitable permissions.
Export files may contain identifiers or allegations that can cause harm if spread carelessly.
- Do not publicly post a member investigation without an appropriate basis.
- Avoid unnecessary copies of exported security logs.
- Store exports securely and delete them when no longer necessary.
- Do not use exports to dox, threaten, or harass anyone.
- Treat security allegations as unproven unless independently established.
23. Acceptable use
Users must not attempt to misuse Authorize or interfere with other servers.
The operator may restrict access where necessary to prevent abuse of the application.
- Do not exploit bugs, vulnerabilities, or form endpoints.
- Do not run automated traffic intended to overload the service.
- Do not impersonate Discord, Authorize staff, or another member.
- Do not submit malicious links or payloads into custom text fields.
- Do not use tools to facilitate harassment or retaliation.
- Do not attempt to bypass CAPTCHA or cooldown mechanisms unlawfully.
24. Reporting security problems
Security issues should be reported privately to the operator through the configured contact method.
Good-faith reports should describe the issue without sharing private user data unnecessarily.
- Do not access data that does not belong to you.
- Do not intentionally interrupt availability while testing a suspected flaw.
- Keep exploit details private until the operator can investigate.
- The operator should prioritize fixing issues that expose private records.
- A report does not authorize security testing against unrelated services.
25. Availability and maintenance
Authorize may be offline for updates, maintenance, network issues, or Discord API restrictions.
The operator does not guarantee uninterrupted service or a particular response time.
- Features depend on Discord's availability and permissions.
- Role updates may be delayed by rate limits or outages.
- Verification can fail if a server removes required permissions.
- Backups may be incomplete unless configured and tested.
- The operator may deploy security patches without advance notice when necessary.
26. Accuracy, reliability, and limitations
Automated security tools may produce incorrect results.
Members should not assume a displayed status is a legally established fact.
- Join thresholds cannot distinguish every raid from a legitimate join surge.
- AutoMod can misclassify ordinary messages.
- Account age is not a complete measure of trust.
- Local and global flags can be incorrect or outdated.
- Some deleted Discord content cannot be restored by the application.
- The service is supplied without a promise of perfect protection.
27. Data ownership and third-party rights
Users keep whatever rights they have in their own content and submissions under applicable law.
The operator may process necessary information to operate the application, as explained in the Privacy Policy.
- The operator does not acquire ownership of Discord accounts.
- Server logos and other uploaded or linked materials must be used lawfully.
- Appeal submissions must not contain someone else's private data without an appropriate reason.
- Exporting data does not give unrestricted rights to republish it.
- Discord names, marks, and services remain subject to Discord's own rules.
28. Changes to services and rules
The project can evolve, and these terms should be revised when the service changes materially.
The operator should give users reasonable notice when required.
- New features may have additional conditions.
- New data collection requires accurate privacy disclosures.
- Previously promised behavior must not be silently replaced with different tracking.
- Effective dates should reflect when a revised policy is published.
- Users may stop using a service they no longer wish to accept, subject to server participation rules.
29. Suspension and termination
Access to Authorize may be limited when necessary for security, legal compliance, or serious misuse.
The operator should use proportionate controls and correct clear mistakes when practical.
- Server owners can remove Authorize from their Discord server.
- Users may leave a server that requires Authorize verification.
- Removing the bot does not by itself erase existing database records.
- Requests for data deletion or correction remain subject to the Privacy Policy and applicable law.
- The operator may retire functionality or end the project.
30. Disclaimers and applicable rights
Nothing in these terms removes rights that cannot lawfully be excluded.
Authorize is a third-party project and is not an official Discord product.
- The operator does not guarantee detection of every raid or scam.
- The terms do not replace Discord's terms or the rules of a participating server.
- The terms do not authorize unlawful surveillance or unrelated profiling.
- Applicable consumer and privacy protections may differ by location.
- The identity, jurisdiction, and contact details of the actual operator must be added before public publication.
31. Contact and requests
Questions about these terms, flagging, or account records should be sent to the configured Authorize operator contact.
Users should never send Discord passwords or secret tokens in a support request.
- Include a Discord user ID only when relevant to a specific account request.
- Describe the server or global flag at issue if applicable.
- Describe whether the request concerns an appeal, account access, or privacy.
- The operator should use a secure channel for sensitive follow-up.
- A missing contact method means the terms are not yet ready for a public launch.