murmur check-permissions

Evaluates permissions against the caller’s effective grants. Each positional argument is a permission string in {kind}.{verb} format. The command prints a table showing whether each permission is granted or denied, and exits non-zero if any check is denied. Use this to verify what the current identity is allowed to do before attempting an operation, or to debug authorization issues. Without --resource, this checks tenant-wide grants only. To include resource and inherited workspace grants and the workspace.use requirement, provide the full catalog reference. A direct agent.read check does not prove discovery access: individual agent grants can authorize a direct read without making it appear in listings.

Synopsis

murmur check-permissions [flags] <kind.verb> [kind.verb ...]

Arguments

Name	Type	Required	Description
`kind.verb`	string	yes	One or more permissions to check, each in `{kind}.{verb}` format (e.g. `agent.read`, `secret.edit`).
`--resource`	string	no	Catalog resource ref in `{kind}/{name}` format, applied to all checks. May appear before or after the permissions.

Output

A tab-aligned table with one row per permission checked:

Column	Description
`PERMISSION`	The permission string that was evaluated.
`GRANTED`	`yes` if the caller has this permission, `no` if denied.
`REASON`	Explanation of why the permission was granted or denied.

The command exits with a non-zero status and prints one or more permissions denied if any permission is denied.

Examples

Check multiple permissions

murmur check-permissions agent.read agent.edit agent.delete

PERMISSION    GRANTED  REASON
agent.read    yes      tenant-binding:backend-developers
agent.edit    yes      tenant-binding:backend-developers
agent.delete  no       denied: no matching grant

Check a permission against a specific resource

murmur check-permissions --resource agent/github_oauth/alice/w/backend/fix-auth agent.edit

PERMISSION  GRANTED  REASON
agent.edit  yes      tenant-binding:backend-developers

The flag may also follow the permissions. For example, murmur check-permissions accepts agent.edit --resource agent/github_oauth/alice/w/backend/fix-auth as the same check.

Check workspace access

murmur check-permissions --resource workspace/backend workspace.read workspace.use

PERMISSION      GRANTED  REASON
workspace.read  yes      resource-grant:backend:0
workspace.use   yes      resource-grant:backend:0

This example has a matching murmur-workspace-user grant as the first entry in the workspace’s grants. Reasons reflect the grants configured in your tenant.

Errors

Code	Meaning	What to do
none	`invalid permission "<arg>": must be "{kind}.{verb}"`: a positional argument is not in `{kind}.{verb}` format. The CLI rejects it before contacting the server.	Fix the argument format and retry.
none	`invalid --resource "<ref>": must be "{kind}/{name}"`: `--resource` is not in `{kind}/{name}` format.	Fix the ref format and retry.
`INVALID_ARGUMENT`	The server rejected a permission or resource ref (for example, an unknown kind).	Check the kind and verb against Permissions.
`UNAUTHENTICATED`	Identity token is missing or expired.	Run `murmur login`, or check your `murmur.local.yaml` configuration.
none	`one or more permissions denied`: at least one permission was denied.	Review the output table to see which permissions were denied and why.

Authorization: how the authorization system evaluates grants
Permissions guide: understanding permission strings and roles
murmur status: query an agent’s current status

Getting Started

Core Concepts

Guides

murmur check-permissions

Synopsis

Arguments

Output

Examples

Check multiple permissions

Check a permission against a specific resource

Check workspace access

Errors

​Synopsis

​Arguments

​Output

​Examples

​Check multiple permissions

​Check a permission against a specific resource

​Check workspace access

​Errors

​Related

Synopsis

Arguments

Output

Examples

Check multiple permissions

Check a permission against a specific resource

Check workspace access

Errors

Related