Google SAM heißt jetzt Agent Mesh: MCP-Tools vernetzen

Google SAM heißt jetzt Agent Mesh

Sovereign Agent Mesh (SAM), inzwischen Agent Mesh genannt, ist eine quelloffene Netzwerkschicht für KI-Agenten. Über einen lokalen Knoten kann ein Agent freigegebene Tools auf anderen Rechnern finden und aufrufen. Das Repository ist von google/sam nach google/agentmesh umgezogen. Die aktuelle README bestätigt die Umbenennung und den Projektstatus: Apache-2.0-Lizenz, noch vor Version 1.0 und kein offiziell unterstütztes Google-Produkt.

Eine typische Situation: Dein Coding-Assistent läuft auf einem Laptop, ein Review-Agent neben dem Build-Server und ein internes Suchtool in einem privaten Cluster. Alle können nützliche Aufgaben übernehmen. Damit sie ihre Fähigkeiten gemeinsam nutzen können, brauchen sie erreichbare Endpunkte und klare Regeln dafür, wer was aufrufen darf.

Agent Mesh stellt diese Verbindungen und die zugehörige Autorisierung bereit. Du lässt die Tools dort laufen, wo sie hingehören, und gibst ausgewählte Funktionen für registrierte Gegenstellen frei.

Versionshinweis, geprüft am 12. Oktober 2026: Dieser Artikel bezieht sich auf den Quellcode-Commit 273e6fba und dessen Namen mit agentmesh-*. Das zuletzt aufgeführte Release, v0.1.0-rc.9, veröffentlicht am 7. Oktober, verwendet noch Namen mit sam-*. Verwende bei der Evaluierung Befehle und Dokumentation derselben Version.

Ein lokaler Knoten macht entfernte Tools erreichbar

Ein Agent spricht mit agentmesh-node auf seinem eigenen Rechner. Dieser Knoten verbindet sich mit dem Mesh und prüft, welche entfernten Dienste er erreichen darf. Ein Provider-Knoten veröffentlicht nur die Backends, die sein Betreiber konfiguriert hat.

Die Control Plane nimmt Mitglieder auf und stellt Zugangstoken aus. Router helfen den Knoten, sich gegenseitig zu finden, und leiten verschlüsselten Datenverkehr weiter, wenn keine direkte Verbindung möglich ist. agentmesh-one bündelt Control Plane, Router und Konsole für kleinere Installationen. Die Architekturdokumentation beschreibt diese Zuständigkeiten.

Bei einem bestehenden Agentensystem hilft diese Aufteilung:

Unser Leitfaden zur Kommunikation zwischen Agenten und zu Band behandelt die übergreifende Koordination. SAM stellt das Netzwerk bereit, über das diese Interaktionen laufen.

Automatische Erkennung spart die laufende Pflege von Endpunkten

Nach dem Beitritt erfährt ein Knoten, welche Router verfügbar sind, und findet veröffentlichte Dienste über das verteilte Verzeichnis des Mesh. Verbindungen können direkt oder über ein verschlüsseltes Relay laufen. Der Netzwerkleitfaden erklärt Diensterkennung, Relays und die Wiederherstellung von Verbindungen.

Das kann dir die Pflege einer eigenen Adressliste für jeden Assistenten ersparen. Ein Dienst behält seinen Namen, wenn sein Provider das Netzwerk wechselt. Die Diensterkennung liefert mögliche Provider. Ob eine Anfrage zulässig ist, entscheiden anschließend die Verbindungsprüfung und die Prüfung der Zugangstoken.

Betreiber wählen weiterhin eine Control Plane, registrieren Mitglieder und vergeben Zugriffsrechte. Auch jedes veröffentlichte Backend muss konfiguriert werden. Die Bezeichnung „Zero Config“ blendet Entscheidungen aus, die festlegen, was deine Agenten erreichen können.

Der lokale Knoten stellt einen MCP-Endpunkt über Streamable HTTP bereit. Der Integrationsleitfaden für Clients enthält Beispiele für Claude Code, Google Antigravity und weitere MCP-Clients. Der zugehörige Skill erklärt einem Assistenten, wie er entfernte Tools findet, beschreibt und aufruft. Registrierung und MCP-Konfiguration bleiben separate Schritte.

Prüfe bei Codex oder Hermes zuerst die unterstützten MCP-Transporte und Authentifizierungseinstellungen, bevor du eine funktionierende Integration zusagst. Dieser Artikel liefert keine getestete Kompatibilitätsmatrix für diese Clients.

Die Identität bleibt beim Knoten, auch wenn das Netzwerk wechselt

Jeder Knoten erzeugt sein eigenes Ed25519-Schlüsselpaar. Seine Peer-ID wird aus dem öffentlichen Schlüssel abgeleitet. Ein OpenID-Connect-Login oder Bootstrap-Token registriert ihn bei einer Control Plane, die ein signiertes Biscuit-Token ausstellt. Dieses Token enthält die Identität und Berechtigungen, die andere Knoten prüfen können.

Das Zugangstoken ist an den Schlüssel des Knotens gebunden. Eine Kopie des Tokens allein verschafft keinen Zugriff auf diesen Schlüssel. Gegenstellen authentifizieren die Verbindung und prüfen, ob die Berechtigungen des Aufrufers den angefragten Dienst abdecken. Die Spezifikation zu Identität und Registrierung erläutert auch Ablauf und Erneuerung.

Du kannst damit den Zugriff auf einen benannten Dienst freigeben, ohne die Regel an die aktuelle IP-Adresse eines Laptops zu binden. Das Zugangstoken gehört weiterhin zu dem Mesh, das es ausgestellt hat. Einen Workload in eine andere Cloud zu verschieben und einer unabhängigen Control Plane beizutreten, sind zwei unterschiedliche Vorgänge.

Mit einem eigenen Mesh kontrollierst du Mitgliedschaft und Schlüssel

Mit einer eigenen Control Plane bestimmst du, welche Identitäten beitreten und welche Dienste sie nutzen dürfen. Deine Installation verfügt über eigene Signaturschlüssel für Zugangstoken und eigene administrative Richtlinien. Der Schutz ihrer Datenbank und Admin-Zugänge gehört zum Betrieb dieser Vertrauensgrenze.

Die Dokumentation zu Kontroll- und Datengrenzen beschreibt Self-Hosting auf privater Infrastruktur, einschließlich eines vom externen Netz getrennten Air-Gap-Netzwerks. In einer isolierten Installation müssen auch die benötigten Identitätsdienste, Tools und Modelle innerhalb dieser Umgebung verfügbar sein.

Tool-Anfragen laufen zwischen den Knoten. Die Control Plane verwaltet Mitgliedschaft und Richtlinien außerhalb dieses Datenpfads. Ein Relay transportiert verschlüsselten Datenverkehr und kann Verbindungsmetadaten beobachten.

Die gemeinsam genutzten öffentlichen Testnetze eignen sich für Experimente mit synthetischen Daten. Ihre Betreiber kontrollieren Mitgliedschaft und Richtlinien; die Verfügbarkeit ist nicht garantiert. Eine unternehmenseigene Grenze beginnt mit einer dedizierten Installation und geprüften Infrastrukturentscheidungen.

EU-Labels schränken die Auswahl der Provider ein

Agent Mesh kann verlangen, dass ein Provider ein signiertes Label wie jurisdiction=eu trägt. Ein Knoten gibt seine Labels bei der Registrierung an. Die Control Plane signiert nur diejenigen, die seine Rolle über allowed_labels erlaubt.

Auf einem Consumer-Knoten kann der Betreiber folgende Mindestanforderung festlegen:

version: "v1alpha1"
egress:
  require_labels:
    jurisdiction: eu

Die Referenz zur Knotenkonfiguration definiert diese Untergrenze. Ein Aufrufer kann zusätzliche Anforderungen an den Provider stellen, die Vorgabe des Betreibers aber nicht entfernen. Die Zugriffsprüfung kontrolliert die signierten Angaben im Zugangstoken, bevor sie eine Anfrage weiterleitet.

Die Signatur belegt, dass die zuständige Mesh-Instanz ein Label akzeptiert hat. Seine physische Bedeutung ergibt sich aus deinen Bereitstellungskontrollen. Auf einem Rechner mit EU-Label könnte weiterhin ein Backend laufen, das Prompts an eine externe Modell-API weiterleitet.

Prüfe den vollständigen Verarbeitungspfad: den tatsächlichen Standort des Providers, die Platzierung der Relays, nachgelagerte APIs, Logs und Backups. Auch reguläre ausgehende Verbindungen der Anwendung brauchen passende Kontrollen. Ein Label auf einem Mesh-Knoten kann all diese Tatsachen nicht belegen.

Unser Leitfaden zur EU-Datenresidenz von KI-Anwendungen behandelt diese umfassendere Grenze. Der konkrete Nutzen hier ist die durchsetzbare Auswahl unter Providern, deren Labels du unabhängig begründet hast.

Der Provider kann einen zentral erlaubten Aufruf ablehnen

Ein Rechner, auf dem ein sensibles Tool läuft, kann eigene Prüfungen vorgeben. Sein Betreiber kann etwa ein bestätigtes Label des Aufrufers verlangen oder einer Gruppe den Zugriff auf einen bestimmten Dienst verweigern. Eine fehlgeschlagene lokale Prüfung oder eine passende Verbotsregel kann den Zugriff blockieren, selbst wenn das Mesh ihn freigibt.

Die Autorisierungsspezifikation beschreibt diese lokale Durchsetzung. Sie unterstützt außerdem enger begrenzte Aufgabentoken für delegierte Arbeit.

Damit hat der Tool-Betreiber ein praktisch nutzbares Vetorecht. Anwendungsspezifische Entscheidungen bleiben bei dem Dienst, der die Daten kennt, etwa welche Kundendatensätze eine Abfrage zurückgeben darf. Unser Artikel zur Zugriffskontrolle auf Datenebene bei MCP erklärt diese nächste Ebene.

SAM mit zwei Knoten und einem Rechentool evaluieren

Starte mit einer Funktion, deren Eingaben und Ergebnis sich leicht prüfen lassen. Ein MCP-Server, der ausschließlich Additionen ausführt, ermöglicht einen nützlichen Test ohne Geschäftsdaten. Diese Anleitung ist aus der Dokumentation abgeleitet. Wavect hat diese Installation für den Artikel weder ausgeführt noch SAM einem Benchmark unterzogen.

Verwende eine dedizierte Test-Control-Plane und Binärdateien, die zum gewählten Quellcode-Stand oder Release passen. Die folgenden Befehlsnamen entsprechen dem untersuchten aktuellen Quellcode. Ersetze mesh.example.com durch die HTTPS-Adresse deiner eigenen Control Plane.

1. Einen bewusst kleinen Provider veröffentlichen

Starte auf Rechner A deinen Test-MCP-Server auf der Loopback-Adresse an Port 7779. Er muss Streamable HTTP unter /mcp anbieten. Speichere diese Konfiguration als provider.yaml:

version: "v1alpha1"
labels:
  jurisdiction: eu
services:
  - type: mcp
    name: calculator
    description: "Arithmetic tools"
    target_url: "http://127.0.0.1:7779/mcp"

Der Leitfaden zur Veröffentlichung von Diensten dokumentiert diesen Konfigurationsaufbau. Der Knoten prüft das Backend, bevor er es bekannt gibt. Erlaube der Registrierungsrolle des Providers das Label jurisdiction=eu, nachdem du geprüft hast, dass es auf diesen Provider zutrifft.

2. Provider und Consumer registrieren

Erstelle für beide Rechner separate Registrierungstoken. Bewahre das Token für A dort in einer lokalen Datei auf und führe Folgendes aus:

agentmesh-node join https://mesh.example.com \
  --bootstrap-token-path ./provider-join-token --config ./provider.yaml
agentmesh-node run --config ./provider.yaml

Speichere auf Rechner B das vorherige Beispiel mit egress.require_labels als consumer.yaml. Registriere und starte B mit dieser Datei und seinem eigenen Token. Der Aufrufer benötigt Zugriff auf mcp://calculator sowie die Diensterkennung über system://mesh.catalog. Beschränke seine Berechtigungen auf diese Übung.

3. Das Tool finden und sein Schema prüfen

Verbinde einen kompatiblen MCP-Client über den dokumentierten Endpunkt und die vorgesehene Authentifizierung mit dem lokalen Knoten von B. Rufe get_mesh_info auf, um die Verbindung zu prüfen, und anschließend discover_remote_services, um den Rechendienst zu finden. Prüfe das Tool des ausgewählten Providers mit find_remote_tools und describe_remote_tool.

Übergib die zurückgegebene Peer-ID, den Tool-Namen einschließlich Namensraum und Argumente gemäß dem Schema an call_remote_tool. Sende die synthetischen Werte 2 und 3 an das Additionstool und prüfe, ob es 5 zurückgibt. Halte fest, welcher Provider geantwortet hat. Tool- und Parameternamen müssen aus der Diensterkennung stammen. Die Referenz der Knoten-API beschreibt diese Schnittstellen zur Erkennung und zum Tool-Aufruf.

4. Die Ablehnungspfade prüfen

Wiederhole den Versuch mit einem Test-Provider, dem das erforderliche signierte Label fehlt. Prüfe, dass er keine Recheneingaben erhält. Ergänze danach eine lokale Verbotsregel beim Provider und prüfe, dass ein ansonsten erlaubter Aufruf abgelehnt wird. Trenne schließlich einen Knoten vom Netz und beobachte Diensterkennung und Wiederverbindung getrennt von möglichen Wiederholungsversuchen der Anwendung.

Dokumentiere erfolgreiche Aufrufe, Ablehnungen und das Wiederherstellungsverhalten in deiner Umgebung. Entscheide anhand dieser Ergebnisse, ob du als Nächstes ein privates Suchtool oder einen Review-Agenten evaluierst.

Reviewer-Pools ergänzen die Koordination oberhalb des Mesh

Das Beispiel eines Pools bereits gestarteter Agenten verteilt Code-Reviews auf schon laufende Worker. Jeder Worker stellt ein MCP-Review-Tool bereit. Ein Manager findet die Worker und vergibt sie zeitweise an einen Orchestrator, der mehrere Aufträge parallel verteilt.

Diese Aufteilung ist hilfreich. Das Mesh findet einen Worker und macht ihn erreichbar. Der Manager entscheidet, ob er verfügbar ist. Dein Workflow legt fest, was als akzeptables Review gilt.

Nach einer Netzwerkunterbrechung kann die Verbindungswiederherstellung die Gegenstellen erneut verbinden. Für den Abschluss einer Aufgabe braucht es weiterhin eigene Regeln. Geht eine Antwort verloren, nachdem ein Tool fertig ist, kann ein erneuter Aufruf den Vorgang wiederholen. Führe Auftrags-IDs und Abschlusszustände nach, bevor du Tools einbindest, die Dateien schreiben oder andere Aktionen auslösen. Die selbstheilenden Verbindungen des Mesh gewährleisten keine exakt einmalige Ausführung von Aufgaben.

Den Pilotversuch auf eine gemeinsam genutzte Funktion begrenzen

Agent Mesh lohnt eine Evaluierung, wenn nützliche Tools auf verschiedenen Rechnern laufen und mehrere Assistenten kontrollierten Zugriff darauf brauchen. Ein lokaler Knoten gibt jedem Client einen Einstiegspunkt. Der Betreiber legt fest, wer welchen Dienst erreichen darf.

Behalte die Isolation der Hosts und die Autorisierung innerhalb der Anwendung im Architekturentwurf bei. Die Sicherheitsarchitektur des Projekts beschreibt die Abgrenzung zu Sandboxing und externen Diensten.

Wenn dein Team bereits einen Laptop-Assistenten mit privater Build- oder Suchinfrastruktur verbindet, ist die erste Entscheidung konkret: Wähle ein Tool, zwei registrierte Knoten und eine Berechtigung, die du testen kannst. Erweitere den Umfang, sobald du zeigen kannst, welche Identität das Tool aufgerufen hat, welcher Provider die Eingabe erhielt und wie ein verbotener Aufruf gestoppt wurde.