Skip to content

Groups & roles

Groups are the primary unit of access control in Arbitex. A group collects users and carries the settings that apply to them: which AI models they can reach, which policy pack governs them, and per-group DLP detector overrides. A user’s effective permissions are the union of every group they belong to.

The two org roles — Member and Admin — control access to the console itself; groups control what a user can do through Arbitex.

The Users & Groups surface showing a list of groups with member counts, and a detail pane for editing model access and policy assignment.
Users & Access → Users & GroupsCitadel synthetic data on a non-production Arbitex demo instance. Never client data.
  1. Open Users & Access → Users & Groups and switch to its Groups section. Existing groups are listed with their member counts.

  2. Choose New group, give it a name, and save. The new group opens for configuration.

  3. In the group detail pane, add members from your roster.

  4. Assign model access — the set of providers and models this group may route to. Users outside any allowing group cannot reach a model.

  5. Assign a policy pack to govern the group’s traffic, and set any per-group DLP detector overrides.

Groups are managed under the admin groups API (control plane), which uses a POST-per-action (RPC-style) convention. All calls require the admin role.

Create a group:

Terminal window
curl -X POST "https://admin.arbitex.ai/api/v1/admin/groups" \
-H "Authorization: Bearer $ADMIN_TOKEN" \
-H "Content-Type: application/json" \
-d '{"name": "Engineering"}'

List groups, update a group, and manage membership use sibling routes under the same prefix, for example:

Terminal window
# list
curl -X POST "https://admin.arbitex.ai/api/v1/admin/groups/list" \
-H "Authorization: Bearer $ADMIN_TOKEN"
# add / read members
curl -X POST "https://admin.arbitex.ai/api/v1/admin/groups/$GROUP_ID/members/get" \
-H "Authorization: Bearer $ADMIN_TOKEN"

Per-group model access is managed under /api/v1/admin/model-access. See the Groups and RBAC reference for the full schema and every endpoint.

Groups and RBAC are available on every plan. The number of groups and the availability of per-group DLP overrides may be gated on higher tiers; gated controls render visible-but-disabled with an upgrade prompt.

Group definitions live in the control-plane database and are enforced by the data plane at request time. On a Hybrid Outpost, group-to-policy resolution happens locally, so enforcement continues even if the control plane is temporarily unreachable.