Summary also on: Configure roles and permissions (platform vs business RBAC) and Configure authentication (platform CLI layer).
Understand which platform personas can use Builder CLI and online tools on the Miso controller and dataplane — separate from business roles on your external system.
Prerequisites
- Tenant ACTIVE after tenant activation wizard
- Platform admin can assign controller roles for your environment
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 roles in rbac.yaml control integration capabilities — not who can run aifabrix upload.
How to set
- Platform admin assigns controller/dataplane roles in the controller UI (or your enterprise IAM process) for each environment.
- Integration developer receives roles that allow: wizard, validate, upload/publish, datasource test, protection upload (as needed).
- Governance operator receives roles that allow: identity sync,
verify-governance, protection validate/upload. - Developer workstation —
aifabrix login(device flow) or credentials method for CI; verify withaifabrix auth status. - 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 | Typical platform work | Examples (high level) |
|---|---|---|
| Platform admin | Environments, app registration, role assignment | Register apps, assign developer roles |
| Integration developer | Wizard, validate, upload, test-integration, test-e2e | Publish integration JSON, run E2E |
| Governance operator | Identity sync, protection, verify-governance | ABAC certification, scenario packs |
| Read-only auditor | show --online, download, lifecycle report | No publish |
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.