LuckPerms Staff Groups and Anticheat Bypass Rules

Give each staff role only the anticheat access it needs

Use separate LuckPerms groups for reviewers, moderators, and administrators. Grant alert and diagnostic permissions to the reviewer group. Keep bypass and exemption permissions out of shared groups, because a bypass for one investigation should not follow a player through every role.

The node names below are placeholders. Replace each one with the exact permission your anticheat documents, and confirm it on your loaded build before you grant it.

Keep the role table in your staff handbook. When you add an anticheat, add its nodes to the table before any staff member receives them, so the live grants never drift from the documented roles.

Map roles to permission groups

Start with a table of roles. Write the grant and the explicit exclusion for each role, and review it whenever a plugin adds nodes.

Create a reviewer group with LuckPerms

The commands below use LuckPerms console syntax. Confirm command names on your LuckPerms version with its help output. The placeholder node and group names must match your own setup.

lp creategroup alerts-reviewer
lp group alerts-reviewer permission set example.anticheat.alerts true
lp group alerts-reviewer parent add staff
lp user ExampleStaff parent add alerts-reviewer

Set bypass rules that stay narrow

A bypass is a deliberate exception, not a convenience. Grant it to the smallest scope the anticheat supports: one check, one account, one reason. Record the reason, the approver, and the expiry in your staff log before the grant takes effect.

• Prefer a per-check permission over a global bypass.
• Grant bypass to a test account or a specific player, never to a whole staff group.
• Write the reason and expiry in the staff log before granting.
• Remove the grant when the reason ends, then record the removal.
• Do not give bypass to a player account that also holds alert access, unless a second person approved it.

Keep bypass grants shorter than their reason

A bypass that outlives its reason is a finding in the next audit. If a grant has no expiry, set a review date when you create it. Reviewers should be able to see, for each grant, who approved it, what it covers, and when it ends.

Handle Bedrock and bridged players separately

Bedrock players connecting through a bridge can trigger checks written for Java movement and mining. The usual fix is an anticheat setting that is aware of the bridge identity, not a blanket bypass. Check your anticheat's documentation for that setting and record which accounts it covers.

FairPlay separates exemption, setback suppression, and packet-modification suppression as different permission effects. The FairPlay per-check permissions article explains that split and the exact node pattern on its build.

Audit grants on a schedule

Review every group that holds an anticheat node once a month. Confirm that each grant still has a recorded reason. Remove grants for staff who changed roles or left the team. Keep the audit result with the staff log so you can show who had access at a given date. Save the output as plain text with the review date, so a later review can compare two months directly. Do not paste audit output into public channels, because it lists staff accounts and their access.

lp group alerts-reviewer info
lp group alerts-reviewer listmembers
lp user TestAccount permission check example.anticheat.alerts

Test each grant with a test account

After you change a group, log in with a test account that has only the intended role. Confirm it can see alerts and cannot run admin or bypass commands. Test the account after each permission plugin update, because load order and inheritance changes can alter the result.

Keep a short test script: join with the test account, stand in a combat area, and note which alerts appear. Repeat it after each grant change and save the result with the audit record. This takes minutes and catches grants that apply to the wrong check or the wrong group.

What we have not verified

The node names in this article are placeholders and are not a list of any anticheat's permissions. Command syntax was not tested against a specific LuckPerms version here. Confirm both on your own server.