On 18 August 2026, a project appeared in Google’s GitHub organisation without a keynote, a launch video or a product name: SAM – Sovereign Agent Mesh. Not a model. Not a framework. Not another protocol for agent semantics. A network — specifically, a zero-trust overlay that lets AI agents share tools without anyone opening a port to the public internet.
That sounds unglamorous. It happens to target the exact point where most enterprise agent projects currently stall: not the model, not the prompt, but the question of how an agent running in the data centre reaches a tool running on a server in the plant — auditably, with authorisation, and without hand-built VPN plumbing.
One clarification up front, because the name causes confusion: this has nothing to do with “Segment Anything”, Meta’s image segmentation model. Google SAM is infrastructure.
What SAM Is — And What It Explicitly Is Not
SAM stands for Sovereign Agent Mesh and lives at github.com/google/sam under an Apache-2.0 licence, with documentation at sam-mesh.dev/docs.
Three facts shape how you should read it.
It is not a protocol; it is a transport and authorisation layer. The semantics — what a tool does, what parameters it takes, what it returns — stay with the Model Context Protocol (MCP). SAM carries MCP calls and decides who is allowed to make them. If MCP itself is still fuzzy for your team, start with our primer on the Model Context Protocol as the USB-C interface for LLMs.
It is not an official Google product. The repository carries an explicit disclaimer stating exactly that. There is no SLA, no support commitment, and no standards body behind it — unlike A2A, which now sits under the Linux Foundation. When you evaluate SAM today, you are evaluating an open source project, not a platform promise.
The public mesh is a test network. A public beta instance runs at bananas.sam-mesh.dev. For real workloads the documentation expects you to run your own control plane. That is not a footnote; it is the central decision if you take SAM seriously.
The Architecture: Three Binaries, One Clean Separation
SAM ships as three components, and the split itself is the most interesting part of the design.
sam-control-plane handles identity and policy. It registers nodes, maps external identities onto mesh identities, and issues tokens. This is where you exercise governance — and the reason self-hosting is not optional for production scenarios.
sam-router provides the data plane: bootstrap nodes and relays built on libp2p with a GossipSub overlay. Routers are what let nodes behind NAT and across mixed networks find and reach each other at all.
sam-node runs wherever your agent runs. It brings the P2P transport and exposes a local MCP HTTP interface at http://127.0.0.1:8080/mcp. Peer-to-peer traffic uses 5001/udp and 5002/tcp by default.
Operationally it stays short. sam-node join https://<your-control-plane> enrols the node — interactively via OIDC or headless with a bootstrap token. sam-node run then starts it. Unless the control plane runs with auto-approval, enrolment stays PENDING until an administrator approves it. A small detail with real consequences: the default is human approval, not automatic admission.
To the agent, all of this looks like an ordinary MCP server exposing three tools: discover_remote_services, find_remote_tools and call_remote_tool. Discover services on the mesh, search them for a matching tool, invoke it. Integration guides exist for Gemini and Claude Code, among others.
Zero Trust Here Means: Every Call, Authorised Offline
The authorisation model is the technically most interesting piece. SAM combines OIDC with Biscuit tokens and Datalog-based rules.
The flow: the control plane verifies an OIDC JWT and translates its claims into Datalog facts such as user(...), group(...) or client_peer_id(...). Those facts are sealed into a Biscuit token. The consequence matters — the receiving node authorises offline. It evaluates the presented token against its own local rules without calling home.
Enforcement is strictly default-deny: access requires an explicit capability fact such as granted_service_exact(...). Local rules can only attenuate, never widen — an operator can tighten policy but cannot bypass the constraints the control plane wrote into the token.
For a CTO the practical shift is this: authorisation moves from “we issued an API key once” to “every individual tool call is cryptographically checked”. Anyone who has cleaned up after a static token leaked into a repository knows the difference. The blast radius of a compromised credential shrinks from “everything that key could reach” to “whatever the policy in that token explicitly permits”.
Where It Sits: MCP, A2A, AP2
The agent standards landscape has sorted itself into layers over the past eighteen months:
- MCP gives an agent tools and context. It answers: what can I call?
- A2A (Agent2Agent) governs communication between agents across organisational and vendor boundaries. It answers: who am I talking to?
- AP2 (Agent Payments Protocol) governs agent-initiated payments. It answers: how does this settle?
None of them answers the question that hits an operations team first: how does the call physically get from A to B when A and B live in different networks — and who is permitted to make it?
That is SAM’s slot. It sits beneath MCP, not beside it. It replaces no protocol; it supplies transport, identity and policy for a protocol originally designed for local processes and later extended to HTTP endpoints. That someone is addressing this gap is the actual news, regardless of whether SAM or a different approach eventually prevails.
Why This Matters More to Established Enterprises Than to Start-ups
The project is candid about its fit: if everything you run lives inside a single VPC, a mesh buys you little. The value appears where the topology is heterogeneous.
Which is the default situation in most established European mid-market companies. ERP on premises. Microsoft 365 in the cloud. The industry-specific application hosted by a niche vendor. Machine data on the shop floor. The warehouse at a hyperscaler. The moment an agent has to work across that landscape, you have had two unsatisfying options: expose MCP servers through reverse proxies, or wire everything through VPN tunnels and firewall exceptions and absorb the operational cost.
The scale becomes obvious once you walk a realistic tool inventory — our CompanyGPT integrations overview lists well over a hundred systems that can be connected via MCP. Every single one is a transport and authorisation question the moment agents start using it.
SAM offers a third answer: a self-organising overlay that survives NAT and authorises each call individually. Conceptually closer to a private VPN than to an API gateway — except scoped to tool invocations rather than IP packets.
What Argues Against Production Use Today
The design is elegant. Production adoption in August 2026 still carries clear caveats, and it is worth naming them plainly.
No support commitment. The disclaimer in the repository is not boilerplate. Without an official product commitment, the operational risk sits entirely with you.
Operational expertise. libp2p, GossipSub, Biscuit tokens and Datalog policies are unfamiliar territory for most enterprise IT teams. Designing a Datalog policy model correctly is a discipline of its own — and mistakes there are security mistakes.
A network layer is not a data protection layer. SAM governs who may call what. It does not govern which personal data may flow, how long it is retained, or how you meet your accountability obligations. Controllership, records of processing, technical and organisational measures and your EU AI Act duties remain unchanged.
Cost and usage transparency lives elsewhere. A mesh tells you which tool call was authorised. It does not tell you what model spend an agent generated doing it. That question belongs on the LLM layer — in our case the AI Gateway, with cost centres and budgets per team, user and agent.
Conclusion: Watch the Project, But Make the Architecture Decision Now
The recommendation for IT decision-makers comes down to four steps, and none of them is “roll out SAM in production”.
One: inventory your MCP servers. Who operates them, where do they run, how are they reachable today, with which credentials? In most organisations we work with, that list is incomplete — and incompleteness there is exactly where shadow IT grows.
Two: separate protocol from transport in your target architecture. Write down explicitly which layer MCP owns and which layer owns reachability and authorisation. Get that separation right and you can swap the transport later — for SAM, for a service mesh, or for a gateway.
Three: pilot in a lab, not on the test network. If you evaluate SAM, do it with your own control plane and without production data. The public mesh is a beta instance and no place for company data.
Four: define your policy model before you pick technology. Which group may call which service with which tools? You have to answer that regardless — in Datalog, in a gateway, or in your identity provider. That is the real work; the technology is an implementation detail afterwards.
SAM is not the finished answer. It is a well-argued proposal for what the infrastructure beneath an agent landscape could look like, and it makes visible that the protocol layer alone is not enough. Organisations building an agent strategy right now should start accounting for that layer in their architecture.
Planning an agent rollout and want the architecture to hold up? In our AI strategy consulting we assess your system landscape, define the policy and operating model, and prioritise the use cases that actually move the needle. Get in touch.