Authentifizierung und Bereiche

Ein Schlüssel ist ein Bearer-Token. Gespeichert wird nur sein Hash — Ikrames kann ihn dir nicht noch einmal zeigen. Behandle ihn also wie ein Passwort: nicht in die Versionsverwaltung, nicht in Chat-Protokolle.

Es gibt zwei Bereiche:

Ein read-Schlüssel sieht die generate-Werkzeuge gar nicht. Sie sind für ihn nicht registriert: sie fehlen in tools/list, und ein Aufruf antwortet „Tool generate_image not found" — nicht „verboten". Diese Wortwahl ist Absicht. Ein Fehler, der „gibt es, darfst du aber nicht" von „gibt es nicht" unterscheidet, sagt einem unbefugten Aufrufer, wonach er suchen soll.

Abgewiesene Schlüssel bekommen aus demselben Grund alle dieselbe Antwort: ein unbekannter Schlüssel, ein widerrufener Schlüssel und ein kaputter Header liefern jeweils 401 ohne Einzelheiten. Der wirkliche Grund steht im Server-Protokoll.

Schlüssel lassen sich widerrufen. Ein widerrufener Schlüssel hört sofort auf zu wirken, bei der nächsten Anfrage — es gibt keinen Zwischenspeicher, den man abwarten müsste.

Einen Schlüssel anlegen

Du legst ihn selbst an, in der App. Öffne das Kontomenü hinter deinem Bild und wähl API-Schlüssel — der Eintrag steht neben Einstellungen, nicht darin.

Beim Anlegen wirst du nach zwei Dingen gefragt:

• Einem Namen, bis 60 Zeichen. Er ist für dich, nicht für den Server — ihn liest du Monate später, wenn du entscheidest, welchen von fünf Schlüsseln du gefahrlos abschalten kannst. Benenn ihn nach dem, was ihn hält (Architekt MCP, Laptop, n8n), nicht nach dem, was er tut.
• Den Bereichen, die er bekommt: read, generate oder beides. Was welcher freischaltet, steht in der Tabelle oben.

Jeder Schlüssel beginnt mit ikr_. Das Präfix ist Absicht: eine Zeichenkette, die in einer Protokolldatei, einem Bildschirmausschnitt oder einer eingefügten Konfiguration auftaucht, ist auf einen Blick als Ikrames-Schlüssel erkennbar — und ein Geheimnis, das niemand erkennt, ist ein Geheimnis, das niemand widerruft.

Bereiche stehen für die Lebensdauer eines Schlüssels fest. Es gibt kein Bearbeiten, und zwar mit Absicht: aus einem read-Schlüssel wird nie ein generate-Schlüssel. Ein Agent, der mehr braucht, bekommt einen neuen Schlüssel, und der alte verschwindet. Eine Berechtigung, die sich erweitern lässt, nachdem der Token schon im Umlauf ist, ist keine Berechtigung, sondern eine Bitte.

Widerrufen ist endgültig. Es greift bei der nächsten Anfrage, wie oben, und lässt sich nicht zurücknehmen; zweimal widerrufen verschiebt auch den Zeitstempel nicht, denn wann ein Schlüssel gestorben ist, ist die Tatsache, auf die sich eine Vorfallsuntersuchung stützt. Die Zeile bleibt stehen, ein widerrufener Schlüssel steht also weiter in der Liste unter den lebenden, mit dem Zeitpunkt seiner letzten Benutzung.

Anlegen und Widerrufen brauchen eine verwaltende Rolle — Eigentümer oder Verwalter des Arbeitsbereichs. Das Benutzen nicht: ein Schlüssel ist an den Arbeitsbereich gebunden, nie an die Person, die ihn angelegt hat, und er arbeitet weiter, wenn diese Person geht.

Ein Schlüssel gehört zum Arbeitsbereich, nicht zu einer Marke. Er sieht jede Marke darin, list_brands gibt alle zurück, und es gibt keinen Weg, einen Schlüssel auf eine einzelne zu verengen. Wenn dein Agent nur eine Marke anfassen darf, liegt diese Grenze in deinem Code — in der brand_id, die du übergibst — und nicht im Schlüssel.

Wie viele Schlüssel du gleichzeitig halten darfst, gehört zu deinem Tarif:

Die Decke zählt aktive Schlüssel je Arbeitsbereich; widerrufene zählen nicht, Aufräumen kostet dich also nie einen Platz. Achte aber auf die Reihenfolge, wenn du an der Decke sitzt: dort musst du erst widerrufen und dann anlegen, der bequeme Wechsel — neuen Schlüssel machen, Konfiguration umziehen, alten abschalten — geht auf dem letzten freien Platz also nicht. Plan diese Lücke ein, wenn du einen Schlüssel wechselst, von dem etwas abhängt.