google/sam is not Segment Anything. SAM here means Sovereign Agent Mesh, an Apache-2.0 networking project for autonomous AI agents. The problem it targets is concrete. Agents now run across cloud servers, on-prem datacenters, laptops, Raspberry Pis and Android devices. Letting them share tools usually means exposing internal scripts, LLM endpoints or private APIs to the public internet. SAM’s alternative is a zero-config, zero-trust P2P overlay — closer to a private VPN, but scoped to agent-to-agent tool sharing over the Model Context Protocol. Nodes discover each other automatically, survive NAT, and authorize every call cryptographically.
Note: The repo carries an explicit disclaimer: this is not an officially supported Google product.
Is it deployable?
Partially, the engineering is production-shaped, but the public mesh is still labelled a beta testnet.
- What ships now: Go binaries, an install script,
ghcr.ioDocker images, acharts/sam-meshHelm chart, a production Kubernetes guide, and Android/iOS support. The public testnet isbananas.sam-mesh.dev. For real workloads, self-host your control plane. The docs call this “DIY Mode” and it is the path to full data and policy control. - Company level: Best fit is mid-market and enterprise engineering orgs running agents across more than one network boundary. Startups inside a single VPC gain less; the value shows up once agents span cloud, datacenter and laptops.
- Industries: Financial services, healthcare, public sector and defense, and industrial or robotics edge fleets. Broadly, any regulated org that cannot publish internal tools to the internet.
- Applications: Cross-cloud MCP tool sharing, hybrid on-prem to cloud agent calls, brokered inference endpoints, sandboxed agents with credential injection, and pooled warm workers.
Architecture: three binaries
sam-control-plane— identity registration, token issuing, policy distribution.sam-router— libp2p bootstrap points and GossipSub routing overlays.sam-node— the P2P client providing mesh transport, self-healing connectivity, and a local MCP HTTP interface.
A node joins with sam-node join, then runs with sam-node run. libp2p uses 5001/udp and 5002/tcp; the local MCP API defaults to 8080.
Identity: OIDC in, Biscuit out
This is the interesting part. The control plane verifies an OIDC JWT. It then translates the claims into Datalog facts and seals them into a Biscuit token. sub becomes user(...), each group becomes group(...), and the peer ID binds in as client_peer_id(...).
The consequence: nodes authorize offline. A node evaluates the presented token against its own local rules without calling home.
Enforcement is strict default-deny. Access needs an explicit capability fact such as granted_service_exact(...). There are no built-in exceptions — even the discovery catalog system://sam.catalog must be granted. Services use a strict type://name convention with wildcard support (mcp://*, mcp://build-runner.*).
Every request runs a two-stage pipeline. Stage 1 gates the connection against ban and revocation caches. Stage 2 runs exactly two Biscuit authorizer passes. The first covers the node’s own identity token to emit target_fact assertions. The second covers the caller’s token. A baseline check blocks replay by requiring the connection peer ID to match the token.
Operators can attenuate locally, denying a write tool after 9 PM or blocking contractors. Local allows still cannot bypass control-plane check if constraints.
Interactive explainer


















