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.

By default, agents run on platform-managed infrastructure. If you need agents in your own cloud — for compliance, data residency, or VPC-internal access — you can create a customer placement.
This is an advanced, optional feature. Most teams don’t need it. Platform-managed placements work out of the box with no cloud setup.

When to use customer placements

  • Compliance: Your security team requires compute in your own account
  • Data residency: Regulatory requirements for specific regions
  • VPC-internal access: Agents need to reach internal services (databases, APIs) inside your VPC
  • Custom networking: Specific firewall rules, proxy configuration, or VPN requirements

How it works

  1. You run a Terraform module in your cloud account that creates a trust relationship
  2. Murmur authenticates to your cloud via OIDC token exchange (Workload Identity Federation)
  3. The trust is scoped to exactly your tenant — no other Murmur tenant can use your resources
  4. You create a placement catalog resource pointing to your infrastructure
  5. Your workspace references this placement

GCP setup

1. Apply the Terraform module

In your GCP project:
module "murmur_placement" {
  source = "github.com/prassoai/murmuration//terraform/gcp/modules/wif-customer"

  project_id   = "your-project-id"
  tenant_id    = "github_app/your-org"        # your Murmur tenant ID
  oidc_issuer  = "https://oidc.murmur.dev"    # Murmur's OIDC issuer
  network      = "your-vpc"
  subnet       = "your-subnet"
  zones        = ["us-central1-a"]
}
This creates:
  • A Workload Identity Federation pool with OIDC provider
  • A service account for Murmur VMs
  • IAM bindings scoped to your project
  • Firewall rules for SSH via IAP

2. Create the placement

cat <<EOF | murmur set placement my-gcp
name: my-gcp
platform: false
substrate: GCP
target:
  gcp:
    project: your-project-id
    zones: ["us-central1-a"]
    subnet: your-subnet
    wif_provider_resource_name: "projects/123/locations/global/..."
    wif_service_account: "murmur-vm@your-project.iam.gserviceaccount.com"
EOF

3. Update your workspace

murmur patch workspace my-team --set placement=my-gcp

AWS setup

1. Apply the Terraform module

In your AWS account:
module "murmur_placement" {
  source = "github.com/prassoai/murmuration//terraform/aws/modules/wif-customer"

  tenant_id   = "github_app/your-org"
  oidc_issuer = "https://oidc.murmur.dev"
  vpc_id      = "vpc-abc123"
  subnet_ids  = ["subnet-abc123"]
  region      = "us-east-1"
}
This creates:
  • An OIDC provider with StringEquals trust policy (scoped to your tenant)
  • An IAM role for Murmur VM operations
  • Security group for agent VMs

2. Create the placement

cat <<EOF | murmur set placement my-aws
name: my-aws
platform: false
substrate: AWS
target:
  aws:
    account_id: "123456789012"
    region: "us-east-1"
    vpc_id: "vpc-abc123"
    subnet_ids: ["subnet-abc123"]
    role_arn: "arn:aws:iam::123456789012:role/murmur-vm"
    oidc_provider_arn: "arn:aws:iam::123456789012:oidc-provider/oidc.murmur.dev"
EOF

Cryptographic isolation

The key security property: your OIDC trust policy uses StringEquals on the sub claim, scoped to exactly your tenant ID. This means:
  • Only Murmur can assume your IAM role (OIDC issuer validation)
  • Only your tenant’s agents can use your placement (sub claim matching)
  • No other Murmur tenant can ever access your cloud resources
This is enforced at the IAM layer — not by Murmur application logic.

Platform vs customer placements

AspectPlatform placementCustomer placement
Who managesMurmurYou
platform fieldtruefalse
Cloud accountMurmur’sYours
Setup requiredNoneTerraform + placement resource
NetworkingPlatform-managedYou configure VPC/subnets
IAM isolationMulti-tenant (platform-level)Single-tenant (your IAM policy)