Zum Inhalt springen
Federavia

Föderationsbroker für MCP und A2A

Eine Adresse für alle Agenten und Werkzeuge Ihrer Partner.

Partner veröffentlichen ihre MCP-Server und A2A-Agenten als Connectors. Ihre Clients fragen einmal Federavia und erhalten die Vereinigung all dessen, wofür ihnen Zugriff gewährt wurde. Ohne bilaterale Integrationen, ohne langlebige Partner-Geheimnisse, auf Ihrer eigenen Infrastruktur.

POST /mcp · tools/list Ein Aufruf
  • weather-api__get_forecast Partner Nord
  • erp-core__lookup_invoice Partner Süd
  • claims-bot__submit_claim Partner West

Stabile, qualifizierte Namen nach dem Muster connector__werkzeug. Der Client kennt nur diese eine Adresse; welche Partner dahinterstehen, ändert seinen Code nicht.

Das Problem

Jede neue Partnerschaft kostet nicht eine Integration, sondern alle bisherigen mit.

Bilateral verbunden wachsen die Strecken zwischen N Clients und M Upstreams als Produkt — mit je eigener Authentifizierung, eigenem Katalog und eigenem Betrieb. Ein Broker ersetzt dieses Produkt durch eine Summe.

Bilateral

N × M
Vier Clients links, jeder einzeln mit vier Upstreams rechts verbunden: sechzehn Strecken Client Client Client Client Upstream Upstream Upstream Upstream
  • Pro Strecke ein eigenes Credential, das jemand rotieren muss.
  • Jeder Client pflegt seinen eigenen Katalog fremder Werkzeuge.
  • Zugriff entziehen heißt: an jeder Stelle einzeln entziehen.

Über Federavia

N + M
Vier Clients links laufen auf einen zentralen Knoten zu, von dem vier Strecken zu den Upstreams rechts abgehen Client Client Client Client Connector Connector Connector Connector
  • Ein Endpunkt, ein Katalog, ein Satz Zugangsdaten je Client.
  • Neue Partner werden veröffentlicht, nicht integriert.
  • Zugriff entziehen heißt: einen Grant widerrufen.

Architektur

Was zwischen Aufruf und Upstream tatsächlich passiert.

Federavia ist kein Reverse Proxy mit Allowlist. Jeder föderierte Aufruf durchläuft dieselben drei Stufen: Wer ruft, darf er das, und mit welchem Token geht es weiter.

Föderationstopologie von Federavia Links drei Clients verschiedener Partner. Ihre Anfragen laufen auf eine einzige Adresse zu und durchlaufen in Federavia drei Stufen: Authentifizierung und Grant-Prüfung, Katalog-Aggregation mit Namespacing sowie Token-Exchange nach RFC 8693. Rechts gehen davon je ein eigens ausgestellter, auf genau einen Connector begrenzter Token an zwei MCP-Server und zwei A2A-Agenten der Partner. Unten schreibt Federavia jeden Aufruf in ein Audit-Log, ohne Payloads. CLIENTS FEDERAVIA · SELBST GEHOSTET CONNECTORS DER PARTNER Agenten-Runtime IDE-Client Backend-Dienst Partner A Partner B Partner C POST /mcp POST /a2a/{connector} 01 02 03 Authentifizierung & Grant-Prüfung Katalog-Aggregation & Namespacing Token Exchange · RFC 8693 Aufrufenden Partner feststellen. Ohne Grant auf diesen Connector endet der Aufruf hier. Fan-out über alle Grants, Namen qualifizieren, Ergebnisse zu einem Katalog zusammenführen. Eingehendes Token gegen ein frisches tauschen, begrenzt auf genau einen Connector, kurzlebig. Der Endnutzer bleibt im Subject erhalten. weather-api erp-core claims-bot doc-review MCP-Server · Partner Nord MCP-Server · Partner Süd A2A-Agent · Partner West A2A-Agent · Partner Ost aud: weather-api aud: erp-core aud: claims-bot aud: doc-review Audit-Log Wer, welcher Connector, welches Ergebnis — bewusst ohne Payloads.
Der Datenpfad ist der einzige Ort, an dem ein Upstream aufgelöst wird — und er löst ausschließlich auf, wofür ein gültiger Grant besteht.

Ablauf

Drei Schritte von der Veröffentlichung bis zum ersten Aufruf.

  1. 01

    Connector veröffentlichen

    Ein Partner meldet seinen MCP-Server oder A2A-Agenten mit Slug, Endpunkt und Datenpfad an. Der Slug wird zum Namensraum, unter dem seine Werkzeuge in jedem Katalog erscheinen.

  2. 02

    Zugriff anfragen

    Ein anderer Partner beantragt in der Konsole Zugriff auf genau diesen Connector. Bis dahin ist er für ihn nicht existent: weder im Katalog noch im Datenpfad.

  3. 03

    Grant genehmigen

    Der besitzende Partner genehmigt — und der Connector erscheint ab dem nächsten tools/list im Katalog des Anfragenden. Ein Widerruf wirkt genauso unmittelbar.

Vertrauen

Ein Broker in der Mitte muss weniger wert sein als das, was er vermittelt.

Federavia hält bewusst nichts vor, was einen Angreifer belohnen würde: keine Partner-Zugangsdaten, keine Nutzdaten, keine stehenden Berechtigungen.

Ohne Grant ist nichts erreichbar

Zugriff gilt für genau einen Partner auf genau einen Connector. Er wird angefragt, genehmigt und ist jederzeit widerrufbar. Der Genehmigungsweg liegt in der Konsole, nicht in einer Konfigurationsdatei.

Keine langlebigen Partner-Geheimnisse

Als Security Token Service nach RFC 8693 stellt Federavia pro Aufruf ein frisches, auf einen einzigen Connector begrenztes Token aus. Ein kompromittierter Broker liefert damit keinen stehenden Zugang zu irgendeinem Upstream.

Der Endnutzer bleibt sichtbar

Jedes ausgestellte Upstream-Token benennt weiterhin den ursprünglichen Endnutzer. Partner setzen ihre eigene Richtlinie pro Nutzer also unverändert durch — sie sehen keinen anonymen Sammelzugriff.

Vollständiger Audit-Trail

Jeder föderierte Aufruf wird aufgezeichnet: wer aufgerufen hat, welchen Connector, mit welchem Ergebnis. Bewusst ohne Payloads — Federavia wird nie zur Kopie der Daten eines Partners.

Was Federavia nicht tut

  • Es speichert keine Nutzdaten: weder Messages noch Artifacts oder Verläufe.
  • Es verwahrt keine Partner-Zugangsdaten in einem Vault, den man stehlen könnte.
  • Es ist kein Modell-Anbieter und keine Agenten-Laufzeit — es vermittelt nur.
  • Es ist kein gehosteter Dienst: der Betrieb bleibt vollständig bei Ihnen.

Standards

Offene Protokolle statt einer weiteren proprietären Schicht.

Was Federavia spricht, sprechen Ihre Clients und die Systeme Ihrer Partner ohnehin. Ein Wechsel weg von Federavia lässt die Endpunkte der Partner unverändert.

MCP 2026-07-28
Zustandsloses Request/Response über Streamable HTTP. Jede Instanz bedient jeden Aufruf, ohne geteilten Zustand.
A2A 1.0.1
Langlaufende Tasks mit Polling, Cancel und Webhooks. Gehalten wird nur die Task-Bindung, nicht ihr Inhalt.
Agentic AI Foundation
Beide Protokolle stehen unter dem Dach der Linux Foundation — herstellerneutral weiterentwickelt.
RFC 8693
OAuth 2.0 Token Exchange als Grundlage für kurzlebige, je Connector begrenzte Upstream-Tokens.
OIDC & Rollen
Single Sign-on je Organisation, dazu feingranulare Rollen für Konsole und Genehmigungswege.
Betrieb
Docker Compose und PostgreSQL, Telemetrie über OpenTelemetry, Metriken für Prometheus.

Auf Ihrer Infrastruktur, ab heute.

Federavia läuft dort, wo Ihre Föderation ohnehin endet: in Ihrem eigenen Netz. Melden Sie sich an der Konsole an, veröffentlichen Sie den ersten Connector und genehmigen Sie den ersten Grant.