expired_time. Diese Seite ist der fokussierte Leitfaden zu dieser einen
Kontrolle. Für die Ausgabenlimit-Seite desselben Bildschirms siehe
Kontingent-Cap & Ablauf.
1. Warum einen ablaufenden API-Key setzen
Der Sinn eines zeitgebundenen Schlüssels ist es, das sichere Ergebnis zum Default zu machen. Ein paar Fälle, in denen es sich auszahlt:Ephemere Agenten
Ein geplanter Job oder kurzlebiger Agent bekommt einen Schlüssel, der mit
dem Deployment-Lebenszyklus stirbt. Ein vergessener Cron-Task kann nicht
Monate später weiter Geld ausgeben.
Demos & Trials
Übergeben Sie einem Interessenten einen Schlüssel, der für die Länge der
Evaluierung funktioniert und dann von selbst dunkel wird — kein
Nachfass-Widerruf nötig.
Auftragnehmer & Lieferanten
Fassen Sie eine Anmeldeinformation auf das Engagement-Fenster. Wenn der
Vertrag endet, endet auch der Schlüssel.
Incident-bezogener Zugang
Gewähren Sie während eines Vorfalls einen engen, kurzlebigen Schlüssel,
sodass erhöhter Zugang den Vorfall selbst nicht überleben kann.
2. Das expired_time-Feld
Der Ablauf eines Schlüssels lebt in einem einzelnen Feld auf dem
Token-Objekt:
| Feld | Typ | Bedeutung |
|---|---|---|
expired_time | Unix-Zeitstempel (Sekunden) | Der absolute Augenblick, an dem der Schlüssel aufhört zu autorisieren. -1 bedeutet läuft nie ab. |
expired_timeist absolut, keine Dauer. Sie setzen den Moment, an dem der Schlüssel stirbt, nicht „30 Tage ab jetzt” — der Datumswähler der Konsole berechnet den Zeitstempel für Sie.- Der Default für einen neuen Schlüssel ist
-1(nie). Ein Schlüssel läuft nur ab, wenn Sie ihm einen echten Zeitstempel geben; das Feld unberührt zu lassen prägt einen nicht ablaufenden Schlüssel.
3. Einen Ablauf in der Konsole setzen
Einen Ablauf zu setzen ist eine Konsolen-Aktion auf Ihrem Session-/Access-Token — nicht etwas, das Sie auf einem Relay-Aufruf übergeben. Das Erstellen oder Bearbeiten eines Schlüssels erfordert die Rolle Developer oder höher.- Öffnen Sie Schlüssel (
/console/token) und erstellen Sie einen neuen Schlüssel oder bearbeiten Sie einen bestehenden. - Wählen Sie im Ablauf-Feld das Datum und die Uhrzeit, an dem der Schlüssel aufhören soll zu funktionieren. Lassen Sie es leer (oder setzen Sie nie), um den Schlüssel permanent zu halten.
- Speichern. Die Änderung wird sofort wirksam — kein Redeploy, keine Änderung im Agenten-Code.
Nur
/v1/*-Relay-Aufrufe tragen den sk-orca-…-Schlüssel. Der Ablauf, den
Sie hier setzen, steuert diesen Relay-Schlüssel, aber Sie konfigurieren ihn
aus der Konsolen-Session, niemals indem Sie den Relay-Schlüssel an eine
Management-Route senden.4. Was ein abgelaufener Schlüssel tut
Wenn ein Schlüssel präsentiert wird, nachdem seineexpired_time vergangen
ist, lehnt das Gateway ihn auf der Auth-Ebene ab — der Request erreicht nie ein
Modell, sodass er kein Kontingent kostet. Der Status des Schlüssels wechselt zu
Expired, einem der automatischen Endzustände, die ein Schlüssel erreichen
kann:
| Status | Wie erreicht |
|---|---|
Enabled | Aktiv; Requests sind autorisiert. |
Disabled | Sie haben ihn pausiert; umkehrbar. |
Expired | Über seine expired_time hinaus — automatisch erreicht. |
Exhausted | Über sein Kontingent / Ausgabenlimit — automatisch erreicht. |
Expired ist terminal in dem Sinne, dass der Schlüssel nicht von selbst wieder
autorisieren wird. Wenn Sie ihn zurückbrauchen, bearbeiten Sie den Schlüssel,
um expired_time in die Zukunft zu schieben (Developer+), und er kehrt beim
nächsten Request zu Enabled zurück — der Schlüssel, seine Limits und seine
Policy-Bindungen sind alle erhalten. Um einen Schlüssel stattdessen endgültig
zurückzuziehen, widerrufen Sie ihn.
Ablauf vs. deaktivieren vs. widerrufen. Der Ablauf ist der geplante
Aus-Schalter — Sie entscheiden die Deadline vorab und gehen davon.
Deaktivieren
ist die manuelle, umkehrbare Pause für einen Vorfall.
Widerrufen
(löschen) ist permanent. Greifen Sie zum Ablauf, wann immer Sie bereits wissen,
wann eine Anmeldeinformation aufhören sollte zu zählen.
5. Ein durchgespieltes Beispiel: ein Zwei-Wochen-Demo-Schlüssel
Angenommen, Sie geben einem Interessenten einen Schlüssel für eine 14-tägige Evaluierung. Sie wollen, dass er ein billiges Modell aufruft, nicht mehr als ein festes Budget ausgibt und dunkel wird, wenn das Trial endet — alles ohne eine Kalendererinnerung, ihn zu widerrufen. Setzen Sie im Neuer Schlüssel-Dialog:model_limits:["openai/gpt-4o-mini"]— die Demo kann nicht nach einem teureren Modell greifen.credit_limit_usd: ein festes Trial-Budget — eine außer Kontrolle geratene Schleife kann es nicht überschreiten.expired_time: das Ende des 14-Tage-Fensters — der Schlüssel hört von selbst auf zu autorisieren, wenn das Trial vorbei ist.
Expired in der
Liste. Nichts für Sie aufzuräumen; die Anmeldeinformation hat sich selbst
zurückgezogen.
6. Wer was tun darf
Der Ablauf wird vom selben Rollen-Gate gesteuert wie der Rest des Schlüssel-Lebenszyklus, bezogen auf Ihren aktiven Workspace:| Aktion | Mindestrolle |
|---|---|
| Den Ablauf eines Schlüssels ansehen | Viewer |
expired_time setzen oder ändern (Schlüssel erstellen / bearbeiten) | Developer |
| Den Klartext eines gewöhnlichen Schlüssels erneut einblenden | Developer |
Den Klartext eines gateway-scoped (is_firewall_gateway) Schlüssels lesen | Admin |
7. Nächste Schritte
Kontingent-Cap & Ablauf
Das Ausgabenlimit-Geschwister des Ablaufs — begrenzen Sie einen Schlüssel
sowohl nach Dollar als auch nach Zeit.
Schlüsselrotation
Die ausfallfreie Übergabe, die einen nicht ablaufenden Schlüssel davor
bewahrt, ewig zu leben.
Das Token-Objekt
Jedes Feld, das ein Schlüssel trägt, einschließlich
expired_time, und was
jedes davon beschränkt.Least-Agency-Checkliste
Kombinieren Sie den Ablauf mit Modell-Limits, IP-Allowlists und
Ausgabenlimits für einen Schlüssel mit minimalem Blast-Radius.
expired_time, wann immer Sie das Datum benennen können — und lassen Sie das
Gateway das Aufräumen für Sie erledigen.