Deploying an MCP tool through the AgentRegistry UI, part 2: fine-grained RBAC

Two policy layers, one identity

Gateway policy and registry policy answer different questions, and both key off the same IdP groups:

The worked example: a self-service policy for the developers group, giving an app team the publish-and-deploy loop from part 1 without runtime administration, secrets, deletion, or policy authorship. Step by step:

1. Create the group and user in the IdP

In Keycloak: the realm's Groups hold admins and developers, the user bob is a member of developers, and a group-membership mapper stamps the membership into each token as the Groups claim. Nothing user-related happens in the registry; if your IdP is Entra or Okta, this step is wherever your groups already live.

2. Start the policy

As a superuser: Access Policies → New Access Policy. Name self-service, description free-text. The Access Policies page is absent from a non-admin's navigation entirely, so a team can never widen its own grants.

3. Principals: bind the IdP group

Add one principal: Kind Role, Name developers, Role developers.

4. Rules: grant the verbs

Each rule combines actions (scope:verb strings) with resources (a kind plus a name, exact or *, with optional tool/skill/prompt subresources for finer grain). Three rules make the self-service shape:

5. Create it and check the list

The saved policy also downloads as JSON, and that export is exactly what arctl apply takes, so policies can be authored in the UI and versioned in git:

{
  "description": "Self-service developers",
  "name": "self-service",
  "principals": [
    { "kind": "Role", "name": "developers", "role": "developers" }
  ],
  "rules": [
    { "actions": ["registry:read", "registry:publish", "registry:edit", "registry:deploy"],
      "resources": [{ "kind": "MCPServer", "name": "*" }] },
    { "actions": ["registry:read"],
      "resources": [{ "kind": "Runtime", "name": "*" }] },
    { "actions": ["registry:read", "registry:publish"],
      "resources": [{ "kind": "Agent", "name": "*" }] }
  ]
}

6. Verify as the developer

Log in as the developer user in a private window (the browser otherwise reuses the admin's Keycloak session). Before the policy exists, or while its principal name is wrong, an authenticated developer sees this:

With the policy in place the same login shows the catalogue and runtimes, and Create MCP Server and Deploy both work. Publish and edit are distinct verbs: creating a new entry checks publish, changing an existing one checks edit, so publish-only and edit-only roles are both expressible.

The claim doing all the work

To show the identity underneath, decode the two users' tokens side by side. Same issuer, same audience, one differing claim, and both policy layers hang off it:

mint() { curl -s -X POST http://keycloak.localtest.me/realms/agentregistry/protocol/openid-connect/token \
  -d "grant_type=password&client_id=ar-cli-password&username=$1&password=$2" | jq -r .access_token; }
claims() { local p; p=$(mint "$1" "$2" | cut -d. -f2 | tr '_-' '/+'); while [ $((${#p} % 4)) -ne 0 ]; do p="${p}="; done
  printf '%s' "$p" | base64 -d 2>/dev/null | jq '{preferred_username, Groups, aud, iss, exp}'; }

claims alice alice
claims bob bob

alice returns "Groups": ["admins"] and bob returns "Groups": ["developers"]. That one value decides bob's registry rights on this page and his gateway tool list in part 1.

Scoping teams tighter than this

Resource names in rules are exact or * in the current release, so a strict per-team catalogue means enumerating that team's resource names in its policy; pair it with the registry's approval workflow (teams submit, platform approves) for the guardrails half. For the gateway side of scaling, per-server grants by name prefix and policy generated from registry state, see the scaling section in part 1.

Where it can go wrong

That closes the pair: part 1 is what a team can do self-service; this page is how the platform decides which team can do it, from one policy object and one IdP claim.