ToolMesh — die fehlende Kontrollschicht für KI-Agenten

07.04.2026

Dunkel Cloud

KI-Agenten erreichen Produktivsysteme schneller, als Security und Governance hinterherkommen. Teams verbinden Agenten mit CRMs, Cloud-APIs, internen Datenbanken, Ticketsystemen und IoT-Geräten — aber die Infrastruktur zwischen Agent und Zielsystem hält sich nur mit Umgebungsvariablen und guten Vorsätzen zusammen.

Das typische Setup sieht so aus: Ein MCP-Server hat direkten Zugriff auf API-Keys, jeder angebundene Agent erhält vollen Zugriff auf jedes Tool, und es existiert keinerlei Aufzeichnung darüber, was wann und von wem aufgerufen wurde. Für einen Prototyp reicht das. Für einen Agenten, der in derselben Session mit Stripe, dem HR-System und dem Cloud-Provider spricht, reicht es nicht.

Im Unternehmenskontext verstärkt sich das Problem. Organisationen betreiben Dutzende Backend-Systeme über Teams und Abteilungen hinweg. Jedes braucht seine eigene Integration, seine eigenen Credentials, seine eigene Access-Policy. Ohne zentrale Kontrollschicht ist jede neue Agenten-Anbindung eine neue, unauditierte Vertrauensbeziehung — und die Angriffsfläche wächst mit jeder einzelnen.

ToolMesh ist unsere Antwort auf diese Lücke.

Was ToolMesh ist

ToolMesh ist die fehlende Kontrollschicht zwischen KI-Agenten und Unternehmenssystemen. Es sitzt zwischen KI-Agenten und Backend-Systemen und verwandelt unkontrollierte Tool-Calls in einen gesteuerten, auditierbaren Prozess — und bindet jede REST-API oder jeden MCP-Server in Minuten statt Monaten an.

Jeder Tool-Call durchläuft eine strikte Pipeline: Auth → AuthZ → Credential Injection → Execution → Output Gate → Audit. Wenn ein Schritt den Request nicht explizit zulässt, passiert nichts. Das Modell sieht niemals rohe Secrets. Jeder Call wird protokolliert. Outputs können gefiltert werden, bevor sie den Agenten erreichen.

Es läuft als einzelnes Binary oder Docker-Container. Es ist Apache-2.0-lizenziert. Es gibt keine SaaS-Abhängigkeit.

Die sechs Säulen

ToolMesh ist um sechs Belange herum aufgebaut, die die meisten Agenten-Setups inkonsistent oder gar nicht behandeln.

1. Authentication

ToolMesh unterstützt OAuth 2.1 mit PKCE für interaktive Clients wie Claude Desktop, API-Keys für programmatischen Zugriff und Multi-User-Setups über eine users.yaml-Konfiguration. Jeder Request wird authentifiziert, bevor er in die Pipeline eintritt.

Für einen schnellen Start genügt eine einzige Umgebungsvariable. Für die Produktion erhält man User-Identitäten mit Rollen, Plänen und Company-Kontext — ohne die Architektur zu ändern.

2. Authorization

Zugriffskontrolle erfolgt pro Tool und pro User, betrieben von OpenFGA. DADL-Tools deklarieren ein access-Level — read, write, admin oder dangerous — und Policy-Dateien bilden diese Levels auf Rollen ab. Ist der Aufrufer für das konkrete Tool nicht autorisiert, wird der Request vor der Ausführung abgelehnt.

ToolMesh verfolgt zusätzlich die CallerClass: welcher KI-Client den Request ausgelöst hat. Eine lokale Claude-Code-Session kann andere Berechtigungen haben als ein gehosteter Agent oder ein CI-Bot, die dieselbe API ansprechen. Gleiches Backend, unterschiedliche Vertrauensstufen, automatisch durchgesetzt.

3. Credential Store

Das ist der Aspekt, den die meisten Setups stillschweigend ignorieren. In einer typischen MCP-Konfiguration liegen API-Keys in Client-Configs oder Umgebungsvariablen — für das Modell sichtbar, über Maschinen verstreut, zentral nicht rotierbar.

ToolMesh injiziert Credentials zur Laufzeit, serverseitig. Das Modell sieht das Tool-Interface und das gefilterte Ergebnis. Es sieht nie das Token, den Key oder das Session-Cookie. Credentials werden in der DADL-Datei per Name referenziert und zur Ausführungszeit aus dem Credential Store aufgelöst.

Der Default-Store liest aus Umgebungsvariablen. Die Architektur unterstützt austauschbare Backends für zentralisiertes Secret-Management (geplant: Infisical, HashiCorp Vault).

4. Output Gate

Nicht jede API-Antwort sollte das Modell unverändert erreichen. Kundendatensätze können PII enthalten. Interne Systeme können Metadaten zurückgeben, die irrelevant oder sensibel sind. Fehlermeldungen können Infrastrukturdetails preisgeben.

Das Output Gate führt JavaScript-Policies aus (über die goja-Engine), die Inputs vor der Ausführung validieren und Outputs anschließend filtern können. Anwendungsfälle reichen von PII-Redaktion über Compliance-Filterung bis hin zur kompletten Ablehnung gefährlicher Inputs. Policies sind überprüfbarer Code, keine Black Boxes.

5. Execution

ToolMesh verbindet zwei Arten von Backends:

DADL-Backends beschreiben REST-APIs deklarativ in YAML. Eine .dadl-Datei definiert Endpoints, Parameter, Authentifizierung, Error-Handling, Pagination und Retry-Logik. ToolMesh verwandelt diese Beschreibung zur Laufzeit in MCP-Tools — kein eigener Server-Code nötig. Die öffentliche DADL-Registry enthält derzeit Definitionen für 24 APIs mit 3.115 Tools für Provider wie GitHub, Cloudflare, GitLab, Stripe, DeepL, Hetzner Cloud und andere.

MCP-Server-Backends binden bestehende MCP-Server über HTTP- oder STDIO-Transport an. Wer bereits einen funktionierenden MCP-Server hat, lässt ihn von ToolMesh in dieselbe Authorization-, Credential- und Audit-Pipeline einhüllen.

Beide Typen durchlaufen dieselbe Fail-closed-Pipeline. Der Backend-Typ ist ein Implementierungsdetail — die Sicherheitsgarantien sind dieselben.

6. Audit Trail

Jeder Tool-Call wird aufgezeichnet: wer ihn aufgerufen hat, welches Tool, mit welchen Parametern, was das Ergebnis war, wie lange er gedauert hat und ob er erfolgreich war. ToolMesh bringt zwei Audit-Backends mit — strukturiertes Logging über slog für einfache Setups und einen append-only SQLite-Store für abfragbare Compliance-Audits.

Wenn jemand fragt „Was hat dieser Agent letzten Dienstag eigentlich gemacht?”, lässt sich das mit einer SQL-Query beantworten statt mit einem Schulterzucken.

DADL: deklarieren statt programmieren

Das Integrationsproblem im Agenten-Tooling ist nicht das Protokoll. Das hat MCP gelöst. Das Problem ist, dass jede neue API immer noch einen neuen MCP-Server erfordert — eine neue Codebasis, eine neue Runtime, eine neue Wartungslast. Die meisten Teams stoppen nach einer Handvoll Integrationen, weil die Kosten pro API zu hoch sind.

DADL (Declarative API Description Language) verfolgt einen anderen Ansatz. Statt für jede API einen eigenen Server zu schreiben, beschreibt man die API in YAML:

backend:
  name: deepl
  type: rest
  base_url: https://api.deepl.com/v2

  auth:
    type: bearer
    credential: deepl_auth_key

  tools:
    translate:
      method: POST
      path: /translate
      access: write
      description: "Translate text into a target language"
      params:
        text: { type: array, in: body, required: true }
        target_lang: { type: string, in: body, required: true }

Das ist eine vollständige Tool-Definition. ToolMesh übernimmt zur Laufzeit Authentifizierung, Parameter-Mapping, Error-Handling, Retries und Credential-Injection.

Weil DADL kompakt und deklarativ ist, können LLMs aus bestehender API-Dokumentation funktionierende Definitionen generieren. Die meisten der frühen Definitionen in der Registry wurden von Claude in unter einer Minute aus API-Docs erzeugt und anschließend reviewt und nachjustiert. Das Format ist AI-nativ gedacht: leicht für Maschinen zu produzieren, leicht für Menschen zu reviewen.

Dazu haben wir einen eigenen Deep Dive geschrieben: Stop Rebuilding REST API Wrappers for MCP.

Code Mode: Skalierung, die sonst nicht funktioniert

15 MCP-Server mit einem einzigen KI-Agenten verbinden? Ohne ToolMesh funktioniert das schlicht nicht — das Kontextfenster läuft voll, der Client streikt. Mit ToolMesh ist es kein Problem.

Statt Hunderte einzelner MCP-Tools zu exponieren, exponiert ToolMesh zwei Meta-Tools: list_tools und execute_code. Das Modell erhält eine kompakte TypeScript-Interface-Beschreibung (~1.000 Tokens statt 50.000+) und schreibt JavaScript dagegen. Ein einzelner Codeblock kann mehrere API-Calls in einem einzigen Roundtrip verketten.

Das ist der Unterschied zwischen „funktioniert nicht” und „läuft einfach”.

Self-hosted, Open Source

ToolMesh ist Apache-2.0-lizenziert. Das Binary ist self-contained — keine externen Abhängigkeiten für den Core-Funktionsumfang. docker compose up liefert eine laufende Instanz mit OAuth, Audit-Logging und einer Auswahl an DADL-Backends.

Es gibt keine Cloud-Abhängigkeit. Deine Credentials, deine Audit-Logs, deine Policies — alles auf eigener Infrastruktur. Der Core ist Open Source und bleibt es.

Loslegen

Der schnellste Weg von null zu einem funktionierenden Setup:

Repo klonen und docker compose up ausführen
MCP-Client so konfigurieren, dass er auf ToolMesh zeigt
Den ersten Tool-Call absetzen

Der Getting-Started-Guide führt das im Detail durch. Die Architektur-Übersicht erklärt, wie die Pipeline arbeitet. Die DADL-Registry enthält gebrauchsfertige Definitionen für 24 APIs.

ToolMesh liegt auf GitHub. Issues, Feedback und DADL-Beiträge sind willkommen.