Gebaut in der Annahme, dass sich das Modell täuschen lässt.

01

Ein Tor für jeden Aufruf

Jeder Tool-Aufruf läuft durch ein einziges Modul, den Tool Guard: aus dem Chat, von Agenten, beim Aktualisieren eines Widgets und von externen Clients. Seine Prüfungen sind eine Liste benannter Funktionen. Die erste, die scheitert, stoppt den Aufruf. Erlaubt ist nur, was ausdrücklich erlaubt wird.

Bei einem abgelehnten Aufruf kann ein Admin nachfragen, warum. shift prüft den Aufruf wie einen Chat-Aufruf gegen die heutigen Server, Tools und Berechtigungen und zeigt, welche Prüfung ihn stoppt.

Eine Prüfung im Build lässt den Code der Anwendung MCP-Server, Modell-Anbieter und das Web nur über wenige dafür bestimmte Module erreichen. So rutscht kein neuer Weg nach aussen unbemerkt durch das Review.

02

Eine Person gibt genau diesen Aufruf frei

Ein Admin prüft jedes Tool eines Servers, bevor es jemand nutzen kann, und gibt ihm eine von vier Stufen. Read-only-Tools laufen. Sensitive Tools, die private Daten zeigen, und Tools, die etwas verändern, warten jedes Mal auf eine Freigabe. Blockierte Tools werden dem Modell nie angeboten.

Die Freigabe zeigt die genauen Argumente, in voller Länge, versteckte Steuerzeichen ausgeschrieben. Sie geben diesen Aufruf frei, einmal. Freigeben kann nur die Person, für die der Aufruf läuft; Admins können ihn ablehnen oder abbrechen. Eine Freigabe verfällt im Chat nach einer Stunde und bei Agenten nach 24 Stunden; verfallen heisst abgelehnt.

{
  "namespace": "shift-demo",
  "name": "podinfo-6b7f9d8c4-x2kqp",
  "previous": true
}

03

Keine Änderung läuft zweimal

Jeder Aufruf wird in einem Ledger festgehalten, nach Lauf und Aufruf-ID, bevor er hinausgeht. Stürzt shift ab, nachdem ein Aufruf gelaufen ist, aber bevor das Ergebnis gespeichert war, verhindert das Ledger, dass ein Aufruf, der etwas verändern kann, ein zweites Mal hinausgeht; ein Read-only-Aufruf läuft einfach noch einmal. Ist bei einem verändernden Aufruf unklar, ob er gelaufen ist, erfährt das Modell «outcome unknown, do not retry», und das Audit-Log markiert den Fall.

Jeder Lauf hat ein Token-Budget und eine Obergrenze für Tool-Aufrufe. Abgelehnte Aufrufe zählen mit.

04

Jeder Schritt festgehalten

Jeder Tool-Aufruf, auch jeder abgelehnte, jede Freigabe und jede Admin-Änderung landet in einem Log, das sich nur ergänzen lässt. Der Eintrag eines Aufrufs nennt, wer ihn freigegeben hat, unter welcher Identität er lief, den Hash der Tool-Definition und die Argumente, mit Geheimnissen nach Schlüsselnamen geschwärzt.

Admin-Änderungen wie Berechtigungen, Stufen, Rollen, Server, Schlüssel und Shortcuts werden in derselben Datenbank-Transaktion wie die Änderung selbst erfasst. Eine Änderung ist protokolliert, oder sie hat nicht stattgefunden.

Ein Datenbank-Trigger verweigert UPDATE, DELETE und TRUNCATE auf dem Log. Export als JSON Lines für Ihr SIEM oder Ihre Revision.

05

Ihr Identity Provider entscheidet, wer hineinkommt

shift meldet Personen mit OpenID Connect an (nur Claims aus dem ID-Token, PKCE, State und Nonce, bei jeder Anmeldung eine bestätigte E-Mail-Adresse) oder mit Magic Links. Ein Modus nur mit SSO schaltet Magic Links ab. SCIM-2.0-Provisioning überträgt Personen und Gruppen: Wer im Identity Provider entfernt wird, verliert den Zugang innert Minuten.

Es gibt zwei Rollen: Admins verwalten Server, Tools, Gruppen und Personen; Benutzer chatten, verbinden ihre Konten und besitzen Agenten. Eine Rolle allein gibt kein Tool frei: Auch ein Admin braucht eine Berechtigung. Gespräche sind privat, auch gegenüber Admins. Admins haben das Audit-Log.

Live getestet mit pocket-id und Dex. Mit Microsoft Entra funktioniert SCIM teilweise.

06

Ihr eigener KI-Client, nach denselben Regeln

shift ist auch ein MCP-Server unter /mcp, für den eigenen Client einer Person, etwa Claude Code. Er ist aus, bis ein Admin ihn einschaltet, und dann ist jedes Tool aus, bis ein Admin es zulässt. Angeboten werden nur Read-only-Tools; ein Aufruf, der eine Freigabe bräuchte, wird abgelehnt. Clients melden sich per OAuth an, mit Tokens, die zehn Minuten gelten, oder mit einem persönlichen Schlüssel für den Betrieb ohne Browser. Jeder Aufruf wird mit Name und Adresse des Clients protokolliert.

07

Geheimnisse bleiben, wo sie hingehören

Schlüssel für Modell-Anbieter und gemeinsame Server-Zugangsdaten liegen mit AES-GCM verschlüsselt in der Datenbank. Optionen mit einem Schlüssel werden nie mit einem Job gespeichert. Log-Zeilen enthalten IDs, Zähler, Dauern und Fehlerklassen, nie Geheimnisse oder Personendaten.

Im Browser gelten eine strikte Content Security Policy mit neuem Nonce pro Anfrage, keine Bilder aus Modell-Antworten und Links nur zu shift und den genutzten Servern. So kann eine präparierte Antwort keine Daten über ein Bild hinausschleusen.

08

Private Adressen nur mit Namen

Ein MCP-Server an einer privaten Adresse braucht einen Admin, der den genauen Host und seine Adressbereiche nennt: nicht grösser als /8, kein Link-Local, keine Metadaten-Adressen von Clouds. Die Adresse eines Servers lässt sich später nicht ändern, damit gespeicherte Zugangsdaten nie an eine neue Adresse gehen. Jeder MCP-Tool-Aufruf landet im Audit-Log, und Anfragen an Ihren Identity Provider werden protokolliert, Werte, die nach Zugangsdaten aussehen, gefiltert.

09

Ein Image, auf Ihrer Infrastruktur

shift kommt als ein Container-Image mit Helm-Chart, eine Installation pro Kunde, nur für diesen Kunden. Es läuft ohne Root-Rechte auf einem schreibgeschützten Root-Dateisystem. Das Chart aktiviert standardmässig eine NetworkPolicy, und Geheimnisse kommen aus einem bestehenden Kubernetes Secret oder aus External Secrets, nie aus den Chart-Werten.

Antworten und Agenten-Läufe sind Jobs in der Datenbank. Sie überstehen einen Neustart.

Wir haben Job, Tool-Schleife, Tool Guard, Ledger und Audit gegen einen geskripteten Angreifer getestet: ein Fake-Modell, das eine vorbereitete Reihe verbotener Aufrufe machte. Der Tool Guard lehnte jeden davon ab.

10

Ein Problem gefunden?

Schreiben Sie uns. Wir antworten aus Bern. hello@zebbra.ch

Schwachstelle melden