Access control

Users share templates, running labs and VPN interfaces with each other. This page is where you see every one of those grants, revoke or transfer them, decide the minimum role each action needs across the whole platform, and read the audit trail.

By the end of this page you will also know how Gate Rules work: the rules that make some actions cost or require currency, and that pay out rewards automatically.

Admin Panel → Platform → Access Control (/admin/acl)

Grants

Every active share on the platform.

Search by a user's email, by a team (@ followed by the team name), or by a resource ID. Narrow it with the type filter: All resources, Templates, Running labs or Interfaces.

Columns: Resource, Owner, Subject (who received access), Role, Granted by, When, Actions.

Action	What it does
Revoke	Removes the grant. The dialog names exactly who loses what before you confirm.
Transfer…	Templates only. Makes someone else the owner. Choose whether the previous owner keeps Manager access (recommended) or Nothing.

Both are audited.

Policy

The Policy tab, headed "Who can do what — platform policy", sets the minimum role a shared user needs for each action.

Applies to	Actions
Templates	See a template; deploy copies; fork; edit files, config and builds; manage sharing, visibility and deletion
Running labs	View the lab dashboard; operate it (renew, startup script, deploy log); stop; redeploy; pause and resume; open VS Code or a terminal; open the app; edit preferences and sharing

The roles, from least to most access:

Resource	Roles
Templates	Viewer, Deployer, Editor, Manager
Running labs	Viewer, Operator, Manager

Pick a new minimum role from the dropdown. ↺ reset returns an action to its default.

Policy changes apply at once, to everyone

There is no confirmation. The new minimum applies immediately across the whole platform. Owners and admins always pass. A share can still carry specific extras (for example, permission to open VS Code) that let someone below the minimum role do that one thing. Policy changes are audited.

What users see when they share is covered in the user guide under Labs.

Audit log

The platform's record of who did what.

Filter by the actor's email, a resource ID, and the event type (All, grants, role changes, revocations, ownership transfers or policy changes), then click Apply.

Columns: When, Actor, Event, Resource, Subject, Change, Via. Load more fetches older rows.

With All selected the log also shows sign-ins, impersonation, platform setting changes, background jobs run by hand, storage and organization actions, plan pre-authorisations, and more.

Not everything is in the audit log

Some actions are recorded only in server logs, which the panel does not show: for example plan changes, moderator switches, lab stop and restart from the Instances page, and Gate Rules changes. Each page of this guide says which. If you need those records, ask whoever runs the server.

Gate Rules

Admin Panel → Platform → Gate Rules (/admin/privilege), headed "Privilege System".

Gate Rules do two jobs:

• Privileges make an action require a minimum balance of a currency. A user below it is blocked and sees the rule's description.
• Events and Actions do something automatically after an action succeeds: pay out currency, or send a notification.

Default rules ship with the platform. You can override them, add your own, or switch them off.

Privileges

A banner at the top shows the experience currency, read-only. The table lists each rule with the action it guards, Currency, Required, Source (default or override), Status and Actions. Search, tick rows for bulk Enable / Disable, or click New Rule.

A rule has: the action it guards, Currency, Operator, Required Score, Description (the message a blocked user sees) and Enabled.

The form identifies the action by the Class and Method names the platform uses internally. Copy them from an existing rule, or ask your engineering team for the names before adding a rule for a new action.

• To change a default rule, use Override this default. Reset drops your override and returns to the default.
• Delete asks for confirmation. Deleting an override can let the default rule take effect again.

Events

An event names an action and the result that counts as success. Fields: the action, Expected Result, Key, Active, Description.

Deleting an event asks for confirmation, because any actions bound to it are left orphaned.

Actions

What happens when an event fires. Fields: Bind to Event, Type (transaction or notification), Order and Active.

Type	Settings
Transaction	Currency, From and To (the system, the person who acted, or the beneficiary), Value, Skip if from == to, Remarks
Notification	Notification Type, Template ID, Notify, Href

A transaction paid from "system" creates currency

Every matching call pays out. An action bound to something users can repeat cheaply can flood the economy. Test with the Rule Tester, and watch Transactions after you enable one.

Rule Tester

Choose an action and a user's email (blank tests as yourself), then Run Test. The result is ALLOWED or BLOCKED, with the user's balance. It is read-only and changes nothing.

Gate Rules changes are recorded in server logs only, not in the audit log.

Next

• Economy — Transactions and achievements
• Users
• Certificates and VPN — assigning VPN interfaces to teams