What did the install ask for?
Discord's bot authorization flow can include a permission integer. Save the requested list and question broad grants before approving the installation.
DISCORD BOT PERMISSIONS
Give each bot enough access—without a blank check.
A useful permissions review compares the bot's documented job with its current server-wide grants, channel reach, and hierarchy. Start with effective access, not the confidence of an install screen or a familiar logo.
✓Least privilege✓Administrator is exceptional✓Configuration—not code review
10 OWNER CHECKS
Review purpose, effective access, hierarchy, and trust
Run the checklist for every installed bot, not only unfamiliar ones. A trusted application can become overprivileged as features change and a server accumulates roles, channels, and exceptions.
Record the bot's identity and job
Write down the application name, developer or vendor, install source, business purpose, internal owner, support contact, and the features the server actually uses. A recognizable name is not evidence of a safe or maintained integration.
Capture requested and current access
Save the permissions shown during installation, then inspect the bot's current role permissions, additional assigned roles, role position, and channel overwrites. The install request is a starting proposal; current effective access is what matters now.
Remove Administrator as the default
Administrator grants every permission and bypasses channel overwrites. Require a specific, documented reason before accepting it, and prefer the smallest explicit set of permissions the bot's active features require.
Justify each server-wide permission
Review Manage Server, Manage Roles, Manage Channels, Manage Webhooks, View Audit Log, Kick Members, Ban Members, and Moderate Members individually. Tie every grant to an enabled feature and an accountable owner.
Resolve channel access separately
Check @everyone, the bot's roles, category overwrites, channel overwrites, and any member-specific bot overwrite. Limit View Channel, Send Messages, Read Message History, and Manage Messages to the destinations the job needs.
Place the bot role deliberately
A bot can grant, edit, or sort only roles below its highest role, and can moderate only members whose highest role is lower. Put the bot above the targets it must manage—not automatically above every staff or integration role.
Separate management reach from ordinary permissions
Role order controls which roles and members a bot can manage; it does not decide ordinary channel access. A lower role can still grant View Channel or Send Messages unless the effective permission calculation denies it.
Test the enabled features
Use a controlled channel and representative target role to verify the bot can perform its documented job and nothing obviously broader. Test failure states too, especially private channels, role assignment, moderation, and webhook workflows.
Review data and operational trust outside Discord
Check the vendor's privacy and security documentation, retention claims, incident history, ownership, and support path. Discord permissions do not reveal what the bot's code does with data it can access.
Revoke stale access and schedule review
Remove unused bots, uninstall abandoned apps, clear obsolete channel exceptions, and review permissions after feature changes, reinstalls, staff turnover, or the creation of new sensitive roles and channels.
THREE DIFFERENT QUESTIONS
Requested, effective, and required permissions are not the same thing
A defensible decision answers all three. Comparing only the invite screen or only the role list leaves an important part of the review unresolved.
What can the bot do now?
Resolve @everyone, every assigned role, Administrator bypass, channel and member overwrites, implicit permissions, and the bot's highest role.
What does the active job need?
Map each current feature to an explicit permission and destination. Anything unmatched is a candidate to remove, test, or escalate to the vendor.
High-impact permissions deserve an explicit reason
| Permission | What Discord grants | Question for the owner |
|---|---|---|
| Administrator | All permissions and a bypass of channel permission overwrites | Why can't the job use explicit permissions? |
| Manage Server | Management and editing of the server | Which server setting or native AutoMod workflow requires it? |
| Manage Roles | Management of roles below the bot's highest role, limited to permissions the bot holds | Which exact roles must it assign or edit? |
| Manage Channels | Management and editing of channels | Does it create or change channels, or only post to them? |
| Manage Webhooks | Management and editing of webhooks | Does the feature truly manage webhooks rather than send messages? |
| Manage Messages | Deletion of other users' messages | Is message moderation an enabled, documented feature? |
| Kick / Ban / Moderate Members | Removal, banning, or timeout actions, subject to hierarchy | Which policy authorizes the action and who reviews mistakes? |
| View Audit Log | Access to the server audit log | What feature needs administrative event history? |
Discord's current permissions reference defines each permission, overwrite order, implicit behavior, and bot hierarchy. Its bot authorization documentation explains the requested permission parameter used during installation.
Role height is a capability boundary, not a trust score
Discord limits a bot's ability to grant, edit, and sort roles to roles below its highest role. Kick, ban, and nickname actions also require the target member's highest role to be lower. Moving a bot upward may make a feature work, but it also expands the set of roles or members the bot could affect.
Ordinary permissions do not follow that role order. Effective channel access combines the server's @everyone baseline, all assigned roles, and channel overwrites; Administrator bypasses the channel calculation. Review hierarchy and channel exposure as two connected but separate questions.
Discord permissions cannot audit the bot's code
A server configuration can show what Discord allows, not whether the bot's implementation is secure, its token is protected, the vendor retains data, or a compromised service is issuing commands. Review vendor trust, account security, and incident readiness separately.
DISPLAYSTATE BOUNDARY
Oracle reports configuration evidence without certifying the integration
DisplayState does not request Administrator. Its own documented permissions support server inspection and narrowly approved operations, and its role should sit only as high as the resources in an approved plan require.
Supported role and channel evidence
Oracle can inspect supported role positions, permission values, managed-role markers, channel overwrites, and credential-free integration inventory.
Source code and live behavior
The audit does not reverse-engineer third-party bots, inspect their infrastructure, watch their actions in real time, or read server conversations.
People, vendors, and necessity
You decide whether the developer is trustworthy, the feature is still needed, the permission tradeoff is acceptable, and access should remain installed.
FREE DURING BETA
Find permission risk before the next bot or role change.
Run the free configuration audit, review effective access and evidence gaps, then make the least-privilege decision as the server owner.
Run the free audit