Skip to main content
A Service Profile is a non-human identity that automated agents run under. Instead of running as a developer (with their GitHub token, their Claude key, their commit identity), the agent runs as the profile and commits as a bot author with the GitHub App’s avatar. Use a Service Profile when you want:
  • Bot-authored commits. Commits made by event-driven Flights show as your-bot[bot] instead of as whichever developer happened to trigger them. That keeps audit trails clean and makes review history easier to read.
  • Identity that outlives any person. When a developer leaves the team their tokens get rotated, but a Flight that runs nightly shouldn’t break. A Service Profile is independent of any human, so it keeps working.
  • Scoped permissions. Grant the service profile authority through tenant-bindings or grants on the target workspace. The profile’s own Access Grants control who can assume it, not what it can do elsewhere.
Service Profiles are created from the dashboard. Power users can also apply the same resource from the CLI with murmur set; see service-profile for the full schema.

​
1. Create the profile

  1. Sign in at cloud.murmur.dev.
  2. Go to Organization Settings → Automations → Service Profiles.
  3. Click New Service Profile and fill in the form:
    • Name (required, immutable): lowercase letters, digits, and hyphens. The name appears in audit logs and grants.
    • Git Author Name: defaults to {app_slug}[bot]. This is what shows in commit metadata.
    • Git Author Email: defaults to {app_id}+{app_slug}[bot]@users.noreply.github.com. GitHub recognizes this format specifically as a bot noreply, which is how it gets the App’s bot avatar to appear on commits. Don’t change the format unless you know what you’re doing.
    • Claude Credentials (required): click +, name the secret (e.g. ANTHROPIC_KEY), and paste an Anthropic API key or OAuth token. The credential is encrypted and stored as a tenant secret. The profile gets its own credential because it’s an independent identity, not because of any developer’s account.
    • Access Grants (optional): name the users or groups permitted to assume this service profile, using service-profile.assume. Empty grants add no resource-specific access; existing tenant-bindings still apply.
  4. Click Create Profile.

​
2. Use it when spawning

Choose the service profile in the Spawn dialog’s identity picker. The agent uses its bot author and configured credentials. Requests use the runtime’s own permissions plus grants extended live from the service profile; see runtime extension. For Flights, attach the profile on the Flight resource itself and every agent the Flight launches inherits the identity:
This is the recommended pattern for event-driven Flights (bug-fixer, dependabot follow-up, CI failure responder). Whichever developer triggered the event shouldn’t end up authoring the bot’s commits.

​
Edit, delete, audit

  • Edit: click any row. Every field except Name is editable. Changing a credential rotates it; existing agents keep using the version they were spawned with.
  • Delete: hover and click the trash icon. Platform-managed service profiles cannot be deleted. Deleting one leaves its running agents in place, stops grants extending from that identity on subsequent requests, and prevents new spawns from referencing it.
  • History: click the clock icon to roll back to a previous version. Useful if a credential rotation goes wrong or someone edits the grants in a way that breaks a Flight.

Authorization

Full permission model, including service-profile.assume.

Flights

Attach a Service Profile to a Flight.