Administrator roles & permissions

Administering a DioscHub deployment — creating assistants, registering MCP servers, running an erasure — is itself access-controlled. This page describes who can reach the admin surface and how their authority is scoped, so you can confirm that administrative access follows least privilege.

There are two ways to authenticate as an administrator: portal login (an administrator account with a password) for people, and admin API keys for programs. Both resolve to a set of permissions, and both are governed by the model below.

Access is deny-by-default

An administrator’s authority comes from the roles assigned to their account. Permissions are not granted broadly and then trimmed — they start empty and are added only by a role. An account with no recognized role has no permissions; an unrecognized role name contributes nothing. There is no grant-everyone default.

DioscHub ships a built-in role ladder:

Owner — full administrative authority for the deployment’s tier.
Admin — broad configuration authority, below owner.
Operator — day-to-day operation without the most sensitive settings.
Viewer — read-only visibility.
DPO — a data-protection role that adds the erasure and subject-access permissions, granted alongside another role.

Permissions themselves are granular — separate rights to read, write, and delete each kind of resource (assistants, MCP servers, knowledge, settings, approvals, data-privacy operations, API keys, and so on). A role is a named bundle of these rights, and an account’s effective permissions are the union of the rights its roles carry.

Every role is capped by the license tier

No role can exceed what the license tier permits. An account’s effective permissions are always the intersection of its roles’ rights with the tier’s permission set — so “owner” means everything this tier allows, not everything DioscHub can do. Raising the tier widens what the same roles can reach; lowering it narrows them.

On Enterprise, you can define custom administrator roles — your own named permission bundles, beyond the built-in ladder — for finer-grained separation of duties. Custom roles are themselves tier-capped, and dropping below Enterprise falls their holders back to a read-only role rather than stranding undefined access.

Programmatic access uses scoped API keys

For non-interactive callers — a backend calling the bind endpoint, an automation script — DioscHub issues admin API keys. A key is deliberately narrow:

Scoped. Each key carries a chosen subset of permissions and can do nothing outside them — a key minted for auth:bind cannot read assistants or change settings.
Hashed at rest. Only a hash of the key is stored; the full value is shown once, at creation, and never again.
IP-restricted. A key can be pinned to an allowlist of addresses or ranges, rejected from anywhere else.
Revocable and expiring. A key can be revoked immediately or given an expiry; a revoked or expired key is refused.
Usage-tracked. Each key records when and from where it was last used, and a per-request log, so you can see how it is being exercised.
Tier-capped. A key’s scopes are intersected with the tier both when it is created and on every request, so a key can never out-reach the tier.

The bind endpoint is the clearest example: it requires a key holding the auth:bind scope — a dedicated secret credential kept on your backend, never the public embed key, so identity assertion stays server-to-server.

Break-glass access

A deployment can be configured with a single break-glass administrator credential that grants full administrative access for bootstrap and automated first-run setup. It sits outside the role-and-tier model by design — that is what makes it a recovery path — so treat it as a top-level secret: set it only when you need it, protect it like the required master keys, and use scoped API keys for everything routine. DioscHub refuses to start in production if this credential is left at a known default value.

Next: return to the Secure & Comply overview.