Permissions

ScaiCore's wrapper defines six module-permission keys. Every endpoint enforces one of them. Permissions live in ScaiGrid (not ScaiKey) and are auto-granted to built-in roles via the standard catch-all in CurrentUser.has_module_permission.

Permission keys#

Key	What it grants
`scaicore:view`	Read Cores, logs, runtime state, checkpoints; list plugins, triggers, events history.
`scaicore:manage`	Create, configure, start, stop, restart, pause, resume, delete Cores; install/uninstall plugins; register triggers; publish / unpublish.
`scaicore:debug`	Debug tools — breakpoints, stepping, inspection (currently stubs; permission is wired ahead of the feature).
`scaicore:checkpoint_resolve`	View and resolve pending checkpoints; cancel and reassign.
`scaicore:delegate`	Delegate and revoke user identity for Cores; update scopes/expiry.
`scaicore:admin`	Full administrative access to all ScaiCore features.

Default role mapping#

Role	Auto-grants
`super_admin`	All of the above.
`partner_admin`	All of the above for tenants under the partner.
`tenant_admin`	All of the above for the tenant.
`tenant_user`	None by default.
`tenant_viewer`	`scaicore:view` only.

tenant_user gets nothing automatically because Cores can call models (accounting impact), publish into the catalogue (visibility impact), and delegate identity (security impact) — explicit opt-in is safer.

Granting selectively#

A common pattern is a Core-operators role:

bash
curl -X POST "$SCAIGRID_HOST/v1/iam/custom-roles" \
  -H "Authorization: Bearer $SCAIGRID_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Core operators",
    "module_permissions": ["scaicore:view", "scaicore:manage", "scaicore:checkpoint_resolve"]
  }'

Reviewers who only resolve checkpoints get scaicore:view + scaicore:checkpoint_resolve. Identity delegation should be held by fewer people; gate it behind a separate scaicore:delegate role.