SAM: Zero-Trust P2P Network for AI Agents

AI agents are no longer confined to a single server. They run on cloud VMs, on-prem datacenters, developer laptops, Raspberry Pis, and Android devices. The problem is that letting these agents share tools — scripts, LLM endpoints, internal APIs — usually means exposing private infrastructure to the public internet. That's a non-starter for any organization with real security requirements.

Google's answer is Sovereign Agent Mesh (SAM), released on August 18 under the Apache-2.0 license. Not Segment Anything — SAM is a zero-config, zero-trust P2P overlay network designed specifically for agent-to-agent tool sharing over the Model Context Protocol. Nodes discover each other automatically, survive NAT traversal, and authorize every call cryptographically. No firewall ports, no DNS config, no TLS cert management per service.

The repo at github.com/google/sam carries a frank disclaimer: this is not an officially supported Google product. But the engineering is production-shaped.

The Problem SAM Solves

When an agent on a cloud server needs to call a tool running on a developer's laptop, you have a few traditional options. You could expose the laptop's endpoint through a reverse proxy — but now your internal tool is on the internet. You could set up a VPN — but VPNs weren't designed for agent-to-agent tool discovery and authorization. You could build a custom API gateway — but that's infrastructure you now have to maintain.

SAM takes a different approach: a purpose-built overlay that treats every node as untrusted by default. The mesh handles peer discovery, NAT traversal, and cryptographic authorization automatically. Agents that join the mesh can expose MCP-compatible tools to other agents without opening firewall ports or managing certificates. The control plane handles identity; the data plane handles encrypted, authorized message delivery.

This matters because the agent ecosystem is moving toward multi-agent workflows where different agents handle different tasks. One agent might own code review, another handles deployment, and a third manages infrastructure. They need to call each other's tools securely, and SAM gives them the networking layer to do it.

Architecture: Three Binaries, One Overlay

SAM splits into three components:

• sam-control-plane — The registry. Handles node identity registration, OIDC authentication, Biscuit token issuance, and policy distribution. This is the only component that holds identity secrets.
• sam-router — libp2p bootstrap points and GossipSub routing overlays. Multiple routers can run for redundancy. They relay traffic but don't hold identity material or policy state.
• sam-node — The P2P client that every agent runs. Provides mesh transport, self-healing connectivity, and a local MCP HTTP interface.

A node joins the mesh with sam-node join and runs with sam-node run. The libp2p transport uses UDP port 5001 and TCP port 5002; the local MCP API defaults to port 8080. Nodes store their identity locally and can move between networks while keeping their PeerID — useful for agents on laptops that roam between home, office, and cloud.

# Join a mesh (requires OIDC credentials)
sam-node join --control-plane https://your-cp.example.com

# Run the node
sam-node run

# The local MCP API is now at http://localhost:8080
# Tools: discover_remote_services, find_remote_tools, call_remote_tool

For organizations that want full control, the docs recommend "DIY Mode" — self-hosting your own control plane. A public testnet exists at bananas.sam-mesh.dev, but it's labeled a beta testnet, not a production path.

How Authorization Actually Works

The authorization model is the most interesting part of SAM. It bridges traditional web identity (OIDC) with decentralized capability tokens (Biscuit), and the result is that nodes authorize requests offline.

Here's the flow: the control plane verifies an OIDC JWT — the same kind of token Google, Microsoft, and other identity providers issue. It then translates the JWT claims into Datalog facts and seals them into a Biscuit token. The sub claim becomes user(...), each group becomes group(...), and the peer ID binds in as client_peer_id(...).

When a node receives a request, it evaluates the Biscuit token against its own local rules without calling back to the control plane. This eliminates a central authorization bottleneck and means the mesh keeps functioning even if the control plane goes down.

Enforcement is strict default-deny. A freshly joined node exposes zero services to peers. Access requires an explicit capability fact like granted_service_exact(...). There are no built-in exceptions — even the discovery catalog (system://sam.catalog) must be explicitly granted. Services follow a type://name convention with wildcard support:

# Example policy: grant a contractor read-only MCP access
roles:
  name: contractor
  allowed_targets:
    - "group:backend-nodes"
  granted_services:
    - service_type: mcp
      service_name: "db-reader"
      permission: exact

Every request runs a two-stage pipeline. Stage 1 checks ban and revocation caches. Stage 2 runs two Biscuit authorizer passes — one for the node's own identity token, one for the caller's token. A baseline check blocks replay attacks by requiring the connection peer ID to match the token. Operators can add local attenuation rules too: deny a write tool after 9 PM, block contractors from specific services, enforce time-based restrictions.

Secure Outbound Gateway: sam-box

One of SAM's practical innovations is the Secure Outbound Gateway (sam-box). It solves a real agent-security gap: sandboxed agents often need to call external APIs, but you don't want to hand them API keys.

sam-box runs as a sidecar. A nano-init process acts as PID 1 inside the sandbox and sets proxy environment variables. For tools that ignore environment variables, it uses LD_PRELOAD to intercept the C connect() syscall on ports 80 and 443. Traffic routes through a Unix domain socket to sam-box, which verifies the Biscuit token, injects the real credential from secrets.yaml, and upgrades the request to HTTPS. The agent sandbox never holds the key.

This is a clean separation: the agent can make outbound requests, but it never sees the actual credentials. The gateway handles authentication, the sandbox handles execution, and the Biscuit token ensures only authorized agents can reach specific services.

Where SAM Fits in the Agent Infrastructure Stack

SAM isn't a general-purpose service mesh like Istio or Linkerd. It doesn't handle HTTP routing, load balancing, or circuit breaking for web services. It's scoped to agent-to-agent tool sharing over MCP — a narrower problem, but one that's becoming increasingly important as multi-agent architectures proliferate.

The project enters a crowded space. Startups and open-source projects have released various agent communication protocols and tool-sharing frameworks over the past eighteen months. What distinguishes SAM is the combination of zero-trust networking, offline authorization via Biscuit tokens, and support for heterogeneous environments — cloud, datacenter, laptop, Raspberry Pi, Android.

For organizations running agents across multiple network boundaries — financial services, healthcare, public sector, industrial edge fleets — SAM offers something that generic networking tools don't: a purpose-built overlay that treats every node as untrusted and every service as explicitly granted.

The project is on GitHub under Apache-2.0, with Docker images on ghcr.io, a Helm chart, production Kubernetes guides, and integration docs for Gemini, Claude Code, and other agents. The public testnet is a starting point; the real value is in self-hosted deployments where you control the identity and policy layer.