Command Guide

Granular control and deep system configuration.

Authorization Engine

Whitelist &
Authorization

Instead of granting total immunity, the Granular Permission System allows owners to define exactly what actions a trusted staff member is allowed to perform — not a single action more.

Multi-Tiered Authorization Model

Server OwnerAbsolute

Bypasses all detections. Exclusive panic restore & whitelist reset access.

Extra OwnersCo-Owners

Designated via !extraowner. Full detect bypass, can manage whitelist & config.

Whitelisted UsersRestricted

Immune only to specific whitelisted actions. Managed via interactive select-menus.

General StaffMonitored

Subject to full monitoring. Even "Admin" permissions won't protect them.

Available Permission Bypasses

role_createrole_deleterole_updaterole_addrole_removerole_mentionchannel_createchannel_deletechannel_updatemember_kickmember_banmember_unbanwebhook_createwebhook_updateintegration_createintegration_deleteemoji_createemoji_deletesticker_createsticker_deletethread_deleteguild_updatebot_add

■ Highlighted = High-risk. Apply with caution.

WHITELIST CONTROL

// Open interactive permission menu

›

!whitelistadd <user>

// Revoke specific or all bypasses

›

!whitelistremove <user>

// View active permissions

›

!whitelistview <user>

// Launch visual management dashboard

›

!whitelistpanel

// [Owner Only] Nuke entire whitelist

›

!whitelistresetOwner Only

Best Practice

Always apply the Least Privilege Principle. If a moderator's account is token-logged, limiting their whitelist scope drastically reduces the blast radius before the Sentinel Engine intervenes.

Co-Owner Engine

Extra Owner
System

Allows server owners to appoint highly trusted administrators with near-total control over security features, bridging the gap between staff and the primary owner.

High-Level Access

Extra Owners can toggle Anti-Nuke, configure punishments, and manage the whitelist—actions restricted from regular admins.

Security Hierarchy

Strictly enforced: Only the Primary Server Owner (User ID matches guild.ownerId) can manage the Extra Owner list.

Scalability & Limits

Supports up to 10 unique Extra Owner slots per server, allowing for a robust senior security team.

Zero-Latency Sync

Changes are instantly synchronized between MongoDB and the in-memory engine for real-time protection updates.

Technical Specifications

Database: Persisted via extraowner array in models/antinuke.js.
Cache Engine: Managed via extraOwners Set in antinukeMemory.js.
O(1) Lookups: Utilizes isExtraOwner() for millisecond permission checks.

EXTRA OWNER CONTROL

// Appoint a trusted security co-owner

›

!extraowneradd <user>or !eo add

// Revoke high-level co-owner status

›

!extraownerremove <user>

// Open interactive co-owner management panel

›

!extraownerpanel

// [Owner Only] Reset entire co-owner list

›

!extraownerresetOwner Only

Ownership Integrity

The primary server owner remains the ultimate authority. Extra Owners cannot remove the primary owner or each other — preventing hostile takeovers within the co-owner tier.

Isolation Engine

The Quarantine
System

A non-destructive alternative to outright banning. When a user triggers Anti-Nuke thresholds, the system strips their power and places them in temporary isolation.

Role Generation & Hardening

Automatically creates a secure Quarantine role with zero permissions (0n bitfield) across the entire server if it doesn't already exist.

Snapshotting the Threat

Takes an intelligent snapshot of roles (oldRoles) and dangerous permissions before stripping them, backed up directly to MongoDB.

Power Stripping & Fail-Safe

Instantly revokes all roles and assigns Quarantine. Defaults to a Ban if role assignment fails due to link role or API limits.

Evasion Prevention

Detects if a malicious user leaves and re-joins, immediately re-quarantining them before they can act.

Summary for Server Owners

No Data Loss: Preserves chat history & server profile versus Kick/Ban.
Easy Recovery: Restore previous roles instantly from the MongoDB snapshot.
Fail-Safe: Seamlessly falls over to a Ban if role hierarchy prevents quarantine.

QUARANTINE

// Open interactive quarantined registry

›

!quarantinelist

// Instantly restore user roles

›

!quarantinerelease <user>

// Mass release everyone in registry

›

!quarantineresetallCaution

// Preemptively quarantine suspicious account

›

!quarantineadd<user> [reason]

Security Infrastructure

Quarantine actions are strictly locked behind the isAuthorized guard. Only the Server Owner or registered Extra-Owners can manage the registry — rogue staff cannot bypass or revert their own isolation.