Zum Inhalt springen
Quark

produkte · foundation

Die Schicht, auf der alles steht.

Foundation ist kein Add-on: Identity, Secrets, Access, Metering und Quotas kommen mit jedem Deployment — und jedes Produkt läuft vom ersten Call an auf ihnen.

identity

Orgs, Projekte und Keys, die alles einordnen.

Das Tenancy-Modell ist einfach genug, um es in einem Atemzug zu erklären, und streng genug, um ein Geschäft darauf zu bauen.

Organisationen stehen oben

Jedes Projekt gehört zu einer — die Grenze für Eigentum und Mitgliedschaft.

Projekte ordnen die Arbeit

API-Keys, Modell-Sichtbarkeit und jede Ressource, die Sie anlegen, leben in einem Projekt. Teams bekommen eigene Spuren; niemand borgt die Credentials eines anderen.

API-Keys werden genau einmal gezeigt

Bei der Erstellung, und nie wieder — die Konsole zeigt nur ein Anzeigepräfix, das nie authentifizieren kann. Widerruf ist ein Klick, und sofort wirksam.

Service-Accounts für die Workloads

Läufe und Automatisierungen bekommen eine eigene Identität, sodass „wer hat das getan“ immer eine Antwort hat.

secrets

Einmal geschrieben, nie gezeigt.

Die Credentials, die KI-Workloads antreiben — Modell-API-Keys, Verbindungs-Strings, Tokens — sind genau die Werte, die in Tickets und Chat-Threads landen. Secrets sind gebaut, das unmöglich zu machen.

Der Wert wird genau einmal angezeigt

Bei der Erstellung, mit bewusster Bestätigung — dann ist er versiegelt. Nicht einmal die Konsole kann ihn wieder zeigen.

Grants, keine Sammeltöpfe

Jedes Secret ist auf die Workloads begrenzt, die es erhalten dürfen. Ein Lauf bekommt ein Secret, weil ihm genau dieses gewährt wurde — mit Namen.

Versionen, nicht Überschreiben

Rotieren durch Hinzufügen einer neuen Version; Konsumenten folgen dem Secret, nicht einer Kopie.

Ein Audit-Trail, den Sie lesen können

Jedes Create, Version, Grant, Revoke und jede Auslieferung — für das ganze Projekt, in Reihenfolge.

für Ihre Security-Reviewer

Upstream-Credentials existieren nie als Klartext in Configs, Env-Dateien oder CI-Variablen — nur als versiegelte Werte mit benannten Grants und einer vollständigen Audit-Historie.

access

Least Privilege, mit einem Veto.

Autorisierung in Quark ist einfach genug, um sie in einem Meeting zu reviewen.

Rollen sind benannte Aktionsmengen

Gewährt für Personen und Service-Accounts — die Allow-Seite der Geschichte.

Policies sind explizite Allow- und Deny-Regeln

Ein passendes Deny setzt alles andere außer Kraft, unabhängig von Rollen. Wenn Sie „nie“ sagen müssen, meint die Plattform es so.

Sinnvolle Voreinstellungen

Eine vernünftige Basis lässt das Projekt atmen; alles Sensible ist einen expliziten Grant vom Sperren entfernt.

Least Privilege von Grund auf

Workloads erhalten genau die Secrets und Berechtigungen, die ihnen gewährt wurden — und sonst nichts, nirgendwo auf der Plattform.

darunter

Ein Substrat, gebaut für Vertrauen.

Die Governance-Ebene steht auf einem Substrat, das gebaut wurde, um vertrauenswürdig zu sein.

Authentifizierter Transport auf jeder Ebene

Plattform-Services authentifizieren sich gegenseitig über verschlüsselten Transport, Workloads tragen eigene Identitäten, und Konsole wie API-Clients sprechen Keys und Tokens.

Workloads haben eigene Identitäten

Plattform-Services verifizieren, wer fragt — nicht nur, welcher Key gezeigt wurde.

Jeder Request wird gegen die Tenancy geprüft

Isolation wird bei jedem Aufruf erzwungen, nicht aus der Netzwerkposition heraus angenommen.

Gehärtete Ausführung, wenn es zählt

Für Workloads mit strengeren Anforderungen können Läufe gehärtet oder vertraulich sein — Isolation ist ein Regler, kein Fork.

metering

Metering by default.

Nutzung wird nicht gesampelt oder geschätzt; sie wird von den Produkten beim Servieren emittiert.

Nach Key

Jede Completion über das Gateway wird dem API-Key zugeordnet, der sie ausgelöst hat. Teams, Produkte und Kunden bekommen eigene Keys — und ihre eigene antwortfähige Spalte im Ledger.

Nach Produkt

Gateway-Aufrufe, Sandbox-Zeit, Index-Builds und der Rest rollen getrennt auf. Wenn sich Spend bewegt, wissen Sie, welches Produkt ihn bewegt hat.

Nach Metrik

Requests, Tokens und die eigenen Arbeitseinheiten der Plattform, jeweils für sich erfasst — keine verwässerten „Einheiten“, die nichts erklären.

Aufgerollt, immer sichtbar

Spend- und Usage-Summaries leben auf der Startseite der Plattform, nicht versteckt in einem Export.

quotas

Quotas, die wirklich durchsetzen.

Ein Budget, das nur berichtet, ist ein Newsletter. Quotas werden dort erzwungen, wo Nutzung anfällt.

Cap pro Metrik setzen, in rollendem Fenster

Für einen Key, ein Produkt oder das ganze Projekt.

Warnung, direkt sichtbar

Jedes Quota zeigt seinen Zustand — gesund, nahe am Cap oder überschritten — mit Headroom als Balken, den man auf einen Blick liest.

Harte Stopps am Nutzungspunkt

Wenn ein Quota erschöpft ist, wird weitere Nutzung abgelehnt, bis das Fenster weiterrollt. Ausufernder Spend wird von der Plattform gestoppt, nicht von wem auch immer gerade wach ist.

Mit Gateway-Limits koppeln

Pro-Key-Caps für Requests und Tokens geben Ihnen einen zweiten Durchsetzungspunkt genau dort, wo Modell-Spend entsteht.

für die Person, die die Rechnung freigibt

Jedes Team kann eigene Keys und eigene Quotas haben — und das Experiment eines Teams kann nie still zur Firmenrechnung werden.

die fragen

Gebaut für die Fragen, die Sie wirklich stellen.

Was hat uns dieser Kunde in diesem Fenster gekostet?

Nutzung nach Key, auf einer Seite.

Warum ist unsere Rechnung gesprungen?

Nutzung nach Produkt, auf derselben Seite.

Stehen wir kurz vor dem Cap?

Quota-Zustände mit Headroom, ohne Export.

Können wir dem Skript des Praktikanten eine Obergrenze geben?

Ja — ein Quota ist nur ein paar Felder entfernt.

kontakt

Sprechen Sie mit uns über Quark im Einsatz.

Erzählen Sie uns von Ihren Workloads — wir zeigen Ihnen, was Ihre eigene Cloud kann.