google/sam: A Sovereign Agent Mesh in Alpha, and What Its Label Gates Actually Enforce
SAM Sovereign Agent Mesh
At a glance
- What is it?
- SAM is an Apache-2.0 Go project from Google that gives autonomous agents a zero-trust peer-to-peer network with cryptographic identities and jurisdiction label gates. It is at v0.1.0-alpha.9, so the question is who can safely build on it now.
- Who is it for?
- Adopt SAM if you need agents to invoke tools across hosts you control, and you are willing to run sam-control-plane and sam-router yourself with your own Ed25519 root keys. Do not adopt it if you need a stable API or an SLA: the latest release is v0.1.0-alpha.9, and the public testnets at bananas.sam-mesh.dev and hub.sam-mesh.dev are explicitly documented as having no uptime commitment and no sovereign guarantees.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem SAM targets: agents that need to reach each other without a central broker
Most agent tool-calling today runs over a single host or through a cloud API that sits between the agent and the tool. SAM takes the opposite position. Its README describes a smart network built for autonomous AI agents, where lightweight sam-node processes form a self-healing peer-to-peer mesh so that agents can plug in, communicate, and invoke tools dynamically. The project's stated goal is sovereignty: custody of root keys, independent identity federation, and policy-enforced data boundaries, with no vendor telemetry and no hardcoded dependency on proprietary cloud services or model providers. That framing tells you the intended user. It is not someone wiring two scripts together on one laptop. It is an operator who has to answer a compliance question about where a prompt and its tool invocation physically executed, and who cannot answer that question with a SaaS control plane they do not hold keys for.
Three binaries and where trust is decided
The architecture splits into three components, and the split is the interesting part. sam-control-plane is the registry: node identity registration, authorization policies, and router coordinating. sam-router is the data plane: libp2p bootstrap nodes and relays that provide connectivity and forwarding. sam-node is the local client: mesh transport integration plus MCP sidecar routing, which is how an agent's tool calls reach the mesh. Trust is not decided in one place. The control plane issues and coordinates, but the README states that local node attenuation policies in sam-node.yaml are evaluated before control plane grants, so a node retains what the project calls absolute veto authority. That ordering matters more than the component list. It means a compromised or misconfigured control plane cannot force a local node to accept a call its own policy rejects. The cost is that policy now lives in two places, and an operator debugging a rejected invocation has to check both the control plane's authorization decision and the local attenuation file.
Jurisdiction gates: the concrete mechanism behind the sovereignty claim
The most specific technical claim in the README is the label gate. A node config carries labels such as labels: {jurisdiction: eu}, and requests carry a matching X-Sam-Required-Labels header. The project describes this as a fail-closed gate that mathematically guarantees prompts and tool invocations never leave authorized geographic scopes, and ties it to GDPR Chapter V, the EU Cloud Sovereignty Framework SEAL-3, and the EU Data Act. Treat the mechanism and the claim separately. The mechanism is checkable: a label on the node, a required-label header on the request, and a fail-closed default if they do not match. The regulatory mapping is the project's own reading of those frameworks and is not something a README can settle for your jurisdiction. If you are evaluating SAM for a data residency requirement, the thing to inspect is the gate implementation and its failure path, not the compliance section.
Getting a node onto the mesh
The README points to a quick start that installs SAM, adds the sam-mesh skill, and puts an agent on the mesh, described as a one-liner. For a dedicated deployment the path is different and heavier. The README lists running a control plane and routing relays on managed cloud, private Kubernetes, or air-gapped datacenters, using the Helm chart documented at charts/sam-mesh/README.md or Kubernetes manifests. Root signing keys are Ed25519, generated and held by the operator through local HSMs, KMS, or Cloud EKM. Identity bridging goes through an OIDC provider such as Dex or Keycloak. Local policy lives in sam-node.yaml. The exact install command is not reproduced in the README text supplied here, so check site/content/docs/quickstart.md and site/content/docs/user/kubernetes-deployment.md before you plan a rollout. The shape of the work is clear even without the command: your own cluster, your own keys, your own IdP, and a per-node YAML file.
The testnet is not the product, and the README says so
SAM ships two public endpoints, bananas.sam-mesh.dev and hub.sam-mesh.dev. The README is unusually direct about them: free testbeds built on community resources for developer testing, continuous integration, and rapid experimentation, with no guarantees, no uptime commitments, zero SLA, and no sovereign guarantees. It goes further and states that running on a shared community testnet delegates identity management to the testbed maintainers, so true sovereignty requires a dedicated control plane with customer-held keys. This is the sharpest limitation in the material, and it is a design consequence rather than a bug. The same property that makes the mesh easy to try (someone else runs the control plane) is the property that voids the sovereignty argument. If your evaluation consists of pointing an agent at hub.sam-mesh.dev and declaring success, you have tested connectivity and nothing else.
Alpha versioning, upgrade cost, and the Apache-2.0 terms
The release history is the practical constraint. v0.1.0-alpha.9 landed 2026-09-07, eight days after v0.1.0-alpha.8, which was itself sixteen days after v0.1.0-alpha.7. Three alpha releases in roughly three weeks is a fast-moving surface, and the project is not marked archived, so work is ongoing. Nothing in the supplied material describes a stability policy, a deprecation window, or a compatibility guarantee between control plane and node versions. Plan for the possibility that a control plane upgrade and a node upgrade have to happen together, and pin your images rather than tracking a tag. On licensing, the repository is Apache-2.0, which permits commercial use and modification and includes an explicit patent grant; it also requires that you preserve copyright and licence notices and state significant changes. The README states plainly that this is not an officially supported Google product and is not eligible for the Google Open Source Software Vulnerability Rewards Program. That second point is worth reading twice: a security flaw you find in SAM will not earn a bounty, which changes the incentive for anyone doing your security review. This is a description of the licence and the project's own disclaimer, not legal advice; get your own counsel on how Apache-2.0 interacts with your distribution model.
Where SAM is the wrong tool, and what to use instead
If your agents and tools all run inside one process, one machine, or one Kubernetes namespace, SAM adds a control plane, a relay tier, a node binary, and an identity bridge to solve a problem you do not have. A plain MCP server on localhost, or a single MCP gateway in front of your tools, gets you tool discovery and invocation with none of the key custody work. SAM is also a poor fit if you need a hosted service with a support contract and an uptime number, because the only hosted endpoints it offers are the community testbeds it disclaims. The honest comparison is with a conventional MCP gateway plus your existing service mesh and OIDC setup: that stack gives you authentication, authorization, and transport security, and it is mature. What it does not give you is a peer-to-peer topology where nodes discover each other without a central broker, or a per-node veto that overrides the control plane. If you do not need either of those two properties, the conventional stack is the better choice, and SAM's own README does not argue otherwise.
Editorial conclusion
Adopt SAM if you need agents to invoke tools across hosts you control, and you are willing to run sam-control-plane and sam-router yourself with your own Ed25519 root keys. Do not adopt it if you need a stable API or an SLA: the latest release is v0.1.0-alpha.9, and the public testnets at bananas.sam-mesh.dev and hub.sam-mesh.dev are explicitly documented as having no uptime commitment and no sovereign guarantees. Before committing, verify three things in the repository: that the Helm chart in charts/sam-mesh matches your Kubernetes version, that your OIDC provider (Dex, Keycloak or a corporate IdP) can be bridged as described, and that the label gate keys you intend to use are actually evaluated by the sam-node.yaml attenuation policies you plan to write.
Community notes