ACE (Access Control Entries) is FiveM's built-in permission system. It decides who can run which commands and which features they can use — from kicking players to opening an admin menu. Understanding ACE is essential for running a secure FiveM server. This guide explains every part with copy-paste examples.

The two building blocks: add_ace and add_principal

  • add_ace grants an object (a group or a player) access to a permission, with allow or deny.
  • add_principal links one principal to another — typically assigning a player into a group so they inherit its permissions.

add_ace — granting permissions

The syntax is: add_ace <object> <permission> <allow|deny>. For example, let the admin group run every command, and let the mod group only kick:

add_ace group.admin command allow        # all commands
add_ace group.mod command.kick allow     # only the /kick command
add_ace group.mod command.clear allow

add_principal — assigning players to groups

Put a player into a group so they inherit all of that group's aces. Identify the player with one of their identifiers:

add_principal identifier.license:abcd1234ef567890 group.admin
add_principal identifier.discord:123456789012345678 group.mod
add_principal identifier.fivem:1234567 group.support

Identifier types (which to use)

  • identifier.license / license2 — Rockstar license, the most stable and recommended for admins.
  • identifier.discord — the Discord user ID; great if your community is Discord-based.
  • identifier.fivem — the cfx.re forum account ID.
  • identifier.steam — Steam hex ID (only if the player has Steam running).
  • identifier.ip — discouraged: IPs change and can be spoofed.

Command permissions: command vs command.<name>

command grants every command; command.<name> grants a single one. This lets you build tiered staff — for example a moderator who can kick and freeze but cannot ban or restart resources.

add_ace group.mod command.kick allow
add_ace group.mod command.freeze allow
# mod does NOT get command.ban or command.restart

Resource ACE objects

Resources define their own ACE objects to gate features. Frameworks (ESX, QBCore, Qbox), admin menus and many scripts check ACE before allowing an action. You grant them exactly like commands:

add_ace group.admin menu.access allow      # custom admin-menu permission
add_ace group.admin car allow              # a spawn-car resource permission

Group inheritance

Make a group inherit another group's permissions with add_principal. Here admins automatically get everything mods have, so you only define mod permissions once:

add_principal group.admin group.mod   # admin inherits all mod aces

allow vs deny

deny explicitly blocks a permission and overrides a broad allow. Use it to carve an exception out of a wide grant — for example a senior-mod group that has almost everything except server restarts:

add_ace group.seniormod command allow
add_ace group.seniormod command.restart deny   # everything EXCEPT restart

Full example: admin / mod / support

# --- Groups & permissions ---
add_ace group.admin command allow            # full access
add_ace group.mod command.kick allow
add_ace group.mod command.freeze allow
add_ace group.mod menu.access allow
add_ace group.support command.report allow

# --- Inheritance ---
add_principal group.admin group.mod          # admin >= mod
add_principal group.mod group.support        # mod >= support

# --- Assign people (use license or discord) ---
add_principal identifier.license:abcd1234ef567890 group.admin
add_principal identifier.discord:123456789012345678 group.mod

Security tips

  • Prefer identifier.license or identifier.discord over fivem/ip for admin accounts.
  • Never grant command allow to a public/everyone principal.
  • Keep your admins in a separate permissions.cfg and exec it from server.cfg for tidiness.
  • After editing, run refresh then restart the relevant resource, or restart the server.
  • For larger teams, manage admins through txAdmin, which writes ACE for you.