Permissions

ScaiSkills defines its own module-permission keys, mapped onto ScaiGrid's RBAC system. Every endpoint enforces one of them via CurrentUser.has_module_permission.

Permission keys#

Default role mapping#

Built-in roles auto-grant these via ScaiGrid's catch-all in CurrentUser.has_module_permission:

tenant_user gets nothing automatically because publishing a skill, binding it, or granting a permission changes what the LLM sees and what runtime gates fire — all of which need explicit opt-in.

Separating bind and grant#

Keep these on different roles. The bind role is held by engineers configuring an agent. The grant role is held by whoever owns the security review for a permission namespace. The split is what makes pending-grants useful: anyone who can bind cannot also self-approve the permissions the skill declared.

A typical custom role split:

1
2
3
4
5
6
7
8

{
  "name": "Skill operators",
  "module_permissions": [
    "scaiskills:view",
    "scaiskills:publish",
    "scaiskills:bind"
  ]
}

A separate, smaller role with scaiskills:grant (and usually scaiskills:manage) goes to whoever owns supply-chain approval.

Audit#

Every permission-gated call is logged via ScaiGrid's standard audit pipeline with actor_user_id, action, and resource_id. Filter by module:

1
2

curl "$SCAIGRID_HOST/v1/audit/events?module=scaiskills&since=2026-05-01" \
  -H "Authorization: Bearer $SCAIGRID_API_KEY"

Permission grants on bindings are auditable in two places — the audit log (who called the grant endpoint) and the mod_scaiskills_permission_grants table (which carries granted_by_scaikey_sub directly on the row).