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.io Docker images, a charts/sam-mesh Helm chart, a production Kubernetes guide, and Android/iOS support. The public testnet is bananas.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