Documentation Index

Fetch the complete documentation index at: https://docs.aifabrix.ai/llms.txt

Use this file to discover all available pages before exploring further.

Platform developer access

  • Updated on Aug 23, 2026
  • Published on Jun 29, 2026
  • 3 minute(s) read
  • MR
  • EB
 Prev Next

Summary also on: Configure roles and permissions (platform vs business RBAC) and Configure authentication (platform CLI layer).

Understand which catalog roles unlock Builder CLI and online tools on the Miso controller and dataplane — separate from Connected System capability RBAC under business role names.

There is one Role catalog. Map personas below to concrete keys in AI Fabrix roles.

Prerequisites

  • Tenant ACTIVE after tenant activation wizard
  • Platform admin can assign Controller roles for your environment
  • Seeded Role catalog visible (AI Fabrix roles already present after install)

Where it lives

Access is granted on the Miso controller per environment (dev, tst, pro). Dataplane permissions are environment-scoped — the CLI token must carry scopes for the environment you target.

Business capability bindings in Connected System RBAC control integration capabilities — not who can run aifabrix upload. Roles referenced on systems must exist in the catalog or deploy/upload fails closed.

How to set

  1. Platform admin (aifabrix-platform-admin) assigns catalog roles in the Controller UI (or your enterprise IAM process) for each environment.
  2. Integration developer (aifabrix-developer) receives roles that allow: wizard, validate, upload/publish, datasource test, protection upload (as needed).
  3. Governance / AI Trust operators (aifabrix-ai-trust-operator and related) receive roles that allow: identity sync, verify-governance, protection validate/upload, AI Trust evaluation.
  4. Everyone (aifabrix-everyone) — map authenticated users who need LLM call/embed and platform search (consume only).
  5. Developer workstation — aifabrix login (device flow) or credentials method for CI; verify with aifabrix auth status.
  6. CI/CD — register integration app, store client id/secret in Builder secret store; pipeline uses application token (same pattern as protection upload).

Do not copy full permission tables into integration repos — assign roles in controller; developers run commands with their token.

Defaults and examples

Persona Catalog role (typical) Typical platform work
Platform admin aifabrix-platform-admin Environments, app registration, role assignment
Integration developer aifabrix-developer Wizard, validate, upload, test-integration, test-e2e
Governance / AI Trust aifabrix-ai-trust-operator (+ related) Identity sync, protection, verify-governance, AI Trust
Read-only auditor aifabrix-observer show --online, download, lifecycle report — no publish
Authenticated consumer aifabrix-everyone LLM call/embed + document/record search only

Exact scope names live in the Builder CLI permissions reference (linked from CLI reference) — use that document when configuring controller roles or debugging 403 errors.

Validate

aifabrix auth status
aifabrix wizard --help   # fails fast if token/scopes missing
aifabrix upload <systemKey> --probe

If upload fails with permission errors, fix platform roles — not business RBAC on the external system.

Common mistakes

Mistake Fix
Confusing business Admin role with platform admin Separate layers
Upload to wrong environment Match token scopes to target env
Pasting client secrets into integration JSON Use kv:// and secret store
Full permission matrix in public docs Use controller UI + permissions reference

Example platform token config shape (no secrets — paths vary by OS):

controllerUrl: https://controller.example.com
environment: dev
authenticated: true

Integration JSON still uses root key, displayName, systemKey, entityType, resourceType, primaryKey, and indexed externalId — platform roles gate upload, not field mapping completeness.

Limits

Exact permission scope names change between controller releases — use the Builder CLI permissions reference linked from CLI reference when debugging 403 errors, not copied tables in integration repos.

Business rbac.yaml permissions control capability execution for Role Assistants — they do not replace controller roles required for aifabrix upload, protection upload, or verify-governance. CI pipelines should use application credentials with the same environment scope as the target upload, not a developer device token checked into git.

Governance operators need distinct scopes from integration developers — assigning upload rights without verify-governance produces integrations that publish but fail certification silently until subject-scoped tests run.

Read-only auditors should use show --online and download — not shared integration developer tokens with publish scopes — to avoid accidental upload in shared shells.

Environment-scoped tokens cannot publish to another environment even when auth status reports authenticated — confirm environment in local config before upload --probe failures are escalated as platform outages.

Separate CI service principals per environment when tst and dev share a controller — cross-environment publish is a common source of mistaken verify-governance subjects.

Related articles