---
summary: ScaiSkills module permissions and which roles get them by default.
title: Permissions
path: reference/permissions
status: published
---

# 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

| Key | What it grants |
|---|---|
| `scaiskills:view` | List skills, read skill detail and versions, list bindings, call `/resolve` and all three `/mcp/skills/*` endpoints. |
| `scaiskills:publish` | Register new skills (`POST /skills`), publish versions, yank versions. |
| `scaiskills:bind` | Create and delete bindings. Does not grant permission approval. |
| `scaiskills:grant` | Approve declared permissions on a binding via `POST /bindings/{id}/permissions/grant`. The supply-chain gate keeper. |
| `scaiskills:manage` | Hard-delete a skill (cascading versions, bindings, grants). The destructive escape hatch. |

## Default role mapping

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

| 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` | `scaiskills:view`. |

`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:

```json
{
  "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:

```bash
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).