Permissions ueber Keys, Tiers und Policies sauber steuern
Access Control in QuantenRam entsteht nicht an einer einzigen Stelle, sondern aus mehreren Schichten. Ein API-Key entscheidet, wer ueberhaupt sprechen darf, das Tier entscheidet, welche Modellfamilien sichtbar werden, und lokale Workflow-Policies entscheiden, welche Tools oder Commands ohne Rückfrage laufen dürfen.
Diese Ebenen sollten bewusst getrennt konfiguriert werden. Wenn ein Team alles in einen einzigen Generalschlüssel und eine einzige Allow-Liste legt, wird später schwer unterscheidbar, ob ein Problem von Authentifizierung, Modellfreigabe oder Workflow-Rechten kommt. Gute Permission-Konfiguration macht genau diese Grenzen sichtbar und damit schneller wartbar.
API-Key-Rechte
Ein Key gehört immer zu genau einem Nutzerkonto, hat einen Namen, einen Scope-Satz und einen Aktivstatus. Praktisch ist heute vor allem inference:chat relevant. Genau deshalb solltest du lieber mehrere kleine, klar benannte Keys pro Umgebung verwenden als einen einzigen universellen Schlüssel.
Modellzugriff ueber Tier und Katalog
Ob ein Alias nutzbar ist, entscheidet sich an der Kombination aus Key und Tierfreigabe. Modelle werden im Katalog ueber allowed_tiers zugeordnet. Wenn ein Alias fehlt, ist die erste Diagnose deshalb immer ein Blick auf /v1/models mit genau dem betroffenen Key.
Workflow-Policies im Team
Selbst mit gültigem Key und freigeschaltetem Modell sollten nicht alle Tools und Commands automatisch laufen. Eine lokale Allow-, Ask- und Deny-Matrix bleibt die letzte Sicherheitsgrenze, besonders für Shell, Netzwerk und destruktive Pfade.
API-Key-Berechtigungen praktisch konfigurieren
Im Dashboard unter /keys solltest du für jede Umgebung und jeden grösseren Zweck einen eigenen Key anlegen. Das erleichtert Rotation, Revocation und spätere Incident-Analyse. QuantenRam erzeugt beim Einstieg automatisch einen Default key, aber für CI, lokale Entwicklung, Staging oder geteilte Team-Workflows ist ein sprechender Name fast immer die bessere Wahl. Wenn ein Key nur kurz gebraucht wird, setze zusätzlich ein Ablaufdatum und rotiere ihn lieber früh als spät.
{
"name": "CI smoke check",
"scopes": ["inference:chat"]
}Wichtig ist dabei die Disziplin nach dem Anlegen. Alte Keys bleiben nicht einfach liegen, sondern werden rotiert oder deaktiviert, sobald ihr Zweck endet. In QuantenRam sind inaktive oder widerrufene Keys klar vom aktiven Satz getrennt, und genau das sollte sich auch in deiner Teamroutine widerspiegeln.
Modellzugriff und Tierrechte konfigurieren
Modellfreigaben sind kein verstecktes Verhalten des Clients, sondern eine Plattformentscheidung. Im Katalog wird pro Alias festgelegt, welche Tiers Zugriff haben. Dadurch lassen sich Start-, Zenmaster- und Guru-Coder-Wege sauber trennen. Ein Start-Key sieht typischerweise eine andere Aliasmenge als ein Zenmaster- oder Coder-Zugang. Diese Differenz ist gewollt und sollte in deiner lokalen Konfiguration nicht uebergangen, sondern bewusst abgebildet werden.
curl https://quantenram.net/v1/models -H "Authorization: Bearer $QUANTENRAM_API_KEY"Wenn ein Team mit mehreren Tiers arbeitet, lohnt sich eine feste Modellpolitik. Start-Keys dienen als Standard für Routine und Hybrid-Billing im Alltag. Zenmaster-Keys bleiben für hochwertige Review- oder Entscheidungsarbeit reserviert. Guru-Coder- oder Coding-nahe Setups gehen gezielt auf quantenram-coding/*. So wird aus dem Tiermodell eine klare Betriebsstrategie statt bloss eine kaufmännische Einteilung.
Organisationweite Policies festschreiben
Auf Organisationsebene sollte jede Rolle wissen, welche Kombination aus Key, Modellfamilie und Toolrechten für sie vorgesehen ist. Ein einfacher Vertrag reicht oft aus: lokale Entwicklerarbeit mit Start oder Coding, Architektur und Release-Freigaben nur ueber definierte Zenmaster-Pfade, Shell- und Netzwerkrechte nur mit Ask-Grenze, keine geteilten Langzeit-Keys zwischen mehreren Kontexten. Solche Regeln müssen nicht lang sein, aber sie müssen sichtbar, versioniert und in Onboarding-Unterlagen wiederholbar sein.
Auch Hybrid Billing gehört in diese Policy hinein. Wenn Start als kostensensitiver Basispfad gedacht ist, sollten Organisationen nicht durch Gewohnheit alles auf Zenmaster verlagern. Eine gute Permission-Politik ist deshalb immer zugleich eine Kostenpolitik: Wer darf welches Tier standardmässig nutzen, und wann ist eine Eskalation fachlich wirklich begründet?
Die sauberste Access-Control-Strategie für QuantenRam trennt drei Ebenen: kleine API-Keys mit klarem Zweck, Modellzugriff ueber Tiers und eine lokale Allow-Ask-Deny-Policy für reale Workflowrechte.