Skip to main content
Murmur uses GitHub as the identity provider. There are no separate Murmur accounts. You log in with GitHub, and the platform determines what you can access from your GitHub org memberships.

​
Developer authentication

Developers authenticate in two ways depending on the interface: CLI and MCP: the CLI signs you in with GitHub (your gh CLI session or the GitHub device flow) and stores the resulting identity credential in your OS keychain. Every API call includes this credential. murmur setup signs you in during bootstrap, and murmur login signs in again or switches accounts. The GitHub token your agents use (the gh CLI token or a personal access token) is a separate credential that murmur setup configures. A personal access token is stored encrypted in your developer profile. With the gh CLI choice, the token is read from gh auth token at each spawn. A key in MURMUR_API_KEY replaces the keychain identity for CI; see API keys. Dashboard: the web dashboard uses GitHub OAuth. You click “Log in with GitHub,” authorize the Macroscope GitHub App, and receive a session cookie. The session is encrypted and refreshed automatically.

​
Tenant membership

Your tenant access is derived from GitHub:
  • Personal tenants: every authenticated GitHub user has a personal tenant (github_oauth/{username}). No setup required.
  • Organization tenants: when your GitHub org installs the Macroscope GitHub App, every org member can access that tenant (github_app/{org}). Membership is checked against GitHub’s org membership API on every request.
There is no invite system. If you’re in the GitHub org, you’re in the Murmur tenant. If you leave the org, you lose access.

​
Agent authentication

Agents running on VMs authenticate with an identity token Murmur mints for that specific agent. The signed token’s subject is the agent’s own identity. Murmur resolves it server-side to the agent and authorizes calls against the agent’s own subtree, so a VM can manage its own run and the child agents it launches. The token is sealed into the encrypted profile only that VM can open, decrypted in VM process memory, re-minted each time the agent wakes, and destroyed with the process when the agent stops. Additional permissions reach a running agent through grants naming its runtime principal directly, or through tenant-binding and workspace grants with extend_to_runtime_agents. Extended grants are evaluated live on every request against the recorded service profile, including a borrowed one, or otherwise the developer owner. Current membership and grant changes affect already-running agents. See runtime extension. The VM uses GH_TOKEN for git and GitHub operations. Developer agents receive your user token, while service agents receive the App installation token.

​
Service agents

Service agents authenticate to Murmur the same way, with an agent-scoped identity token minted at workflow start. What differs is whose authority they carry: they operate on behalf of the org via their service profile, not a specific developer, and their GitHub credential is the App installation token.