Plattform
Die offene Plattform von SwiftXEO ermöglicht es externen KI-Assistenten und Ihren eigenen Systemen, sich mit einem kontrollierten Workspace zu verbinden – um freigegebene Vorgaben zu lesen und Arbeit vorzuschlagen, jedoch niemals um diese zu genehmigen.
Ein MCP-Server mit OAuth, eine REST-API auf Workspace-Ebene, signierte eingehende Webhooks und ein Gmail-Connector (Beta) bilden eine einheitliche Schnittstelle mit einem festen Prinzip: extern vorgeschlagen, intern kontrolliert.
Autonomie schlägt vor. Menschen autorisieren. Die Governance bleibt aktiv.
Warum das wichtig ist
Führungskräfte möchten, dass Assistenten wie Claude und ChatGPT mit realem Unternehmenskontext arbeiten – mit freigegebener Strategie, aktuellen Zielen und geprüften Erkenntnissen –, statt auf Basis eingefügter Textabschnitte zu raten. Was sie davon abhält, ist das Risiko, dass ein externes Tool unbemerkt zur Entscheidungsinstanz wird.
SwiftXEO löst diesen Zielkonflikt strukturell statt durch Richtliniendokumente. Verbundene Assistenten lesen dieselben freigegebenen Daten, mit denen Ihr Team arbeitet, und alles, was sie zurückschicken, landet in einer Prüfwarteschlange. Kontext fließt nach außen; Entscheidungsgewalt niemals.
Die Zugänge
Claude und ChatGPT verbinden sich über einen Standard-MCP-Connector mit OAuth-Anmeldung mit dem Workspace – die Verbindung mit Claude ist durchgehend verifiziert. Konfigurationsbasierte Clients wie Claude Code und Cursor verbinden sich über einen Workspace-API-Schlüssel.
Workspace-bezogene API-Schlüssel steuern eine versionierte REST-Schnittstelle: Lesen Sie freigegebene Business-DNA, Ziele, aktive Erkenntnisse und Historie; reichen Sie Nachweise und Vorschläge aus Ihren eigenen Systemen ein.
Signierter, verifizierter Push von externen Systemen. Jede Payload wird gegen ein quellspezifisches Secret geprüft und als Material für die menschliche Überprüfung gespeichert – niemals direkt ausgeführt, niemals bei Eingang blind vertraut.
Ein schreibgeschützter Beta-Connector, der neu eingehende E-Mails in überprüfbare Nachweise im Workspace umwandelt. Er versendet niemals E-Mails, und wie bei jeder externen Quelle wird nichts erfasst, was ohne Überprüfung zur Wahrheit wird.
Das Nur-Vorschlag-Prinzip
Jedes externe Element – der Vorschlag eines Agenten, eine Webhook-Payload, eine E-Mail – gelangt als nicht vertrauenswürdiger Kontext in den Workspace. Es kann von Prüfern gelesen, nach der Überprüfung als Nachweis gewertet und nur von einem Menschen mit der entsprechenden Rolle als Unternehmenswahrheit freigegeben werden. Kein API-Scope, MCP-Tool oder Webhook kann diese Freigabe erteilen.
Es gibt bewusst keine Möglichkeit zur Genehmigung, Aktivierung oder Autorisierung auf irgendeiner Ebene. Das Nadelöhr ist strukturell bedingt: Die Routen zur Freigabe eines Vorschlags erfordern einen angemeldeten menschlichen Workspace-Admin – ein Prinzip, das durch eine permanente Test-Suite abgesichert ist.
Externe Antworten werden projiziert, nicht roh ausgegeben. Die Identitäten von Prüfern und Autoren verlassen den Workspace als Rollenbezeichnungen – z. B. „Workspace-Administrator“ – niemals mit Namen oder internen Kennungen. Verbundene Agenten erfahren, was und von welcher Rolle entschieden wurde, nicht von wem.
Das Vertrauensmodell
Jedes externe Element gilt initial als nicht vertrauenswürdig. Jede Stufe auf der Vertrauensleiter – von geprüften Nachweisen über freigegebenen Kontext bis hin zur Unternehmenswahrheit – ist eine menschliche Entscheidung, die die Autorisierung des Materials ändert.
Fragen
Jeder MCP-fähige Client. Claude (Web, Desktop und Mobil) verbindet sich über OAuth und ist nachweislich funktionsfähig; ChatGPT verbindet sich im Entwicklermodus über denselben OAuth-Flow. Claude Code, Cursor und benutzerdefinierte Agenten verbinden sich mit einem Workspace-API-Schlüssel.
Nein. Externe Agenten können freigegebenen Kontext lesen und Vorschläge einreichen, aber kein Scope oder Tool kann genehmigen, aktivieren oder veröffentlichen. Jeder Vorschlag wartet in einer Prüfwarteschlange, bis ein menschlicher Workspace-Admin entscheidet.
Sie landen als nicht vertrauenswürdiger Kontext in einem rein serverseitigen Prüfbereich. Ein Prüfer kann das Material zu einem Nachweis hochstufen, als aktive Vorgabe freigeben oder ablehnen – abgelehnte Elemente werden mit ihrer Historie aufbewahrt, beeinflussen aber niemals künftige Arbeiten.
Noch nicht – es handelt sich um eine schreibgeschützte, geschlossene Beta, die pro Workspace aktiviert wird. Der MCP-Server, die REST-API und eingehende Webhooks sind allgemein verfügbar.
Vertiefung
Entwickler
Endpunkte, Scopes, MCP-Tools und Webhook-Signierung im Detail.
Integrationen
Die Kanäle und Datenquellen, mit denen sich ein Workspace verbindet.
Governance & Autonomie
Das Prüfmodell, das jeder externe Vorschlag durchläuft.
Memory Governance Protocol
Die Doktrin hinter dem kontrollierten Unternehmensgedächtnis.
Erstellen Sie unter Einstellungen einen Workspace-API-Schlüssel oder starten Sie mit einem DNA-Scan – die offene Plattform liest aus derselben freigegebenen Datenbasis wie alles andere im Produkt.