Admin access

Admin Access (/admin/access) controls which parts of the console an admin can see. Only an Owner can open this page.

A bundle is a named set of console areas — Accounts, AI Providers, Certificates, and so on. Grant a bundle to an admin and they see exactly those areas and nothing else. An admin’s effective access is the union of every bundle they hold.

Two separate gates

Getting into the console at all, and seeing something once you’re in, are two different grants:

Gate	What it controls	Granted from
Console access	Whether the account can sign in to /admin at all	The Identity admin role, from the account’s own page under Accounts
Area access	Which areas an admin who is already in sees	A bundle, assigned here

A bundle grants no console access on its own — adding someone to a bundle before they hold the admin role puts them on the holder list with No under Console access, and nothing changes for them until the baseline role is granted too. The reverse also happens: an admin with the admin role but no bundle can sign in and lands on No areas assigned — ask an Owner to assign you a role, because /admin no longer has content of its own — it redirects to the first area you can view.

The three starter bundles

Every server ships with three bundles already created:

Bundle	Grants	Editable
Owner	Every area, including Admin Access itself	No — built in, cannot be renamed, re-scoped or deleted
Auditor	Audit Log, Token Usage, AI Feedback	Yes — an ordinary bundle you can rename, re-scope or delete
User Administrator	Accounts, Groups, Sync	Yes — an ordinary bundle you can rename, re-scope or delete

Only Owner is protected. Auditor and User Administrator are starting points, not fixed roles — treat them as templates and reshape or remove them if they don’t match how your team is organised.

Upgrading from before this feature

The migration that introduced bundles made every account already holding the admin role a member of Owner, so nobody lost access on deploy. If your server has run this migration, check who holds Owner and trim it down to the admins who actually need every area.

Areas a bundle can grant

Checkboxes in the editor are grouped by the same sections the sidebar uses:

Section	Areas
Access	Accounts, Groups, Sync
Capabilities	AI Providers, Knowledge Bases, Mesh, Plugins, Guardrails
Provisioning	Client Policies, Managed Personas
Activity	Token Usage, Audit Log, AI Feedback
System	Certificates, Settings, License

A handful of areas cover more than their own page: Accounts also gates a user’s own detail and synced-items pages, Sync also gates Devices and the cross-user item inventory, Mesh also gates Connectors and Operators, and Audit Log also gates the Anomalies and Guardrail-decisions tabs on Audit. Granting the parent area grants the whole group.

Admin Access — this page — is not on the list. It is reachable only by holding Owner, so a non-Owner admin can never grant themselves (or anyone else) the ability to change access.

High-trust areas

Three areas carry a warning in the editor because what they grant reshapes the platform for everyone, not just what the holder can see:

Area	Consequence
Certificates	Adds and revokes the signing certificates clients trust for plugin packages
Settings	Can restart the server and wipe user data from the Data tab
License	Replaces the license, changing every seat and feature limit at once

Grant these only to admins you would trust with the server itself. When you add a holder to a bundle carrying any of them, the add-holder dialog repeats the consequence so it’s the last thing you see before confirming.

Creating a bundle

1. Press Create bundle.

2. Give it a Name and, optionally, a one-line Description of who it’s for.

3. Check the areas it should grant. High-trust areas are called out in place, with their consequence written next to the checkbox.

4. Press Create bundle to save.

Assigning holders

Each row’s Members column links to that bundle’s holder list.

1. Open a bundle’s member list from the Members column.

2. Press Add holders. The picker lists admins who already hold the admin role and don’t already hold this bundle — if it’s empty, grant admin on the account first from Accounts, then come back.

3. Check who should hold it and confirm.

Remove takes a holder off the bundle immediately; it does not touch their console access or any other bundle they hold. Removing your own last grant is allowed — it just stops being anonymous, since your own row is marked You.

You can't remove the last Owner

If a holder is the only remaining member of a bundle that grants every area, and no Admin:Emails address matches an existing account either, removal is refused: “This is the last account that can administer admin access… Add another holder, or an Admin:Emails address, before removing this one.” Add a second Owner first.

Admins whose address is listed in Admin:Emails show a Config chip on the holder list — their configuration entry already grants them every area, so this bundle’s membership doesn’t change what they can see.

Editing and deleting

Owner’s row shows View instead of Edit — its name, scope and membership-editing-via-the-dialog are all locked, because it is what makes the escalation guard above possible. Change who holds Owner from its members page instead.

Every other bundle can be renamed, re-scoped or deleted. Deleting one asks first: if it has holders and grants areas, the confirmation names exactly which areas those admins lose. They keep anything another bundle still grants them, and the change takes effect on their next interaction with the console.

Keep an escape hatch

If a deployment ends up with no Admin:Emails address matching an existing account, and Owner has no members, the server logs a warning at startup: nobody can be granted console access without direct database access. Keep at least one of the two in place.

Audit trail

Every mutation here writes its own event to the audit log, rather than one generic “Updated” an admin would have to open to understand:

Event	Written when
Admin.Bundle.Created	A bundle is created
Admin.Bundle.Renamed	A bundle’s name or description changes
Admin.Bundle.AreasChanged	A bundle’s granted areas change
Admin.Bundle.Deleted	A bundle is deleted
Admin.Bundle.MemberAdded	A holder is added
Admin.Bundle.MemberRemoved	A holder is removed