---
summary: ScaiLink module permissions, default role mapping, and how tenant admins
  enable the cloud registry per group.
title: Permissions
path: reference/permissions
status: published
---

ScaiLink declares seven module-permission keys. Four cover the desktop bridge; three cover the cloud MCP registry and are default-deny for non-admin roles so tenant admins can scope the feature explicitly.

## Permission keys

| Key | What it grants |
|---|---|
| `scailink:view` | See ScaiLink dashboard, list sessions and capabilities, view the cloud registry. |
| `scailink:invoke` | Invoke tools, read resources, and get prompts on connected desktop clients. |
| `scailink:manage` | Manage session policies, list every active session in the tenant. |
| `scailink:audit` | Read the audit log (tenant-wide and per-user). |
| `scailink:remote.use` | Discover and invoke tools from registered cloud MCP servers. Without it, the caller sees nothing in the cloud registry. |
| `scailink:remote.manage_own` | Register, rotate, and delete personal cloud MCP servers. |
| `scailink:remote.manage_tenant` | Register, edit, and delete tenant-shared cloud MCP servers. |

## Default role mapping

The built-in admin roles auto-grant every ScaiLink permission via ScaiGrid's module-permission 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` | None by default. |

The cloud registry is deliberately default-deny for `tenant_user` and `tenant_viewer` — the feature stores third-party credentials and bills outbound traffic, so opt-in via custom roles is the right posture.

## Enabling cloud MCP for a group

Tenant admins enable the feature for a subset of users by creating a custom role and assigning it to a group.

```bash
curl -X POST "$SCAIGRID_HOST/v1/iam/custom-roles" \
  -H "Authorization: Bearer $SCAIGRID_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Cloud MCP user",
    "module_permissions": [
      "scailink:view",
      "scailink:remote.use",
      "scailink:remote.manage_own"
    ]
  }'
```

Map a group to that role through the existing group-roles UI. Group members can now register personal servers and invoke registered tools.

To restrict tenant-shared registration to a single sysadmin, grant `scailink:remote.manage_tenant` directly via the user-module-permissions surface — leave the custom role at `use + manage_own` for everyone else. To revoke cloud MCP for a group, drop the keys from their effective role.

## Audit

Every permission-gated call is logged with `actor_user_id`, `action`, `target_name`, `status`, and `duration_ms`. ScaiGrid's standard audit log query supports filtering by `module=scailink`:

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

The module's own audit endpoints (`GET /v1/modules/scailink/audit`, `GET /v1/modules/scailink/users/{id}/audit`) expose the same events filtered to ScaiLink-specific actions plus detail-level controls inherited from the desktop client's `session_init` settings.