SAM: Google's Apache-2.0 P2P Mesh Lets AI Agents Share Tools Without Touching the Internet

August 18, 2026news

google/sam — Sovereign Agent Mesh — is an Apache-2.0 zero-config, zero-trust P2P overlay network designed for autonomous AI agents that need to discover and invoke each other's tools without routing traffic through the public internet. The project ships as Go binaries, an install script, ghcr.io Docker images, a charts/sam-mesh Helm chart, a production Kubernetes guide, and Android and iOS support. A public testnet runs at bananas.sam-mesh.dev. The repo carries an explicit disclaimer: this is not an officially supported Google product.

The problem SAM targets is concrete. Agents now run across cloud VMs, on-premises datacenters, laptops, Raspberry Pis, and Android devices simultaneously. Letting them exchange tools typically means exposing internal scripts, LLM endpoints, or private APIs to the internet — unacceptable for financial services, healthcare, public sector, defense, and industrial edge fleets. SAM treats this as a networking problem rather than an application-layer one, distinguishing it from coordination frameworks that require a shared orchestration contract across agent control layers. The public mesh is explicitly labelled a beta testnet; real workloads should self-host the control plane via what the docs call "DIY Mode."

Three-Binary Architecture

SAM decomposes into exactly three binaries. sam-control-plane handles identity registration, token issuance, and policy distribution. sam-router provides libp2p bootstrap points and GossipSub routing overlays. sam-node is the P2P client, delivering mesh transport, self-healing connectivity, and a local MCP HTTP interface. A node joins with sam-node join and serves with sam-node run. The libp2p layer binds to 5001/udp and 5002/tcp; the local MCP API defaults to port 8080. Nodes expose three standard MCP tools to their agents: discover_remote_services, find_remote_tools, and call_remote_tool. The command sam-node skill install writes a SKILL.md so an agent can bring a node online autonomously — though the enrollment login step remains with a human by design.

OIDC-to-Biscuit Identity Translation

The control plane accepts an OIDC JWT, verifies it, and translates its claims into Datalog facts sealed inside a Biscuit token. The sub claim becomes user(...), each group membership becomes a group(...) fact, and the node's peer ID is bound in as client_peer_id(...). The result is offline authorization: a receiving node evaluates the Biscuit token against local policy rules without calling back to the control plane, surviving outages and introducing no per-request latency from a central authority — a meaningful property for agent systems operating at the frontier where verification bottlenecks become a liability.

Every inbound request runs a two-stage pipeline. Stage 1 checks the connecting peer against ban and revocation caches. Stage 2 executes 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, with a baseline replay check requiring the connection peer ID to match the token peer ID. The enforcement posture is strict default-deny — no service is reachable until a policy grants an explicit capability fact such as granted_service_exact(...). Even the discovery catalog at system://sam.catalog requires an explicit grant. Services follow a type://name convention with wildcard support, so patterns like mcp://* and mcp://build-runner.* are valid. Operators can attenuate locally after the fact, but local allows cannot bypass control-plane constraints.

Secure Outbound Gateway

The Secure Outbound Gateway (sam-box and nano-init) keeps credentials out of agent sandboxes entirely. nano-init runs as PID 1 inside the sandbox and sets proxy environment variables. For tools that bypass them, it uses LD_PRELOAD to hook the C connect() syscall on ports 80 and 443. Traffic reaches sam-box over a Unix domain socket. The gateway verifies the Biscuit, injects the real credential from secrets.yaml, and upgrades the connection to HTTPS before forwarding. The sandboxed agent never holds the API key — directly mitigating the class of credential-exfiltration risk seen in incidents like the public Sentry key exposure via a coding agent.

Deployment Targets

Capability SAM Public Testnet SAM Self-Hosted (DIY Mode)
Control plane location bananas.sam-mesh.dev Operator-managed infrastructure
Data sovereignty Partial — metadata touches Google-run plane Full — all identity and policy on-premises
Policy control Shared defaults Operator-defined Datalog rules
Production readiness Beta testnet only Production Kubernetes guide ships
Best-fit org size Evaluation and prototyping Mid-market and enterprise across multiple network boundaries
Credential injection (sam-box) Available Available with operator-controlled secrets.yaml
NAT traversal Yes — libp2p relay Yes — operator-deployed routers

The project also documents a warm agent pool pattern: a manager fans batch work across identical running workers discovered via DHT, tracking availability with leases, fencing tokens, and a POOL_BUSY backstop. Workers verify short-lived HMAC tokens offline; anything without a valid lease returns NO_LEASE.

SAM's release positions agent networking as purpose-built infrastructure with cryptographic enforcement at every hop rather than an application-layer convention. The Apache-2.0 license removes adoption friction for enterprise evaluation, and the Helm chart plus Kubernetes guide indicate self-hosted deployments are the intended serious path. Whether the offline Biscuit model holds under adversarial attenuation scenarios — particularly as agent-to-agent call graphs deepen — will determine whether SAM becomes a foundational layer or a well-engineered prototype.