# Vetox Access Control — capability reference > Vetox Access Control — 40 grantable dashboard sections in 11 groups, a 25-entry cap, the request-time decision order, and rival staff-access models. - Canonical: https://discordtools.blog/blog/vetox-access-control-reference - Published: 2026-09-02 - Author: The Index desk - Facts checked: 2026-08-31 - Sources: - Vetox documentation — Access Control (https://docs.vetox.io/en/server-management/dashboard-permissions) — checked 2026-08-31 - Vetox documentation — Permissions (https://docs.vetox.io/en/permissions) — checked 2026-08-31 - Publication: The Index, an independent site not affiliated with Discord Inc. --- ## What it is Access Control is a per-server allow-list that narrows which dashboard sections a Discord administrator can reach. Without it, every administrator sees and can change every page. With it, an entry pairs one or more roles and/or specific users with the set of sections they are allowed to open, and everyone else with Administrator sees only Overview. Enforcement is server-side on every API request, not only in the sidebar that hides a link. ## The problem it solves Discord's own permission model is coarse. To let a moderator tune Auto-Moderation, they need Administrator (or Manage Server) — which also lets them edit the server itself and reach every other Vetox page: leveling, giveaways, premium, tickets, backups. Access Control decouples "can configure the feature I own" from "can configure everything", which is the difference between handing a moderation lead one page and handing them the whole panel. ## How it works One configuration document per server, with two immediate-save switches and a list of entries: | Field | Meaning | | --------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `restrictPermissions` | Master switch. Off by default — any administrator has full access. On — only listed roles/users reach anything beyond Overview. | | `isOwner` ("Restrict Protection") | On restricts the Access Control page itself to the server owner, so nobody can grant themselves more access — unless an entry explicitly grants the Access Control section, which overrides it. | | `sectionAccess[]` | Up to 25 entries. Each is `{ roleIds[], discordIds[], sections[] }`. | Both switches save immediately — there is no separate save step. **The decision order**, run on every request to a server's dashboard endpoints, in sequence: an internal service-to-service call bypasses everything; an active [support session](/blog/vetox-support-sessions-reference) is granted full access within its own locked scope; a blacklisted server is refused outright; a Custom Bot owner gets a full-access fast-path; the guild must show the bot as present; the requester's live Discord permissions are read fresh from the Bot over Kafka on every request rather than trusted from a cached login; the server owner bypasses everything below; a non-administrator is refused regardless of any Access Control entry; with `restrictPermissions` off, any administrator gets full access; with `isOwner` on, only the owner (or an explicit grant) may open the Access Control page itself; the requester's roles and user ID are matched against every entry's `roleIds` and `discordIds`; and finally the union of matched entries' sections — always including Overview — is what the request is allowed to touch. **Eight utility routes are never section-restricted**, because they serve many pages at once: Overview, Roles, Channels, Emojis, Invites, Discord data, Language, and Members. **Fails open on its own error.** If the permission document cannot be read, the middleware widens access rather than locking every administrator out — a backend fault is treated as an availability problem, not a security boundary, and the blacklist and Administrator checks still apply underneath it. ## What is configurable | Setting | Range / values | Default | | ------------------------------------- | ---------------------------------------------------------- | ------- | | `restrictPermissions` | boolean | `false` | | `isOwner` ("Restrict Protection") | boolean | `false` | | `sectionAccess` entries | up to 25 per server | `[]` | | Each entry's `roleIds` / `discordIds` | array of role or user IDs; no stated upper bound per entry | `[]` | | Each entry's `sections` | array, at least one required | `[]` | An entry must name at least one role or one user — an entry with neither is rejected. `overview` is never listed as a grantable section because it is implicit on every match. ### The 40 grantable sections, in 11 groups | Group | Sections | | ------------------ | -------------------------------------------------------------------------------------- | | General (2) | Setup, Commands | | AI (3) | AI Usage, AI Control, AI Auto-Mod | | Moderation (4) | Auto-Mod, Moderation Tools, Protection, Anti-Raid | | Community (8) | Welcomer, Leveling, Giveaways, Suggestions, Starboard, Counting, Battle Pass, Streaks | | Customization (4) | Self-Roles, Auto-Roles, Colors, Temp Voice | | Communication (4) | Embed Messages (includes Sticky Messages), Auto-Responder, Auto-Interaction, Reminders | | Notifications (8) | Twitch, YouTube, Kick, Reddit, Bluesky, Steam, RSS, Podcasts | | Tickets (1) | Tickets | | Applications (1) | Applications | | Monitoring (3) | Server Insights, Logs, Backup | | Administration (2) | Access Control, Dashboard Watcher | Sub-pages that share a parent section are covered by the parent grant rather than needing their own entry: the Welcomer modes, the Auto-Roles tabs, and the Embed/Sticky Messages editors. ## Tier availability | Capability | Starter | Basic | Max | Black | | --------------------------------- | ------- | ----- | --- | ----- | | Configure Access Control | No | No | Yes | Yes | | Section access entries | — | — | 25 | 25 | | Reading the current configuration | Yes | Yes | Yes | Yes | The gate applies to all four mutating actions — turning either switch on, and adding, updating or deleting an entry — at Max ($7.99/mo or $69.99/yr). Reading the configuration stays open on every tier, because the request-permission middleware itself needs to consult it before deciding whether any given request is allowed through — gating the read would make every request depend on a premium check it cannot itself pass. **Downgrading below Max** turns both switches off automatically but keeps every stored entry. Re-upgrading restores the exact same delegation with no reconfiguration. ## Commands None. Access Control has no slash command — the whole feature is dashboard-only. ## Dashboard surface `/server/[serverId]/dashboard-permissions` — a single page, no tabs. The two immediate-save switches sit at the top, with a Section Access table below and an Add/Edit dialog that groups the 40 sections by the same 11 categories as the table above with a role/user picker. The sidebar label is "Access Control"; the page's own title is "Dashboard Permissions"; the API route and stored section key are both `dashboard-permissions`. All three names refer to the same system. ## Permissions required No Discord permission is needed by the bot for this feature — it is entirely a dashboard-side allow-list. To reach the page at all, a requester must be the server owner or hold Administrator in Discord, and — when Restrict Protection is on — must be the owner unless explicitly granted the Access Control section itself. ## What it connects to - **Governs every other server-feature page** in the product — a section key here is the grant that lets a delegated administrator open that page at all. See the [Permissions reference](/blog/vetox-permissions-reference) for how this sits alongside the other two permission layers. - **Bypassed, within its own narrow scope, by [Support Sessions](/blog/vetox-support-sessions-reference)** — an active support session is granted full access to its one locked server for its duration, independent of any Access Control entry. - **Depends on the Bot** for the live Discord permission lookup (Administrator status, ownership, roles) on every request, rather than trusting a cached login snapshot. - **Paired with [Dashboard Watcher](/blog/vetox-dashboard-watcher-reference)**, which records what a delegated administrator actually changed once granted a section. ## Who it is for Servers on Max or above with more than one person configuring the bot: a staff team where moderators tune moderation, community managers run giveaways and leveling, and only the owner touches premium, backups or Access Control itself. It earns its place the moment "I need to give someone Administrator so they can change one setting" becomes a real sentence in a server's staff chat. ## Practical use cases 1. **Moderator delegation.** An entry for the Moderator role granting Auto-Mod, Moderation Tools, Logs and Anti-Raid — nothing else. 2. **A community team.** An entry for Community Manager granting Leveling, Giveaways, Starboard, Suggestions and Welcomer. 3. **Closing the escalation loop.** Turn on Restrict Protection so only the owner can edit who has access, preventing a delegated administrator from granting themselves more. 4. **Onboarding a contractor.** An entry keyed to a single Discord ID rather than a role, granting one section, deleted the moment the work is done. ## How it compares Section-level delegation for a Discord bot's own dashboard is uncommon — most general-purpose bots stop at "Administrator or nothing." | Product | Delegation model | Granularity | Where | | -------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- | ------------------------------------------------------------------------------- | | **Vetox** | Named-section allow-list, role or user scoped | 40 sections, 11 groups, 25 entries per server | Dashboard, Max tier | | **Zeppelin** | 5-level permission cascade plus per-user, per-channel, per-permission-level config overrides, with full attributed revision history | The finest-grained model found in this category | A YAML config editor behind a whitelisted, largely inaccessible hosted instance | | **ProBot** | Administrator-only by default | A Discord role must be manually created and assigned to reach the dashboard at all | Dashboard | | **Dyno / Carl-bot / MEE6** | Web dashboard, Administrator baseline | No section-level delegation documented | Dashboard | Zeppelin's cascade remains an unusually granular staff-permission model, including an audit-logged history of every configuration edit — but it is reserved for a bot whose hosted instance grants access case by case and whose configuration surface is a YAML file rather than a form. Among form-driven, generally-available dashboards, a named-section delegation model at Vetox's granularity — 40 distinct sections rather than an all-or-nothing role — is not documented by ProBot, Dyno, Carl-bot or MEE6, each of which stops at Administrator as the finest available grain.