Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.murmur.dev/llms.txt

Use this file to discover all available pages before exploring further.

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. A profile has its own Access Grants, so you can give the bot exactly what it needs (e.g. spawn agents in one Workspace) without copying a developer’s full scope.
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 → Agents → Service Profile.
  3. Click New Service Profile and fill in the form:
    • Name (required, immutable): lowercase letters, digits, and hyphens. Choose carefully because you can’t rename later. The name will appear 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): bind Groups or Users to a role or to an inline permission list. Use this to scope what the bot can do (e.g. spawn agents in one Workspace, but not edit any catalog resources). Leave grants empty to fall back to your tenant’s default bindings.
  4. Click Create Profile.

​
2. Use it when spawning

Once the profile exists, the Spawn dialog grows an identity picker next to the Workspace and Model fields. Choose the profile and the agent runs as the bot: bot author on commits, bot’s encrypted Claude credential for the model, bot’s Access Grants for what it’s allowed to do. For Flights, attach the profile on the Flight resource itself and every agent the Flight launches inherits the identity: 
service_profile: my-bot
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 profiles (lock badge) can’t be deleted. Deleting a profile doesn’t kill in-flight agents that are using it; it just means future spawns can’t reference 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.