Am 18. August 2026 ist im GitHub-Account von Google ein Projekt aufgetaucht, das keine Keynote und keinen Produktnamen bekommen hat: SAM – Sovereign Agent Mesh. Kein neues Modell, kein neues Framework, kein neues Protokoll für Agenten-Semantik. Sondern ein Netzwerk. Genauer: ein Zero-Trust-Overlay, über das KI-Agenten Werkzeuge austauschen, ohne dass irgendjemand einen Port ins Internet öffnen muss.
Das klingt unspektakulär. Es adressiert aber exakt die Stelle, an der die meisten Agenten-Projekte im Mittelstand gerade hängenbleiben: nicht am Modell, nicht am Prompt, sondern an der Frage, wie ein Agent im Rechenzentrum an ein Werkzeug kommt, das auf einem Server in der Fertigung läuft – auditierbar, autorisiert und ohne VPN-Bastelei.
Zur Klarstellung vorweg, weil die Namensgleichheit für Verwirrung sorgt: Es geht nicht um „Segment Anything", das Bildsegmentierungsmodell von Meta. Google SAM ist ein Infrastrukturprojekt und hat damit nichts zu tun.
Was SAM ist – und was es ausdrücklich nicht ist
SAM steht für Sovereign Agent Mesh und liegt unter github.com/google/sam offen unter Apache-2.0-Lizenz. Die Dokumentation findet sich unter sam-mesh.dev/docs.
Drei Punkte sind für die Einordnung entscheidend:
Erstens: SAM ist kein Protokoll, sondern eine Transport- und Autorisierungsschicht. Die Semantik – also was ein Werkzeug kann, welche Parameter es nimmt, was es zurückgibt – bleibt beim Model Context Protocol (MCP). SAM transportiert MCP-Aufrufe und entscheidet, wer sie ausführen darf. Wer MCP noch nicht eingeordnet hat, findet die Grundlagen in unserem Beitrag Model Context Protocol – die USB-C-Schnittstelle für LLMs.
Zweitens: SAM ist kein offizielles Google-Produkt. Das Repository trägt den ausdrücklichen Hinweis, dass es sich nicht um ein offiziell unterstütztes Google-Produkt handelt. Es gibt kein SLA, keine Support-Zusage und kein Standardisierungsgremium dahinter – anders als bei A2A, das inzwischen unter dem Dach der Linux Foundation liegt. Wer SAM heute bewertet, bewertet ein Open-Source-Projekt, nicht eine Plattform-Zusage.
Drittens: Das öffentliche Netz ist ein Testnetz. Unter bananas.sam-mesh.dev steht eine öffentliche Beta-Instanz bereit. Für reale Workloads sieht die Dokumentation vor, dass Sie eine eigene Control Plane betreiben. Das ist kein Detail, sondern die Kernentscheidung, wenn Sie SAM ernsthaft prüfen.
Die Architektur: drei Binaries, eine klare Trennung
SAM besteht aus drei Komponenten, und diese Aufteilung ist der eigentlich interessante Teil des Designs:
sam-control-plane verwaltet Identitäten und Policies. Sie meldet Knoten an, bildet externe Identitäten auf Mesh-Identitäten ab und stellt Token aus. Sie ist der Ort, an dem Sie Governance ausüben – und der Grund, warum Self-Hosting für produktive Szenarien nicht optional ist.
sam-router stellt die Datenebene bereit: Bootstrap-Knoten und Relays auf Basis von libp2p mit GossipSub-Overlay. Die Router sorgen dafür, dass sich Knoten hinter NAT und in heterogenen Netzen überhaupt finden und erreichen.
sam-node läuft dort, wo der Agent läuft. Der Knoten bringt den P2P-Transport mit und stellt lokal eine MCP-HTTP-Schnittstelle unter http://127.0.0.1:8080/mcp bereit. Für den P2P-Verkehr nutzt er standardmäßig 5001/udp und 5002/tcp.
Der Ablauf in der Praxis ist bewusst kurz gehalten: sam-node join https://<ihre-control-plane> meldet den Knoten an – interaktiv über OIDC oder headless per Bootstrap-Token. Anschließend startet sam-node run den Knoten. Läuft die Control Plane nicht mit automatischer Freigabe, bleibt die Anmeldung im Zustand PENDING, bis ein Administrator sie bestätigt. Ein kleines Detail mit großer Wirkung: Der Default ist eine menschliche Freigabe, nicht ein automatischer Beitritt.
Für den Agenten selbst sieht das Ganze wie ein ganz normaler MCP-Server aus. Er bekommt drei Werkzeuge: discover_remote_services, find_remote_tools und call_remote_tool. Damit findet er Dienste im Mesh, sucht dort nach passenden Tools und ruft sie auf. Integrationsanleitungen liegen unter anderem für Gemini und Claude Code vor.
Zero Trust bedeutet hier: jede Anfrage einzeln, ohne Rückfrage
Der technisch spannendste Teil ist das Autorisierungsmodell. SAM kombiniert OIDC mit Biscuit-Token und Datalog-basierten Regeln.
Der Ablauf: Die Control Plane prüft ein OIDC-JWT und übersetzt dessen Claims in Datalog-Fakten – etwa user(...), group(...) oder client_peer_id(...). Diese Fakten werden in ein Biscuit-Token versiegelt. Der entscheidende Effekt: Der aufgerufene Knoten autorisiert offline. Er wertet das vorgelegte Token gegen seine eigenen lokalen Regeln aus, ohne bei der Control Plane nachzufragen.
Die Durchsetzung ist strikt default-deny: Zugriff braucht eine explizite Berechtigungsaussage wie granted_service_exact(...). Und lokale Regeln können nur einschränken, nicht erweitern – ein Betreiber kann seine Policy verschärfen, aber die Bedingungen der Control Plane nicht umgehen.
Für IT-Entscheider ist daran vor allem eines relevant: Das Modell verschiebt die Autorisierung von „einmalig ein API-Key ausgestellt" auf „jeder einzelne Tool-Aufruf wird kryptografisch geprüft". Wer schon einmal aufgeräumt hat, nachdem ein statisches Token in einem Repository gelandet ist, weiß, warum das ein Unterschied ist. Der Radius eines kompromittierten Credentials schrumpft von „alles, was der Key konnte" auf „das, was die Policy im Token explizit erlaubt".
Einordnung: MCP, A2A, AP2 – und wo SAM dazwischen sitzt
Die Standardlandschaft rund um Agenten hat sich in den letzten anderthalb Jahren in Schichten sortiert:
- MCP gibt einem Agenten Werkzeuge und Kontext. Es beantwortet die Frage: Was kann ich aufrufen?
- A2A (Agent2Agent) regelt die Kommunikation zwischen Agenten über Organisations- und Herstellergrenzen hinweg. Es beantwortet: Mit wem rede ich?
- AP2 (Agent Payments Protocol) regelt agentengetriebene Zahlungen. Es beantwortet: Wie wird abgerechnet?
Keine dieser Schichten beantwortet jedoch die Frage, die im Betrieb zuerst auf den Tisch kommt: Wie kommt der Aufruf physisch von A nach B, wenn A und B in unterschiedlichen Netzen stehen – und wer darf das überhaupt?
Genau da setzt SAM an. Es ist eine Schicht unter MCP, nicht daneben. Es ersetzt kein Protokoll, sondern liefert Transport, Identität und Policy für ein Protokoll, das ursprünglich für lokale Prozesse und später für HTTP-Endpunkte gedacht war. Dass diese Lücke von jemandem adressiert wird, ist die eigentliche Nachricht – unabhängig davon, ob sich am Ende SAM oder ein anderer Ansatz durchsetzt.
Warum das für den DACH-Mittelstand relevanter ist als für Start-ups
Die Autoren des Projekts benennen die Zielgruppe selbst recht offen: Wer alles in einer einzigen VPC betreibt, gewinnt durch ein Mesh wenig. Der Nutzen entsteht dort, wo die Topologie heterogen ist.
Das ist die Normalsituation im deutschen Mittelstand: Das ERP läuft on-premises, Microsoft 365 in der Cloud, das Fachverfahren beim Branchenanbieter, die Maschinendaten im Werk, das Data Warehouse bei einem Hyperscaler. Sobald ein Agent quer über diese Landschaft arbeiten soll, hat man bisher zwei Optionen gehabt – beide unbefriedigend: MCP-Server über Reverse Proxies ins Internet stellen, oder alles über VPN-Tunnel und Firewall-Ausnahmen verdrahten und den Betriebsaufwand tragen.
Wie viele Systeme im Spiel sind, sehen Sie schnell, wenn Sie eine typische Werkzeuglandschaft durchgehen – unsere Übersicht der CompanyGPT-Integrationen listet über hundert Systeme, die per MCP angebunden werden können. Jedes einzelne davon ist im Agenten-Betrieb eine Transport- und Autorisierungsfrage.
SAM bietet für dieses Problem eine dritte Antwort: ein Overlay, das sich selbst organisiert, NAT übersteht und jeden Aufruf einzeln autorisiert. Konzeptionell näher an einem privaten VPN als an einem API-Gateway – nur eben auf Tool-Aufrufe zugeschnitten statt auf IP-Pakete.
Was heute gegen einen produktiven Einsatz spricht
Bei aller Eleganz des Designs: Für einen Produktiveinsatz im August 2026 gibt es klare Vorbehalte, und die sollten Sie nüchtern benennen.
Kein Support-Versprechen. Der Disclaimer im Repository ist nicht Formsache. Ohne offizielle Produktzusage tragen Sie das Betriebsrisiko vollständig selbst.
Betriebs-Know-how. libp2p, GossipSub, Biscuit-Token und Datalog-Policies sind für die meisten IT-Abteilungen im Mittelstand Neuland. Ein Policy-Modell in Datalog sauber zu entwerfen, ist eine eigene Disziplin – und Fehler dort sind Sicherheitsfehler.
Netzwerkschicht ist keine Datenschutzschicht. SAM regelt, wer aufrufen darf. Es regelt nicht, welche personenbezogenen Daten dabei fließen dürfen, wie lange sie gespeichert werden oder wie Sie Ihrer Rechenschaftspflicht nachkommen. Verantwortlichkeit, Verarbeitungsverzeichnis, technische und organisatorische Maßnahmen sowie die Pflichten aus dem EU AI Act bleiben unverändert Ihre Aufgabe.
Kosten- und Nutzungstransparenz fehlt auf dieser Ebene. Ein Mesh sagt Ihnen, wer welches Tool aufrufen durfte. Es sagt Ihnen nicht, welche Modellkosten ein Agent dabei verursacht hat. Diese Frage gehört auf die LLM-Ebene – bei uns in den AI Gateway mit Kostenstellen und Budgets pro Team, Nutzer und Agent.
Fazit: Beobachten, aber die Architekturentscheidung jetzt treffen
Die konkrete Handlungsempfehlung für IT-Entscheider besteht aus vier Schritten – und keiner davon lautet „SAM produktiv ausrollen".
Erstens: Inventarisieren Sie Ihre MCP-Server. Wer betreibt sie, wo laufen sie, wie sind sie heute erreichbar, mit welchen Credentials? In den meisten Unternehmen, die wir sehen, ist diese Liste unvollständig – und genau dort entsteht Schatten-IT.
Zweitens: Trennen Sie in Ihrer Zielarchitektur Protokoll von Transport. Notieren Sie explizit, welche Schicht MCP übernimmt und welche Schicht Erreichbarkeit und Autorisierung übernimmt. Wenn diese Trennung sauber ist, können Sie den Transport später austauschen – ob gegen SAM, gegen ein Service Mesh oder gegen eine Gateway-Lösung.
Drittens: Pilotieren Sie im Labor, nicht im Testnetz. Wenn Sie SAM evaluieren, dann mit eigener Control Plane und ohne produktive Daten. Das öffentliche Mesh ist eine Beta-Instanz und für Unternehmensdaten kein geeigneter Ort.
Viertens: Definieren Sie Ihr Policy-Modell, bevor Sie Technik auswählen. Welche Gruppe darf welchen Dienst mit welchen Werkzeugen aufrufen? Diese Frage müssen Sie ohnehin beantworten – ob in Datalog, in einem Gateway oder in Ihrem Identity Provider. Sie ist die eigentliche Arbeit; die Technologie ist danach eine Umsetzungsfrage.
SAM ist nicht die fertige Antwort. Aber es ist ein gut lesbarer Vorschlag dafür, wie die Infrastruktur unter einer Agenten-Landschaft aussehen könnte – und es macht sichtbar, dass die Protokollschicht allein nicht reicht. Unternehmen, die ihre Agenten-Strategie gerade aufsetzen, sollten diese Schicht ab sofort in ihrer Architektur mitdenken.
Sie planen den Einsatz von KI-Agenten und wollen die Architektur von Anfang an tragfähig aufsetzen? In unserer KI-Strategieberatung bewerten wir Ihre Systemlandschaft, definieren das Policy- und Betriebsmodell und priorisieren die Use Cases, die tatsächlich Wirkung entfalten. Sprechen Sie uns an.