In diesem Beitrag
Vendo für SaaS: Mandantentrennung und Freigaben
Quellenbasis: Dokumentation am 8. Oktober 2026 geprüft. Dies ist ein recherchierter Implementierungsleitfaden. Der folgende Pilot ist ein Vorschlag; wir haben diese Herstellerprüfungen nicht durchgeführt und ihre Leistung nicht gemessen.
Was bleibt nach einer Vendo-Integration beim SaaS-Team?
Dein Backend entscheidet weiterhin, welche Datensätze der angemeldete Nutzer lesen und ändern darf. Generierte Oberflächen, Sandbox und Freigabekarte ersetzen keine API-Autorisierung. Beginne mit einem kundenspezifischen Dashboard, dessen Werkzeuge bereits Mandantengrenzen durchsetzen. Ergänze Aktionen erst nach unabhängiger Prüfung dieser Grenze.
Gemeint ist Vendo unter vendo.run, die Anpassungsschicht im offiziellen runvendo-Repository. Sie ergänzt bestehende Produkte um agentengesteuerte Funktionen und kleine Anwendungen. Andere Unternehmen mit dem Namen Vendo sind hier nicht gemeint.
Wie sollten Identität und Mandantenzugriff funktionieren?
Die Vendo-Dokumentation zur Anmeldung übernimmt die bestehende Identität und empfiehlt ein unveränderliches Subject. Das Beispiel ohne Anmeldung weist allen Besuchern denselben Demo-Nutzer zu. Für einen produktiven Betrieb mit mehreren Mandanten ist dieses Beispiel ungeeignet.
Nutze denselben vertrauenswürdigen serverseitigen Session-Resolver für Vendo und eigene Routen. Ermittle Organisationsmitgliedschaften im Backend und prüfe sie in jedem Werkzeug mit Zugriff auf Geschäftsdaten. Eine vom Modell gelieferte Organisations-ID beweist keine Berechtigung. Auch Nutzer in zwei Organisationen benötigen eine eindeutige Grenze für die aktive Organisation.
Was muss ein Pilot mit zwei Mandanten beweisen?
Erstelle synthetische Organisationen A und B mit je einem Administrator und einem nur lesenden Mitglied. Beide haben eine Rechnung mit derselben lokalen Nummer, aber unterschiedlichen internen IDs. Geplant sind eine Ansicht überfälliger Rechnungen und eine Erinnerungsaktion. Folgende Fälle sind Abnahmeziele, keine beobachteten Vendo-Ergebnisse.
| Versuch | Erforderliches Ergebnis | Unabhängige Prüfung |
|---|---|---|
| A fragt B's Rechnungs-ID ab | Ablehnung ohne Datenleck | API-Antwort und Zugriffslog |
| A wechselt die aktive Organisation | Nur der neu berechtigte Kontext ist sichtbar | Datensätze erneut laden und gespeicherte App öffnen |
| Lesendes Mitglied sendet eine Erinnerung | Ohne ausdrückliches Recht blockiert | Versandprotokoll bleibt unverändert |
| Administrator verliert nach Freigabe seine Rolle | Recht wird vor Ausführung erneut geprüft | Kein Versand nach Entzug |
| Zwei Worker setzen dieselbe Freigabe fort | Genau ein logischer Seiteneffekt | Dauerhafter Aktionsschlüssel und Versandprotokoll |
| Prozess startet neu | Berechtigter Zustand bleibt, abgelaufene Grants bleiben abgelaufen | Speicherzustand und wiederholte Aktion |
Prüfe Lesezugriffe direkt gegen Host-Werkzeuge und durch die generierte UI. Ein versteckter Button ist kein Autorisierungstest.
Fragt Vendo vor jedem Schreibzugriff?
Nein. Die Freigabedokumentation beschreibt als Standard: Lesen und Schreiben laufen, destruktive und nicht eingestufte Aufrufe fragen nach. Definiere ausdrückliche Regeln für sensible Schreibaktionen wie Nachrichtenversand oder Abrechnungsänderungen. Ein geschäftlich kritischer Schreibzugriff kann Freigabe brauchen, ohne technisch als destruktiv eingestuft zu sein.
Die Dokumentation unterscheidet außerdem App und MCP: Nach MCP-Freigabe muss der externe Agent in derselben MCP-Session erneut aufrufen. Prüfe beide Wege, wenn Kunden beide nutzen. Binde Freigaben an die konkrete Aktion und prüfe Rechte bei Ausführung erneut. Eine Freigabe umgeht keine Autorisierung.
Was muss einen Neustart überstehen?
Die Persistenzdokumentation beschreibt Cloud-Speicherung für Threads, Apps, Grants, Freigaben, Audit und Läufe. Persistenz allein beweist keine einmalige Ausführung einer Host-Aktion. Pflege ein dauerhaftes Geschäftsaktionsprotokoll mit Mandant, Akteur, freigegebenen Argumenten, Aktionsschlüssel und geklärtem Ergebnis.
Prüfe bei unklarem externem Ergebnis zuerst das Zielsystem. Wurde eine Erinnerung bereits zugestellt und stirbt der Prozess vor dem Speichern der Antwort, kann eine neue Aktion sie doppelt senden. Teste genau diesen Absturzzeitpunkt.
Reicht ein erfolgreicher vendo-doctor-Lauf?
Nein. Laut Produktionscheckliste liest doctor Quellcode und Umgebung, ohne die bereitgestellte App aufzurufen. Nutze ihn für Verdrahtungsfehler, danach prüfe Staging auf Identität, Streaming, verifizierte Webhooks, Freigaben und Neustarts. Cloud übernimmt einige Infrastrukturaufgaben; mehrere Sicherheits- und Request-Grenzen verdrahtet weiterhin die Anwendung.
Wann passt Vendo?
Wenn Kunden unterschiedliche Ansichten oder begrenzte Abläufe über eine zuverlässig autorisierte API brauchen. Bei einer festen Aufgabe ohne kundenseitig erstellte Apps kann ein eigener Copilot einfacher sein. Kläre Wartung von Werkzeugschemas, gespeicherten Funktionen und Wiederherstellung vor der Ausweitung. Mit einer Funktion und Rechtematrix kannst du eine SaaS-Agentenintegration eingrenzen.
Weiterführende Umsetzungshilfe
Enterprise MCP Authorization Architecture: eine Multi-Tenant-Referenzarchitektur. AgentMail im SaaS: Mandantentrennung und doppelte E-Mails.
Geprüfte Quellen
Unabhängigkeit und Marken: Wavect veröffentlicht diese Seite und ist selbst Anbieter, wir haben also ein wirtschaftliches Interesse daran. Mit den hier genannten anderen Unternehmen sind wir weder verbunden noch von ihnen beauftragt oder empfohlen, und alle Firmennamen, Marken und Warenzeichen Dritter gehören ihren jeweiligen Inhabern. Aussagen über andere Anbieter stammen aus öffentlich zugänglichen Quellen, vor allem aus deren eigenen veröffentlichten Seiten, mit Stand des auf dieser Seite genannten Prüfdatums, und können sich seither geändert haben. Bitte prüfe sie vor einer Entscheidung selbst. Diese Seite wurde nach bestem Wissen und Gewissen erstellt, mit dem Ziel, möglichst objektiv zu bleiben. Wenn dir etwas falsch oder unfair erscheint, schreib uns und wir korrigieren es: [email protected]