Blog
FiveM Admin Permission Systems: ACE, Role Hierarchies and Avoiding Over-Privileged Staff
FiveM Admin Permission Systems: ACE, Role Hierarchies and Avoiding Over-Privileged Staff
Most FiveM servers start with admin permissions as an afterthought. The owner gives a trusted friend full superadmin access, that friend gives a few others the same, and within a month there are eight people with unrestricted server control, no audit trail, and no way to know who did what when something goes wrong. Building a proper ACE permission hierarchy from the start is the single most impactful security improvement most servers can make.
What ACE Permissions Are and How They Work
FiveM’s Access Control Expressions (ACE) system is the native permission layer built into the server. It operates at two levels:
- Principal identifiers: the Steam hex, Discord ID, FiveM license, or IP of a specific player, or a named group that contains multiple identifiers
- Aces (permissions): named strings like
command.kick,command.ban,resource.start, or custom strings your own scripts check viaIsPlayerAceAllowed(source, 'my.permission')
The server.cfg lines that grant permissions follow a simple pattern: add_ace group.moderator command.kick allow — the moderator group gets the kick command. add_principal identifier:steam:xxxx group.moderator — a specific player is placed in the moderator group. Inheritance is one-directional: a group can be a member of another group, inheriting its permissions, but not the reverse.
Designing a Role Hierarchy That Matches Your Server
A functional FiveM admin hierarchy has at least four tiers:
Tier 1: Support Staff
Handles player assistance — stuck entities, broken quest states, basic queries. Permissions needed: teleport to player, check player inventory (read-only), send server message, close a basic ticket. Does not need ban, kick, or resource management access. Most servers over-privilege support staff with full moderation tools because it’s easier to give everything and trust them. This creates risk when support staff go rogue or their account is compromised.
Tier 2: Moderator
Active moderation — kicks, short temporary bans, freeze player, spectate, noclip for incident investigation, access to transaction logs for economy dispute resolution. Does not need resource start/stop, config access, or ban duration over 72 hours.
Tier 3: Senior Moderator / Admin
All of the above plus: longer ban durations, database record corrections (item restoration after proven exploit, not as gifts), txAdmin resource control (start/stop individual resources), log access for full server-side records. This tier should have fewer members than the tiers below it, not more.
Tier 4: Owner/Head Admin
Unrestricted. Config changes, server.cfg access, financial controls if the server runs Tebex payments. This tier should be one to three people maximum and should use named identifiers, not groups — so every assignment is explicit and auditable. For managing your Tebex permissions for store access, the configuration and payment management guides on buy-tebex.io cover admin access control at the store level.
Recommended FiveM scripts for your server
txAdmin Role Design
txAdmin has its own role system that operates alongside ACE permissions. The txAdmin roles control access to the txAdmin panel itself: who can restart the server, who can access the console, who can modify whitelist entries. These should mirror your ACE tier hierarchy but are managed separately. Common misconfiguration: giving all txAdmin panel access to moderators who only need in-game tools. Moderators should be in txAdmin as basic users who can view the player list and file reports, not as managers who can restart the server.
The Audit Trail Problem
Even a well-designed permission hierarchy is only as useful as the logging behind it. An admin who takes a prohibited action (spawning items into their own inventory, softening a ban on a friend) cannot be held accountable if no record exists. Build logging into every privileged action:
- Every ban, kick, and warn: Discord webhook with actor, target, reason, and duration
- Every inventory modification by staff: to a separate admin-action log, not the main transaction log
- Every server restart: timestamp, actor, and declared reason
- Every config change: a config change log or Git commit if you version your configs
The broader logging infrastructure — transaction logs, exploit logs, and the Discord webhook setup — is covered on febex.io‘s own existing guides. This article adds the permission architecture layer that determines who can generate those log entries in the first place.
Quarterly Access Reviews
Staff turnover is constant on FiveM servers. People who leave the staff team on good terms often keep their permissions indefinitely because removing them is not urgent. Staff who leave on bad terms may have permissions pulled immediately but their team Discord role not updated. Run a quarterly access review:
- Export the current ACE principal assignments from server.cfg
- Cross-reference against the active staff list
- Remove identifiers for anyone no longer in an active role
- Verify that each remaining person’s permission level matches their current role
A former Senior Moderator who is now a Support Staff should be demoted in ACE, not just in role chat. The two are separate and both must be updated. Servers that follow this discipline also run better server documentation practices — the runbook approach covered on tebax.io that prevents permission assignments from living only in the head of whoever set them up.
Upgrade your server — shop our FiveM scripts
Over-Privileged Admins: The Most Common Breach Vector
The most damaging incidents on FiveM servers are not from external cheaters — they are from over-privileged admins abusing access, or from compromised admin accounts being used because the account holder had more access than their role required. The principle of least privilege — give each staff tier only what is needed to perform their function and nothing more — reduces the blast radius of both insider abuse and account compromise.