Zum Hauptinhalt springen
Sie betreiben fast nie nur einen Schlüssel. Ein echter Workspace hat einen Produktionsschlüssel, einen Staging-Schlüssel, den lokalen Schlüssel eines Entwicklers, vielleicht einen Einmalschlüssel für einen Lasttest — alle rufen dieselben Modelle durch dasselbe Gateway auf. Unterscheiden Sie sie mit dem environment-Tag: ein kurzes freiform Label, das Sie auf jeden Schlüssel stempeln, sodass die Konsole, Ihr Team und der Usage-Tracking-Tab Schlüssel danach gruppieren können, wo sie laufen. Dies ist das kleine organisatorische Feld, kein Durchsetzungsfeld — es ändert nicht, was ein Schlüssel tun kann. Für die Limits, die einen Schlüssel begrenzen (Modelle, IPs, Ausgaben, Ablauf, Policies), starten Sie bei der Übersicht über Scoped Keys.

​
1. Warum das API-Key-Umgebungs-Tag

Wenn jeder Schlüssel in der Liste wie sk-orca-•••• aussieht, können Sie den Produktionsschlüssel nicht vom Wegwerf-Dev-Schlüssel unterscheiden — und genau das ist der Schlüssel, den Sie nicht versehentlich rotieren, widerrufen oder dessen Ausgabenlimit Sie nicht versehentlich anheben wollen. Das environment-Tag verwandelt eine anonyme Anmeldeinformation in eine beschriftete:
  • Auf einen Blick — die Schlüsselliste zeigt, welche Schlüssel prod, staging oder dev sind, sodass Sie am richtigen handeln.
  • Nach Ausgaben — der Usage-Tracking-Tab kann Ausgaben nach Umgebung bündeln, sodass „was kostet uns Staging diese Woche” ein Filter ist, kein Spreadsheet.
  • Nach Konvention — ein gemeinsames Vokabular (prod / staging / dev) über den Workspace hinweg, sodass ein Teamkollege, der die Liste liest, Ihre Aufteilung versteht, ohne zu fragen.
Das Tag ist freiform und nur beschreibend. Es steuert nicht Modelle, IPs, Ausgaben oder Policy — das sind die anderen Schlüsselfelder. Zwei mit prod getaggte Schlüssel bekommen keine Sonderbehandlung über das Teilen eines Labels hinaus.

​
2. Was das Feld akzeptiert

environment ist ein optionales, kurzes Text-Label auf dem Schlüssel-Objekt:
EigenschaftVerhalten
TypFreiform-String — kein festes Enum. prod, staging, dev sind Konventionen, keine eingebauten Werte.
LängeVon umgebenden Leerzeichen getrimmt und auf 32 Zeichen begrenzt; alles Längere wird abgeschnitten.
Leer / ungesetztEin Schlüssel ohne Tag liest sich als unbeschriftet zurück und fällt in ein unlabeled-Segment in Usage Tracking.
Effekt auf TrafficKeiner — rein organisatorisch.
Wählen Sie ein kleines, stabiles Vokabular und bleiben Sie dabei. prod, staging, dev ist für die meisten Teams genug; Konsistenz ist das, was das Tag nützlich macht, wenn Sie Ausgaben filtern. Ein Freitext-Feld mit prod, Prod und production darin verfehlt den Zweck.

​
3. Das Tag auf einem Schlüssel setzen

Setzen Sie environment im Schlüssel-Editor in der Konsole (/console/token) — an demselben Ort, an dem Sie Modell-Limits und Policy-Bindungen setzen. Das Erstellen oder Bearbeiten von Schlüsseln erfordert die Rolle Developer oder höher.
1

Den Schlüssel öffnen

Gehen Sie in der Konsole zu Schlüssel (/console/token) und erstellen Sie einen neuen Schlüssel oder bearbeiten Sie einen bestehenden.
2

Das Umgebungs-Label setzen

Geben Sie ein kurzes Label — z. B. prod — im Environment-Feld ein. Halten Sie es unter 32 Zeichen.
3

Speichern

Das Tag ist nun an den Schlüssel angehängt. Es erscheint in der Schlüsselliste und wird als Usage-Tracking-Dimension verfügbar.
Das Bearbeiten eines Schlüssels, um ein unverwandtes Feld zu ändern (eine Umbenennung, ein neues Ausgabenlimit), bewahrt das bestehende Umgebungs-Tag — das Tag wird nur geändert, wenn Sie es explizit setzen. Um ein Tag zu löschen, setzen Sie das Feld auf einen leeren Wert; das ist ein absichtlicher Reset zurück auf den unbeschrifteten Zustand.

​
4. Ausgaben nach Umgebung segmentieren

Sobald Ihre Schlüssel getaggt sind, kann der Usage-Tracking-Tab (Konsole → Übersicht) Ausgaben, Requests und Tokens nach der Umgebungs-Dimension gruppieren. Er bündelt die Nutzung jedes Schlüssels unter seinem Umgebungs-Label, mit ungetaggten Schlüsseln gesammelt unter unlabeled. Das beantwortet Fragen, die die Pro-Schlüssel-Ansicht nicht kann, auf der Ebene, auf der Sie tatsächlich budgetieren:
  • Wie viel gibt staging gegenüber prod diese Woche aus?
  • Hat der neue dev-Schlüssel überschritten, was wir erwartet hatten?
  • Welche Umgebung trieb den Spike am Dienstag?
Dieselbe Ansicht segmentiert auch nach Schlüssel, Modell, Mitglied und Use-Case-Task — die Umgebung ist die, die darauf abbildet, wo der Traffic lief. Die Ausgaben-Segmentierung liest nur Consume-Zeilen, bezogen auf Ihren Workspace, sodass die Zahlen mit Billing übereinstimmen.
Die Umgebungs-Dimension liest das aktuelle Label auf jedem Schlüssel, wenn Sie den Bericht laden. Das Neutaggen eines Schlüssels ändert, wie seine historischen Ausgaben das nächste Mal gebündelt werden, wenn Sie die Ansicht öffnen — das Tag ist eine Live-Eigenschaft des Schlüssels, kein auf vergangene Requests eingefrorener Stempel.

​
5. Ein durchgespieltes Beispiel: drei Schlüssel, ein Workspace

Ein kleines Team, das ein Produkt über drei Umgebungen hinweg betreibt:
SchlüsselenvironmentAnderer Scope (der Teil, der tatsächlich durchsetzt)
Produktions-Agentprodenge firewall_policy_id, wöchentliches credit_limit_usd, gepinnte allow_ips
Staging-Agentstagingeine permissive Firewall-Policy im Shadow-Mode, ein niedrigeres Cap
Lokales Devdevmodel_limits auf ein billiges Modell, kurzfristige expired_time
Die Tags ändern keines dieser Limits — sie machen die drei Schlüssel lesbar. Die Liste liest sich auf einen Blick, der Usage-Tab zeigt drei Ausgabenbalken statt drei undurchsichtiger Schlüssel-IDs, und wenn Sie den prod-Schlüssel rotieren, sind Sie sicher, dass Sie den richtigen gegriffen haben.
Kombinieren Sie das Umgebungs-Tag mit echter Durchsetzung, sodass jeder Schlüssel sowohl beschriftet als auch begrenzt ist. Das Tag sagt Ihnen, was ein Schlüssel ist; die Least-Agency-Checkliste stellt sicher, dass er nicht mehr tun kann, als diese Umgebung braucht.

​
6. Tags vs. Durchsetzung — verwechseln Sie die beiden nicht

Das Umgebungs-Tag ist das leichteste Feld auf einem Schlüssel. Es ist verlockend, danach als Sicherheitskontrolle zu greifen; es ist keine. Wenn Sie wollen, dass ein dev-Schlüssel unfähig ist, Produktionsmodelle zu treffen oder echtes Geld auszugeben, wird das Label das nicht tun — die durchsetzenden Felder werden es:

Modell-Limits

model_limits ist das, was einen Dev-Schlüssel tatsächlich davon abhält, ein Frontier-Modell aufzurufen — nicht das dev-Tag.

Kontingent, Cap & Ablauf

credit_limit_usd und expired_time begrenzen Ausgaben und Lebensdauer. Das Tag organisiert; diese beschränken.

Policies binden

guardrail_id und firewall_policy_id hängen die Content- und Tool-Call-Policies an, die den Traffic des Schlüssels steuern.

Das Token-Objekt

Die vollständige Feld-für-Feld-Referenz für einen Schlüssel, Umgebungs-Tag inbegriffen.

​
7. Wo das hineinpasst

Das Umgebungs-Tag ist ein Stück des breiteren Schlüsselmodells — enge, beschriftete Identitäten für jeden Agenten und jeden Ort, an dem er läuft.

Übersicht über Scoped Keys

Der Hub für jedes Feld, das ein Schlüssel trägt.

Scope & Schlüssel

Wie Workspaces, Policies und Schlüssel zusammen verschachtelt sind.

Schlüssel verwalten

Schlüssel in der Konsole erstellen, bearbeiten und widerrufen.
Ein Tag ist die billigste Investition in einen ordentlichen Workspace: ein paar Zeichen pro Schlüssel und der Unterschied zwischen einer Liste, die Sie lesen können, und einer, die Sie nicht lesen können. Stempeln Sie jeden Schlüssel mit seiner Umgebung in dem Moment, in dem Sie ihn erstellen — und lassen Sie die anderen Felder das Durchsetzen erledigen.