Skip to main content
GitHub org owners are automatically tenant admins in Murmur. That covers most cases, but sometimes you need to grant admin scope to someone who isn’t (and shouldn’t be) a GitHub org owner: a backend engineer who manages your Workspaces, a service account that automates billing, a bot that needs to manage tenant secrets. This guide walks through doing that safely. The full permission model (every kind, every verb, wildcard rules, evaluation order) lives in Authorization. This page is the practical “grant or revoke admin” recipe. Before you start, you need admin yourself, or these three specific permissions: tenant-binding.create, tenant-binding.edit, and role.read. In a brand-new tenant, the first GitHub org owner runs the commands below and then delegates outward from there.

​
1. Create the binding

A user becomes a tenant admin when they’re bound to the murmur-tenant-admin role, which grants * (every permission on every resource). You can bind a single user directly, or bind a group and manage membership separately. Groups are recommended for anything beyond one person, because you can add or remove members later without touching the binding itself.

​
A single user

Apply with murmur set: 
cat <<'EOF' | murmur set tenant-binding jane-tenant-admin
name: jane-tenant-admin
grant:
  users: [jane]
  role: murmur-tenant-admin
EOF
The username is the GitHub login. No github_oauth/ prefix. Create the group first, then bind it: 
cat <<'EOF' | murmur set group platform-admins
name: platform-admins
static:
  members: [jane, bob]
EOF

cat <<'EOF' | murmur set tenant-binding platform-admins-tenant-admin
name: platform-admins-tenant-admin
grant:
  groups: [platform-admins]
  role: murmur-tenant-admin
EOF
To onboard or offboard someone later, edit the group, not the binding. This keeps your bindings stable, makes membership changes easy to review, and means a future audit of “who is an admin?” answers itself.

​
2. Verify the promotion took

Before you walk away, confirm it actually worked. murmur check-permissions answers yes or no for each verb you list and shows you which binding produced the result: 
# Run as the newly-promoted user
murmur check-permissions tenant-binding.create role.create secret.create
A successful promotion shows yes on every check with Reason: root (the murmur-tenant-admin role grants *). Spot-check a handful of sensitive verbs (tenant-binding.create, secret.create, pool-config.edit) instead of trying to enumerate every kind. If one returns no, the binding probably points at a misspelled role or a group the user isn’t actually in.

​
3. Audit who has admin

Anyone with tenant-binding.create can promote others, including (in theory) promoting themselves to keep access if you remove them. Audit periodically with murmur get: 
murmur get tenant-binding
Look for any binding that points at murmur-tenant-admin or murmur-root. Both grant universal access. The GitHub org-owner binding is automatic and shows up under the murmur-org-admins group, which resolves dynamically against GitHub at evaluation time, so changes in GitHub propagate without needing a Murmur update.

​
Revoke admin

For a single-user binding, delete it with murmur rm: 
murmur rm tenant-binding jane-tenant-admin
For a group-based grant, you have two options. Delete the binding (revokes admin from everyone in the group at once): 
murmur rm tenant-binding platform-admins-tenant-admin
Or keep the binding and just remove the user from the group: 
cat <<'EOF' | murmur set group platform-admins
name: platform-admins
static:
  members: [jane]   # bob removed
EOF
To revoke admin from a GitHub org owner, you remove them from the GitHub org. The murmur-org-admins group is dynamic and stays in sync with GitHub, so the change takes effect on their next request without any Murmur action.

Authorization

Full permission model, built-in roles, every kind and verb.

Service Profiles

Service Profiles for Flights and automated agents.