Google has released SAM, an infrastructure project that rethinks how autonomous AI agents discover and call one another’s tools across network boundaries without exposing private endpoints to the public internet. SAM stands for Sovereign Agent Mesh, not Segment Anything — and the distinction matters. The repository at github.com/google/samcodecodecodecodecodecode carries an Apache-2.0 license and a frank disclaimer: this is not an officially supported Google product. What ships is a zero-config, zero-trust P2P overlay network, closer in spirit to a private VPN but scoped specifically to agent-to-agent tool sharing over the Model Context Protocol (MCP). Nodes discover each other automatically, survive NAT, and authorize every cryptographic call without phoning home to a central server.
Why a dedicated agent mesh exists: the connectivity problem SAM solves
The problem SAM targets is concrete and growing more acute by the quarter. AI agents today run across cloud servers, on-premises datacenters, laptops, Raspberry Pis, and Android devices. Letting those agents share tools — internal scripts, LLM endpoints, private APIs — usually means exposing those resources to the public internet or maintaining a patchwork of VPN tunnels. Neither option scales well for organizations running more than a handful of agents across more than one network boundary.
SAM’s alternative is a purpose-built overlay that treats every node as untrusted by default. The mesh provides automatic peer discovery, NAT traversal, and cryptographically enforced authorization. Agents that join the mesh can expose MCP-compatible tools to other agents without opening firewall ports, configuring DNS, or managing TLS certificates for every service. The control plane handles identity; the data plane handles encrypted, authorized message delivery.
What is the Sovereign Agent Mesh? A zero-trust P2P overlay for agent tool sharing
The Sovereign Agent Mesh is a networking layer that enables autonomous AI agents to share tools and capabilities across distributed environments without exposing those tools to the public internet. It uses a three-component architecture — a control plane for identity and policy, routers for bootstrap and message routing, and nodes as the P2P clients — to create a self-healing overlay. Every inter-agent call is cryptographically authorized using Biscuit tokens derived from OIDC identities, and the system enforces default-deny access: no service is reachable until a policy explicitly grants it.
Architecture: three binaries that form the mesh
SAM’s architecture breaks down into exactly three binaries, each with a distinct responsibility. Understanding the separation helps clarify where trust lives and how data flows.
sam-control-plane — identity, policy, and token issuance
The control plane registers node identities, authenticates users via OIDC, issues Biscuit tokens, and distributes policy. Organizations can use the public testnet at bananas.sam-mesh.devcodecodecodecodecodecode, but the documentation explicitly recommends self-hosting the control plane for real workloads. The docs call this “DIY Mode,” and it is the recommended path for achieving full data and policy control. The control plane is the only component that needs to be trusted with identity secrets and policy definitions.
sam-router — bootstrap and GossipSub routing
Routers serve as libp2p bootstrap points and participate in GossipSub routing overlays. They help nodes discover each other on first join and relay traffic for peers stuck behind NAT. Multiple routers can run in a mesh for redundancy. They forward data-plane traffic but do not hold identity material or policy state — their role is purely infrastructural.
sam-node — the P2P client that agents actually run
The node is what every agent or service runs to join the mesh. It provides mesh transport, self-healing connectivity, and a local MCP HTTP interface. A node joins with sam-node joincodecodecodecodecodecode, then runs with sam-node runcodecodecodecodecodecode. The libp2p transport uses UDP port 5001 and TCP port 5002; the local MCP API defaults to port 8080. Nodes store their identity in a local data directory and can move between networks while keeping their PeerID — an important property for agents running on laptops that roam between home, office, and cloud.
Identity model: OIDC in, Biscuit out — and authorization that works offline
The identity and authorization system is arguably the most carefully engineered part of SAM. The control plane verifies an OIDC JWT — the same kind of token used by Google, Microsoft, and other identity providers. It then translates the JWT claims into Datalog facts and seals them into a Biscuit token. The translation is direct: subcodecodecodecodecodecode becomes user(...)codecodecodecodecodecode, each group claim becomes group(...)codecodecodecodecodecode, and the peer ID binds in as client_peer_id(...)codecodecodecodecodecode.
The consequence is significant: nodes authorize requests offline. A node evaluates the presented Biscuit token against its own local rules without calling back to the control plane. This eliminates a central authorization bottleneck and means the mesh continues functioning even if the control plane is temporarily unreachable. The token itself carries all the facts needed to make an authorization decision.
How does SAM handle authorization without a central server?
SAM uses Biscuit tokens, which are cryptographic tokens that embed Datalog facts and allow offline verification. When a node receives a request, it evaluates the presented token against locally stored policy rules without contacting the control plane. The token carries all identity claims — user, groups, peer ID, expiration — as immutable facts. The node runs a two-stage authorization pipeline that checks connection gating first, then evaluates the token against granted service policies. This design eliminates the need for a central authorization server during runtime and allows the mesh to remain operational during network partitions.
Default-deny authorization: nothing is reachable until a policy says so
SAM enforces a strict default-deny model. A freshly joined node exposes zero services to peers. Access requires an explicit capability fact such as granted_service_exact(...)codecodecodecodecodecode. There are no built-in exceptions — even the discovery catalog, addressed as system://sam.catalogcodecodecodecodecodecode, must be explicitly granted. Services use a strict type://namecodecodecodecodecodecode convention with wildcard support: mcp://*codecodecodecodecodecode matches any MCP service, while mcp://build-runner.*codecodecodecodecodecode matches all services under that prefix.
Every request runs a two-stage authorization pipeline. Stage 1 gates the connection against a ban list and revocation cache. Stage 2 runs exactly two Biscuit authorizer passes. The first pass covers the destination node’s own identity token and emits target_factcodecodecodecodecodecode assertions. The second pass covers the caller’s request token. A baseline replay check requires the connection’s peer ID to match the peer ID embedded in the token — a simple but effective defense against token reuse from different nodes.
Operators can attenuate access locally. A node operator might deny a write tool after 9 PM or block contractors from certain services. Local allow rules still cannot bypass control-plane check ifcodecodecodecodecodecode constraints — the control plane retains ultimate authority over what facts are valid.
Deployability: what ships now and who should care
The engineering is production-shaped, but the public mesh is still labelled a beta testnet. Organizations evaluating SAM should understand what is ready today and where the rough edges remain.
What ships now
The repository ships Go binaries, a one-line install script, Docker images on ghcr.iocodecodecodecodecodecode, a Helm chart at charts/sam-meshcodecodecodecodecodecode, a production Kubernetes deployment guide, and support for both Android and iOS nodes. The public testnet runs at bananas.sam-mesh.devcodecodecodecodecodecode. For production workloads, the docs recommend self-hosting the control plane — what they call “DIY Mode” — which gives the operator full data and policy control.
Company profile: who benefits most
The best fit is mid-market and enterprise engineering organizations running agents across more than one network boundary. Startups operating inside a single VPC gain less from SAM; the value appears once agents span cloud, datacenter, and laptops. Organizations that have already adopted MCP as a tool-sharing protocol will find the integration most natural, though SAM can wrap non-MCP services behind its gateway.
Industries where SAM makes the most sense
Financial services, healthcare, public sector, defense, and industrial or robotics edge fleets are the primary candidates. These are regulated environments that cannot publish internal tools to the internet and need cryptographic guarantees about who is calling what. For a hospital running agent-based diagnostic tools across on-premises servers and cloud inference endpoints, SAM provides a way to share MCP tools without exposing patient data pathways to the public internet. For a defense contractor with agents on air-gapped laptops and cloud-based analytics pipelines, the zero-trust overlay and offline authorization model align with existing security postures.
Applications and use cases
The documented use cases include cross-cloud MCP tool sharing, hybrid on-premises to cloud agent calls, brokered inference endpoints via OpenRouter integration, sandboxed agents with credential injection, and pooled warm workers that sit ready to handle requests from multiple callers. The gateway pattern — where a sandboxed agent makes outbound calls through sam-boxcodecodecodecodecodecode — is particularly interesting for security-conscious deployments. The agent inside the sandbox never sees the API key; sam-boxcodecodecodecodecodecode verifies the Biscuit token, injects the real credential from a secrets store, and upgrades plain HTTP to HTTPS before forwarding the request upstream.
The gateway pattern: how sandboxed agents get credentials without seeing them
One of SAM’s more practical designs is its outbound gateway for sandboxed agents. An agent running inside a sandbox — a container, a Firecracker microVM, or similar — needs to call external APIs but should not have access to the API keys themselves. The gateway pattern solves this with a four-step flow.
The sandboxed agent makes an HTTP request through a proxy configured via HTTP_PROXYcodecodecodecodecodecode. The sandbox’s init process (nano-initcodecodecodecodecodecode) forwards the raw bytes over a Unix domain socket to sam-boxcodecodecodecodecodecode, a gateway node that lives outside the sandbox. sam-boxcodecodecodecodecodecode verifies the agent’s Biscuit token against its local policy. If the token is valid and the requested destination is mapped in secrets.yamlcodecodecodecodecodecode, sam-boxcodecodecodecodecodecode injects the real credential — a Bearer token, an API key, or a custom header — and upgrades the connection to HTTPS before sending it to the upstream service. The agent never sees the credential. If the destination is not mapped, the request is forwarded without credentials, which typically results in a 401 or 403 from the upstream.
This pattern has practical value for any organization running untrusted agent code. The agent can be compromised without leaking API keys. The credential store lives outside the sandbox boundary, and the gateway enforces which destinations each agent is allowed to reach.
Self-hosting vs. the public testnet: what the docs recommend
SAM’s documentation is clear about the distinction between the public testnet and a production deployment. The public mesh at bananas.sam-mesh.devcodecodecodecodecodecode is suitable for evaluation, prototyping, and non-sensitive workloads. For anything that touches real data or production systems, the docs recommend deploying your own control plane.
Self-hosting gives the operator full control over identity provider integration, token expiration policies, service catalogs, and audit logging. It also means the operator controls the root keys that sign Biscuit tokens — no third party can mint valid identities for your mesh. The Helm chart and Kubernetes deployment guide make self-hosting straightforward for teams already running Kubernetes, and the Go binaries work on bare metal, VMs, and edge devices.
What SAM does not do — and why that is intentional
SAM is not a general-purpose service mesh in the style of Istio or Linkerd. It does not handle HTTP routing, load balancing, circuit breaking, or observability for web services. It is scoped to agent-to-agent tool sharing over MCP, which is a narrower — and in some ways deeper — problem.
The project also does not provide a built-in agent runtime. SAM handles the networking and authorization layer; what runs inside the agent is entirely up to the developer. An agent could be a Python script using the MCP SDK, a Go binary, a LangChain agent, or a custom application. SAM provides the transport and authorization; the agent provides the logic and tools.
The decision to focus narrowly on MCP-based tool sharing rather than general-purpose service mesh functionality reflects a clear design philosophy: solve one problem well rather than build another undifferentiated platform. For teams that need general service mesh capabilities, SAM can run alongside Istio or Linkerd — it handles the agent-specific authorization and discovery that those meshes do not address.
Competitive landscape and strategic positioning
SAM enters a space that has seen a flurry of activity in the past eighteen months. Several startups and open-source projects have released agent-to-agent communication protocols, tool-sharing frameworks, and agent registries. What distinguishes SAM is its combination of zero-trust networking, offline authorization via Biscuit tokens, and pragmatic support for heterogeneous environments — cloud, datacenter, laptop, Raspberry Pi, Android.
The choice of Apache-2.0 licensing matters. Organizations that are wary of viral licenses or restrictive terms can adopt SAM without legal friction. The explicit disclaimer that this is not an officially supported Google product cuts both ways: it means the project could evolve rapidly without corporate process overhead, but it also means enterprises cannot buy support from Google. The community and the source code are the support structure.
Google’s decision to release SAM under these terms suggests a strategic bet on MCP as an emergent standard for agent tool sharing. If MCP becomes the default protocol for agent interoperability — similar to how HTTP became the default for web services — then SAM’s early, production-quality implementation of a zero-trust MCP transport network positions Google’s ecosystem favorably. Organizations that adopt SAM today are investing in a networking layer that aligns with a protocol that has growing industry momentum.
Technical requirements and operational considerations
Running SAM requires minimal infrastructure. A control plane needs a Go runtime or a Docker host, a database for identity state, and integration with an OIDC provider. Routers need stable network addresses that nodes can reach for initial bootstrap. Nodes need outbound access to the routers on UDP 5001 and TCP 5002, plus the ability to accept inbound connections if they want to be reachable without relay.
For organizations already using Kubernetes, the Helm chart and production deployment guide provide a clear path to deployment. The docs recommend running the control plane with a replicated database and at least two routers for redundancy. Nodes do not require persistent storage beyond their identity directory, and they can be ephemeral — a node’s identity persists across restarts as long as the data directory survives.
The Biscuit token model introduces its own operational considerations. Tokens have expiration dates, and nodes with expired tokens cannot authorize requests. Organizations need a process for token renewal — typically handled by having nodes re-authenticate with the control plane before their tokens expire. The control plane can also revoke tokens by adding their identifiers to a revocation cache that nodes periodically sync.
Security model: what gets protected and what does not
SAM’s security model protects the agent-to-agent communication channel and enforces authorization at the tool level. It does not protect against compromised control planes, stolen Biscuit keys, or malicious node operators who control their own hardware. The zero-trust assumption applies to the network, not to the administrative domain.
The offline authorization model means that a node operator can make local allow decisions, but they cannot escalate beyond what the control plane’s facts permit. A node operator could deny a tool that the control plane allows (local attenuation), but they could not grant access to a tool that the control plane has not authorized. This asymmetry is deliberate: local operators have the power to protect their own resources but not to compromise others’.
The replay protection — requiring the connection peer ID to match the token’s embedded peer ID — prevents a common class of token theft attacks. A stolen Biscuit token cannot be used from a different node. Combined with token expiration and revocation, the system provides defense in depth against credential compromise.
Practical evaluation: testing SAM without committing to production
For teams that want to evaluate SAM, the recommended path is to join the public testnet with a single node, expose a simple MCP tool, and verify that a second node can discover and call it. The entire flow — install, join, run, call — takes minutes rather than hours. The documentation at sam-mesh.dev includes examples for Python and Go agents, plus configuration files for the control plane and routers.
The testnet is a genuine mesh: nodes that join can discover and call other nodes that have chosen to expose services. This makes it useful for prototyping and for understanding the developer experience, but teams should treat it as an untrusted network for evaluation purposes only. No sensitive tools or data should be exposed on the testnet.
After evaluation, the step to self-hosting involves deploying the control plane behind your own OIDC provider, configuring your organization’s service catalogs and policies, and migrating nodes from the testnet to your own mesh. The tooling supports this transition — nodes can be configured with a different control plane endpoint at any time.
The trajectory of agent infrastructure and where SAM fits
SAM arrives at a moment when agent infrastructure is fragmenting. Every major cloud provider, several startups, and numerous open-source projects are building agent frameworks, communication protocols, and coordination layers. The risk is that the ecosystem fragments into incompatible islands, with agents that can only talk to other agents running the same framework.
MCP, the protocol that SAM transports, represents an attempt to define a standard interface for agent tools. If that standard gains broad adoption, SAM becomes a networking layer that any MCP-compatible agent can use regardless of framework. An agent written in Python with the MCP SDK, a LangChain agent, and a custom Go agent could all coexist on the same mesh, sharing tools and calling each other’s capabilities, without any of them knowing or caring what framework the others use.
That vision is not yet realized — MCP adoption is growing but not universal, and SAM itself is early in its lifecycle — but the architectural choices are sound. The separation of identity, transport, and authorization into discrete layers gives SAM the flexibility to evolve as the agent ecosystem matures. Organizations that invest in understanding the model today will be well positioned to deploy agent-to-agent networking at scale as the technology stabilizes.
The release of SAM as an Apache-2.0 open-source project, with clear documentation and a working testnet, lowers the barrier for engineering teams to experiment with agent mesh networking. Whether SAM becomes the standard substrate for agent communication or a reference that inspires better solutions, the problems it addresses — cross-network tool sharing, offline authorization, credential injection for sandboxed agents — are not going away. They are the infrastructure challenges of a world where autonomous agents run everywhere, and they need a networking layer that treats no network as trusted and no agent as privileged by default.
