google/sam: a zero-trust P2P mesh for autonomous AI agents

The problem SAM targets: agents that cannot reach each other

Most agent frameworks assume the tools an agent calls live on the same host or behind one vendor's API. The moment you want a reviewer agent in one cluster to call a summarizer agent in another, you are back to writing bespoke networking, credential distribution and firewall rules. SAM's answer is to treat the network itself as the integration layer. Nodes run as `sam-node` processes, discover each other, and expose tools over the mesh so an agent can invoke them without a pre-arranged endpoint.

The intended audience is platform and infrastructure engineers who have to run agents under constraints that a hosted API cannot satisfy: data that must stay in a jurisdiction, identities that cannot be minted by a third party, or sites that are partly air-gapped. The README frames this as sovereignty, defined as custody of root keys, independent identity federation and policy-enforced data boundaries rather than as a marketing claim about where the servers sit.

How the mesh is wired: control plane, routers, nodes

The repository names three components. `sam-control-plane` is the registry: node identity registration, authorization policies and router coordination. `sam-router` provides libp2p bootstrap nodes and relays, which is the data plane. `sam-node` is the local client that integrates mesh transport and routes MCP traffic to a sidecar.

The dependency list in `go.mod` shows what that is built on. `github.com/libp2p/go-libp2p` plus `go-libp2p-kad-dht` and `go-libp2p-pubsub` supply peer discovery and gossip; `go-libp2p-gostream` and `go-libp2p-http` carry HTTP over libp2p streams; `github.com/modelcontextprotocol/go-sdk` is the MCP side; `github.com/a2aproject/a2a-go/v2` appears for agent-to-agent messaging; `github.com/biscuit-auth/biscuit-go/v2` is the authorization token format. Persistence leans on `modernc.org/sqlite`, `go.etcd.io/bbolt` and `github.com/jackc/pgx/v5`, so a control plane can run against SQLite, an embedded key-value store or PostgreSQL depending on the deployment.

The identity model is Ed25519 root signing keys that the operator generates and holds, with OIDC federation for bridging user and agent identities through an existing provider such as Dex or Keycloak. Policy enforcement is split in two: the control plane grants, and the local node evaluates `sam-node.yaml` attenuation rules before that grant is honoured. The README describes this as nodes retaining an absolute local veto. That ordering is the most interesting design decision in the project, because it means a compromised or misconfigured control plane cannot unilaterally widen what a node will accept.

Installing sam-node and joining the developer testnet

The README points at the Quick Start Guide and describes getting started as a one-liner: install, add the skill, and the agent is on the mesh. Binaries or Docker are both offered. The repository ships an `install.sh` at the top level and a `Dockerfile.sam-node`, so both paths are real rather than aspirational.

For a source build, the Makefile builds the whole set of binaries into `bin/`. This is what a contributor runs first:

make build
./bin/sam-node --help

The default goal is `build`, and it compiles `sam-node`, `sam-control-plane`, `sam-router`, `sam-one`, `mcp-client`, `sam-box`, `sam-bench` and `sam-console`. Two binaries, `nano-init` and `sam-a2a-bridge`, are separate Go modules built with `go -C`, which the Makefile comments explain keeps a userspace TCP stack and the A2A SDK out of the root dependency graph. Expect the first build to pull a large module set.

The README gives the community testnet endpoints as `bananas.sam-mesh.dev` and `hub.sam-mesh.dev`. A node config carries labels used for jurisdictional gating, and the README shows the shape directly:

labels: {jurisdiction: eu}

On the wire, the required-labels header is `X-Sam-Required-Labels`. The point of the label gate is that a prompt or tool invocation whose required labels do not match the node's attested labels is refused rather than downgraded. The README calls this fail-closed. What you should see after joining is the node registering with the control plane and becoming discoverable; tool invocation from an agent then flows over the mesh rather than to a fixed URL. The README also points at a testnet validation tutorial for verifying remote tool invocation and HTTP stream proxies, which is the right place to confirm the mesh is actually carrying traffic before you trust it.

Where SAM is the wrong tool

The README is unusually direct about one limitation: the public endpoints are community testbeds with no guarantees, no uptime commitments, zero SLA and no sovereign guarantees. Running there delegates identity management to whoever maintains the testbed. If your requirement is sovereignty, the testnet is not a deployment, it is a smoke test.

The release history is the second constraint. The newest tag is v0.1.0-alpha.9, published on 2026-09-07, preceded by alpha.8 and alpha.7 within weeks of each other. Alpha releases at that cadence mean interfaces, config keys and CLI flags can move between versions, and the README does not document rollback or a compatibility policy. A team that needs a frozen API surface for a two-year integration should look elsewhere for now.

There is also a category error to avoid. SAM is not an agent framework. It does not plan, reason or manage prompts. If your problem is that one agent on one machine needs better tool selection, adding a mesh adds a control plane, routers and a key custody problem for no benefit. The mesh earns its cost when agents are already distributed across trust boundaries.

How SAM differs from running agents behind a service mesh

Istio and Linkerd are the obvious comparison, and the difference is where identity comes from. A service mesh issues workload identities from a cluster-local certificate authority and assumes the cluster is the trust domain. SAM issues Ed25519 identities from a root key the operator holds, and the README states that cryptographic identities are environment-agnostic so a node can move between cloud, local and edge environments. A workload that leaves the cluster keeps its identity; a SPIFFE-style identity generally does not.

The second difference is the unit of authorization. Service meshes authorize connections between services. SAM authorizes tool invocations between agents, with `X-Sam-Required-Labels` carrying the constraint and the local node holding veto power. That is a policy model aimed at data residency, where the question is not whether service A may reach service B but whether this particular invocation is allowed to leave a jurisdiction.

If your agents all live in one Kubernetes cluster and your identity provider already satisfies your auditors, a service mesh is the smaller, better-understood answer. SAM starts to pay off when peers sit in different administrative domains and the control plane is not something you fully trust.

Maintenance, upgrade cost and the Apache-2.0 terms

The repository is not archived and the last push was on 2026-09-10, ten days before this writing. That is a live project, but the release line is still alpha, so treat upgrades as migrations rather than patch installs: read the release notes for each tag, and expect that a `sam-node.yaml` that worked on alpha.7 may need review by alpha.9. The README does not describe a deprecation window, which is the thing to watch for as the project approaches a stable tag.

Licensing is Apache-2.0, which permits commercial use, modification and redistribution with the usual notice and patent-grant terms. Two repository-level caveats matter more than the licence text. The README states this is not an officially supported Google product, and that it is not eligible for the Google Open Source Software Vulnerability Rewards Program. In practice that means no vendor security response process backs the code you deploy; your own review is the control. None of this is legal advice, and the `LICENSE` file governs.

The build itself has a real cost. CGO is disabled by default in the Makefile for static binaries, and the dependency graph includes libp2p, an MCP SDK, an A2A SDK, three storage engines and OIDC libraries. That is a large surface to track for CVEs and a large surface to vendor.

Editorial conclusion

Adopt SAM if you need agents to discover and call each other's tools across clouds or edge sites under identities you hold yourself, and you can run a control plane and routers on your own infrastructure. Do not adopt it if you need a stable API, an uptime commitment, or a managed service: the newest release is v0.1.0-alpha.9 and the README states the public testnets give zero SLA. Before committing, verify on your own hardware that your sam-node.yaml policies actually veto a call the control plane would otherwise grant, because that local veto is the property the whole sovereignty story rests on.

Frequently asked questions

Official sources

1. google/sam on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases