Übersicht
user_path ist eine normalisierte Hierarchie für den Aufrufer, zum Beispiel
/team/alpha oder /team/alpha/service.
GoModel verwendet sie, um Modellzugriff, Workflows, Budgets, Nutzung und Audit-Daten
dem richtigen Team, Tenant, Dienst oder Kunden zuzuordnen.
API-Keys
Sie können einen User-Path im Admin-Dashboard an einen verwalteten API-Key binden:API Keys -> Create API Key -> User Path
user_path zusammen mit seinen
Labels, sodass Sie auf einen Blick erkennen, welchem Teilbaum ein Key zugeordnet ist.
Verwendet ein Request diesen Key, behandelt GoModel den user_path des Keys als
effektiven User-Path des Requests.
HTTP-Header
Clients können einen User-Path auch direkt senden:USER_PATH_HEADER oder
server.user_path_header in config.yaml konfigurieren. Ist nichts gesetzt, verwendet GoModel
X-GoModel-User-Path.
Hat der API-Key einen eigenen user_path, hat der Key Vorrang. GoModel überschreibt den
Header-Wert mit dem an den Key gebundenen Pfad, bevor Workflow-Abgleich, Audit-Logging,
Nutzungserfassung und Prüfungen des Modellzugriffs laufen.
Zugriffsbereich
Der an den Key gebundeneuser_path ist zugleich der Zugriffsbereich des Keys: der Teilbaum, den er
lesen und verwalten darf. Ein an /team/alpha gebundener Key erreicht /team/alpha und
jeden Nachfahren, aber weder /team/beta noch /team noch Zeilen, die
ohne User-Path erfasst wurden. Der Header erweitert den Bereich nie; er wählt nur den
Pfad, dem ein Request zugeordnet wird.
Die Regel ist für alle Zugangsdaten gleich: Der User-Path ist der Knoten, als der Sie
handeln, und Sie sehen diesen Knoten und alles darunter. Eine an
/users/alice gebundene SSO-Session verwaltet daher nur diesen Teilbaum. Eine Erweiterung, die
Gateway-Admins vergeben möchte, bindet diese Sessions an / und Team-Admins an die
Wurzel des Teams, etwa /team/alpha – genau so, wie Sie einen API-Key unter
diesem Pfad erstellen würden.
Der Bereich gilt an zwei Stellen:
- Admin API und Dashboard. Ein Key mit Dashboard-Zugriff und einem
user_pathist ein bereichsbeschränkter Admin dieses Teilbaums. Siehe Bereichsbeschränkter Admin-Zugriff. - Objekteigentum bei
/v1-Lebenszyklus-Endpunkten, wie im Folgenden beschrieben.
Objekteigentum
Responses, Conversations, Batches und hochgeladene Dateien merken sich denuser_path,
unter dem sie erstellt wurden. Abrufen, Auflisten, Aktualisieren, Abbrechen oder Löschen
eines solchen Objekts per ID gelingt nur, wenn dieser Pfad im Bereich des Aufrufers liegt;
andernfalls antwortet das Gateway mit 404, genau wie bei einer unbekannten ID. Ein
/v1/responses-Aufruf, der auf eine Conversation oder eine
previous_response_id aus einem anderen Teilbaum verweist, schlägt auf dieselbe Weise fehl – auch bei
Providern, die previous_response_id selbst auflösen.
Bereichsbeschränkte Zugangsdaten können nur Objekte ansprechen, die das Gateway nachverfolgt: Eine ID, zu der das
Gateway keinen Eintrag hat, wird als fehlend gemeldet, und GET /v1/files listet die
nachverfolgten Dateien des Aufrufers aus den eigenen Einträgen des Gateways statt vom
Provider. Globale Zugangsdaten sehen jedes Objekt, einschließlich älterer Zeilen, die erfasst wurden,
bevor der Pfad gespeichert wurde, und greifen bei nicht nachverfolgten IDs weiterhin auf den Provider zurück.
Verwenden Sie einen persistenten Speicher, damit jedes Objekt über Neustarts hinweg nachverfolgt bleibt.
Modellzugriff
Richtlinien für den Modellzugriff sind standardmäßig aktiviert. Eine Richtlinie ist ein virtuelles Modell ohne Ziel; sie kann mituser_paths einen Selektor auf einen Teilbaum beschränken oder
deaktiviert werden, um den Selektor vollständig abzuschalten. Selektoren können Folgendes adressieren:
/für alle Provider und Modelle{provider_name}/für einen konfigurierten Provider{provider_name}/{model}für ein Modell bei einem Provider- eine Modell-ID ohne Provider-Namen
- Selektor:
openai/gpt-5 user_paths:["/team/alpha"]
/team/alpha und seine Nachfahren erlaubt, etwa /team/alpha/service.
Verwalten Sie diese Regeln im Dashboard unter Models -> New virtual model: Lassen Sie
Target model leer, um eine Zugriffsrichtlinie für den Source-Selektor zu erstellen.
Redirects (Aliase) finden Sie unter Virtuelle Modelle.
Die Seite Users beantwortet dieselbe Frage von der anderen Seite: Welche Modelle
darf eine Gruppe, ein Benutzer oder ein API-Key aufrufen? Jeder User-Path-Knoten und jeder verwaltete API-Key hat eine
optionale Liste allowed_models; die Listen werden den Baum hinab geschnitten, sodass ein Kindknoten
nur einschränken kann, was seine Gruppe erlaubt. Siehe Benutzer.
Bereitgestellte Modelle
GET /v1/models verwendet ebenfalls den effektiven user_path.
Zwei API-Keys können daher unterschiedliche Modelllisten sehen, wenn für ihre User-Paths
unterschiedliche Regeln für den Modellzugriff gelten.
Workflows
Workflows können auchscope_user_path enthalten, sodass verschiedene Teams oder Dienste
unterschiedliche Einstellungen für Budget, Cache, Audit, Nutzung, Guardrails und Failover verwenden können.
Sie können den User-Path mit Provider- und Modellbereich kombinieren, zum Beispiel:
/team/alphaopenai_primary+/team/alphaopenai_primary+gpt-5+/team/alpha
Budgets
Auch Budgets sind überuser_path einem Bereich zugeordnet. Ein Budget für /team/alpha gilt für
/team/alpha und Nachfahren wie /team/alpha/service, aber nicht für benachbarte
Pfade wie /team-alpha.
Ausgabenlimits und die Durchsetzung über Workflows finden Sie unter Budgets.