Skip to main content
Diese Seite ist die einzige Referenz für Freigabeberechtigungen und Anmeldedatenfluss. Die freigebbaren Ressourcentypen sind Agents, Connectors und MCP-Server (plus Skills und Workflows, wenn diese optionalen Module aktiviert sind). Nutzen Sie diese Seite, um zu verstehen, was passiert, wenn Sie eine Ressource freigeben, die selbst auf anderen Ressourcen aufbaut.
Wissensdatenbanken sind nicht freigebar. Eine KB erreicht andere Personen nur, indem sie an einen freigegebenen Agent gebunden wird, der den Inhalt des Besitzers zur Laufzeit delegiert (siehe „Wie der Zugriff durch gebundene Ressourcen fließt”). Es gibt keine Publish-KB-Aktion.

​
Die zwei Fragen

Jede Freigabeentscheidung beantwortet zwei unabhängige Fragen:
  1. Sichtbarkeit — kann die andere Person diese Ressource überhaupt sehen/nutzen?
  2. Anmeldedaten — mit wessen Geheimnis (API-Schlüssel, Datenbankpasswort, Server-Umgebung) wird es ausgeführt?
Sichtbarkeit betrifft die Ressource; Anmeldedaten sind eine separate, benutzerspezifische Angelegenheit, die nur Connectors und MCP-Server betrifft. Halten Sie diese auseinander — die meiste Verwirrung entsteht durch die Vermischung von „Ich kann es sehen” mit „Ich kann den Schlüssel des Eigentümers nutzen”.

​
Sichtbarkeit: Eigene + abonnierte Ressourcen

Eine Ressource ist für Sie nur sichtbar, wenn Sie sie besitzen oder Sie ein explizites Abonnement dafür haben. Es gibt keine implizite “Alle in meiner Organisation können es sehen”-Regel mehr — die Freigabe in der Organisation wird durch Abonnements bereitgestellt. Die gleiche Regel gilt überall dort, wo eine Ressource verwendet wird — Chat-Tool-Zusammenstellung, Bindung an einen Agenten und ein Workflow-Schritt lösen alle Eigene + abonnierte auf. Ein Connector, den Sie abonniert haben, kann also an einen Agenten gebunden und aus einem Workflow aufgerufen werden; einer, den Sie weder sehen noch abonnieren können, wird an allen drei Stellen abgelehnt.
Abonnements sind begrenzt: Wenn Sie eine Organisation verlassen (oder daraus entfernt werden), werden die Abonnements, die Sie nur durch sie hatten, widerrufen, und die pro Benutzer gespeicherten Anmeldedaten für diese Ressourcen werden gelöscht.

​
Credentials & “Allow fallback”

Only Connectors and MCP servers hold credentials. Each one has an Allow fallback switch that decides whether subscribers may borrow the owner’s credential: Key rules:
  • Off is the default. Sharing your token is opt-in. A newly created connector or MCP server does not share the owner’s credential, and existing ones were migrated to off.
  • The owner is always exempt. “Allow fallback” only governs other users; you can always use your own connector with your own credential.
  • No silent failure. When fallback is off and a user has no credential, the tool is removed from the toolset rather than offered and then failing at call time. Every surface (chat, the Playground, workflow steps) must show a “configure your own credentials” prompt instead of a broken tool.

​
Wie der Zugriff durch gebundene Ressourcen fließt

Ressourcen werden zusammengesetzt. Das Freigeben einer Ressource macht die darunter gebundenen Ressourcen implizit verfügbar — aber Anmeldedaten fließen nicht automatisch mit ihnen. Wenn Sie den Container freigeben, reisen die Referenzen als Graph von IDs mit — ein freigegebener Workflow oder Agent enthält keine eingebetteten Geheimnisse. Zur Laufzeit überprüft jede referenzierte Ressource den Zugriff des Ausführenden erneut:
  • Knowledge Bases haben keine benutzerabhängige Anmeldedaten, daher delegiert eine an einen freigegebenen Agent gebundene KB ihren Inhalt: Wer den Agent ausführt, liest die Daten des KB-Besitzers (der Agent benötigt seine KB zum Funktionieren). Die Delegierung wird durch die Sichtbarkeit des Agent-Besitzers gesteuert — wenn der Agent-Besitzer den Zugriff auf eine gebundene KB verliert (z. B. nach dem Verlassen der Organisation, über die sie freigegeben wurde), wird diese KB aus dem Agent entfernt, anstatt weiterhin gelesen zu werden. Ad-hoc-KB-Suche außerhalb eines gebundenen Agents wird gegen den Aufrufer überprüft (eigene + abonnierte).
  • Connectors / MCP servers enthalten Anmeldedaten, daher delegieren sie nur, wenn „Allow fallback” aktiviert ist (siehe unten).

​
Bearbeitete Szenarien

Sie besitzen einen Agent, der einen persönlichen Connector bindet (Sie haben den Connector selbst nicht freigegeben). Sie teilen den Agent mit Ihrer Organisation oder global. Jemand anderes führt ihn aus: Mit anderen Worten: Das Freigeben des Agents gibt nicht das Geheimnis des Connectors frei. Die Einstellung “Allow fallback” des Connectors selbst ist der einzige Schalter, der entscheidet, ob die Anmeldedaten durch die Bindung eindringen. Dasselbe gilt für einen Connector oder MCP-Server, auf den von einem Skill oder einem Workflow-Schritt aus verwiesen wird.
Deshalb ist das empfohlene Muster für einen Connector, den Sie freigeben möchten: Lassen Sie Allow fallback aus, und lassen Sie jeden Benutzer seine eigenen Anmeldedaten binden. Schalten Sie es nur ein, wenn Sie absichtlich Ihren Schlüssel verleihen möchten (und die Nutzung übernehmen) — zum Beispiel eine gemessene API, für die Sie bereit sind, die Kosten für andere zu übernehmen.