allowlists), and a set of actor lists whose members may never steer — denylists, overriding both. An event whose author fails the policy is recorded on the agent’s timeline as BLOCKED and is never delivered: no follow-up, no checklist task, no wake, no flight spawn.
A steering policy controls who may initiate agent work from outside — not what the agent may do once it is working. In the dashboard, steering policies are managed under Organization Settings → Steering Policies.
Fields
Tiers
Thetier field sets the minimum GitHub author association that may steer. The tiers below run from broadest to narrowest — COLLABORATORS admits everyone MEMBERS does, plus repository collaborators.
Denylists
An actor list is a named set of usernames with no polarity of its own — the referencing field decides. Naming a list underallowlists admits its actors; naming one under denylists refuses them. That lets you subtract individual actors from an otherwise-broad policy: keep the tier open for everyone with repository access while stopping one noisy machine account — a preview bot that comments on every push, for example.
Matching is identical in both directions: provider-scoped (a GitHub login is matched in PROVIDER_GITHUB_OAUTH) and case-insensitive against the event author’s login, unioned across every list the field names.
A list may be named by allowlists or denylists, never both — deny would silently win, so a policy that says both is rejected at write time. To subtract an actor from a list you otherwise admit, name a second, narrower list on denylists:
steering_denylist_denied, so it is distinguishable from a tier or allowlist miss.
Precedence
- An agent’s own owner always steers it. A denylist never locks a developer out of their own agent — revoking a person’s authority is a role change, not a steering policy.
- Denylists beat everything else. A denied author is blocked even when the tier admits them and even when an allowlist (this policy’s own, or another applicable policy’s) names them.
- Tier, then allowlists. An author no denylist names is admitted by the tier or, failing that, by an allowlist.
How a policy is selected
A steering policy is chosen per event, by the repository the event came from and — for service-profile agents — by the owning profile:- Per repository —
repo-config.steering_policynames a policy explicitly. When unset, the platform selects by repository visibility: public repos usemurmur-public-steering-policy, private repos usemurmur-private-steering-policy. Both are platform builtins. - Per service profile —
service-profile.steering_policynames a policy for agents running under that identity.
Examples
Require organization membership
Allowlist-only, with trusted actors
Turn the tier check off and admit only the users named in an actor allowlist.Everyone on a private repo, except a preview bot
STEERING_TIER_OPEN admits any author, so this shape fits a private repository — where everyone who can comment was already granted access by the organization — and subtracts the machine accounts that must never steer. On a public repository, where anyone on GitHub can comment, pair denylists with a restrictive tier (STEERING_TIER_COLLABORATORS or narrower) instead.
First the actor list naming the bots:
murmur patch updates just the one field, preserving any repo-config settings the repository already has (murmur set would replace the whole resource):
Members, plus an allowlist of outside contributors
Listing steering policies
Reading a single steering policy
Errors
Related
- actor-allowlist — the named actor lists a policy admits (
allowlists) or refuses (denylists) - service-profile — references a steering policy for agents under that identity
- repo-config — references a steering policy per repository
- Events — the webhook events steering gates
murmur set— CLI command for creating and updating catalog resourcesmurmur get— CLI command for reading catalog resources