Diese Seite ist die zentrale Referenz für Freigabeberechtigungen und Anmeldedatenfluss über die fünf freigabefähigen Ressourcentypen — Agents, Skills, Knowledge Bases, Connectors und Workflows. Nutzen Sie sie, um zu verstehen, was passiert, wenn Sie eine Ressource freigeben, die selbst auf anderen Ressourcen aufbaut.
Die zwei Fragen
Jede Freigabeentscheidung beantwortet zwei unabhängige Fragen:
- Sichtbarkeit — kann die andere Person diese Ressource überhaupt sehen/nutzen?
- 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.
| Freigabebereich | Bedeutung | Wie andere Zugriff erhalten |
|---|
| Persönlich (Standard) | Nur der Besitzer kann es sehen. | — |
| Organisation | In einer Organisation veröffentlicht. | Organisationsmitglieder abonnieren vom Marktplatz (oder werden beim Beitritt automatisch abonniert). |
| Global / Marktplatz | Im öffentlichen Marktplatz veröffentlicht. | Jeder abonniert vom Marktplatz. |
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:
| State | A subscriber with their own credential | A subscriber without their own credential | The owner |
|---|
| Allow fallback OFF (default) | Uses their own credential. | No access — the tool is hidden and the UI prompts them to configure their own credential. | Always uses their own. |
| Allow fallback ON | Uses their own credential. | Falls back to the owner’s credential (and any usage/billing lands on the owner). | Always uses their own. |
- 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 komponieren. Das Teilen einer Ressource macht implizit die darunter gebundenen Ressourcen verfügbar — aber Anmeldedaten fließen nicht automatisch mit ihnen.
| Container | Kann referenzieren | Wie |
|---|
| Agent | Knowledge Bases, Connectors, MCP servers | kb_ids / connector_ids / mcp_server_ids |
| Agent | Skills | skill_ids (veraltet — verwenden Sie stattdessen Skill→Agent) |
| Skill | Connectors, Agents, … | resource_refs (der @alias-Mechanismus) |
| Workflow | Agents, Knowledge Bases, Connectors, MCP servers | pro Knoten agent_id / kb_id(s) / connector_id / mcp_server_id |
- Knowledge Bases haben keine benutzerspezifischen Anmeldedaten, daher delegiert eine an einen gemeinsamen Agent gebundene KB ihren Inhalt: Wer den Agent ausführt, liest die Daten des KB-Besitzers (der Agent benötigt seine KB zum Funktionieren). Ad-hoc-KB-Suche außerhalb eines gebundenen Agents wird zugriffsgeprü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:
| Szenario | ”Allow fallback” des Connectors | Was der andere Benutzer erhält |
|---|
| 3a | ON | Das Connector-Tool ist verfügbar und wird mit Ihren Anmeldedaten ausgeführt — der andere Benutzer kann es verwenden. Die Nutzung wird Ihnen in Rechnung gestellt. |
| 3b | OFF (Standard) | Das Connector-Tool ist für diesen Benutzer verborgen. Der Rest des Agents funktioniert weiterhin; die Benutzeroberfläche fordert ihn auf, seine eigenen Anmeldedaten für diesen Connector hinzuzufügen. Danach wird das Tool wieder angezeigt und wird mit seinem Schlüssel ausgeführt. |
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.
