Zero-Trust

Klassische Zero-Trust-Prinzipien, angewendet auf jede Ressource, jeden Request, jeden Agenten, jedes Tool. Kein implizites Vertrauen, nur weil jemand im VPN ist. Kein „Admin by default“. Jede Entscheidung wird protokolliert.

Die Prinzipien

Niemals vertrauen, immer verifizieren — jeder Request wird auf Ressourcenebene authentifiziert und autorisiert, nicht am Perimeter
Least Privilege — der gewährte Zugriff ist der engste, der die Aufgabe ermöglicht
Explizite Allowlists — Agenten und Tools benötigen konkrete Berechtigungen, keinen impliziten Zugriff dadurch, dass sie sich „innerhalb der Firewall“ befinden
Alles protokollieren — jede Entscheidung ist ein Audit-Ereignis

Wie es für Benutzer gilt

Der Request eines Benutzers zum Lesen eines Dokuments:

Session authentifiziert (SSO-Token verifiziert, MFA falls erforderlich)
Base-Mitgliedschaft geprüft
Collection-Zugriff geprüft
ACL auf Dokumentebene geprüft (einschließlich vererbter Einschränkungen)
Schwärzungsregeln angewendet, wenn die Rolle des Benutzers eingeschränkt ist (z. B. externer Prüfer)
Zugriffsereignis in das Audit-Log geschrieben
Antwort zurückgegeben — oder verweigert, mit einem spezifischen Fehler, der auf die Richtlinie verweist, die den Zugriff blockiert hat

Wie es für Agenten gilt

Agenten sind vollwertige Zero-Trust-Bürger. Ein Agent hat einen expliziten Scope:

Tool-Allowlist — ein Agent kann nur Tools aufrufen, die in seiner Konfiguration aufgeführt sind. Ein Agent ohne send_email in seiner Allowlist kann keine E-Mails senden, selbst wenn er dazu aufgefordert wird.
Knowledge-Scope — ein Agent sieht nur die Collections, die ihm zugewiesen wurden. Ein Recherche-Agent in Base A kann den Korpus von Base B nicht abfragen.
Output-Schema — wenn ein Agent auf ein bestimmtes Output-Schema beschränkt ist, kann er keine beliebigen Freiform-Antworten erzeugen.
Rate-Limits — Aufrufbudgets pro Agent verhindern außer Kontrolle geratene Schleifen.

Abwehr von Prompt Injection

Zero-Trust für Agenten bedeutet, dass ein von einem Angreifer kontrollierter Prompt einen Agenten nicht dazu verleiten kann, Dinge außerhalb seiner Allowlist zu tun:

Ein Agent kann sich nicht selbst per Prompt Injection neue Tools verschaffen — neue Tools erfordern eine Admin-Konfigurationsänderung
Ein Agent kann keine Daten an einen nicht autorisierten Endpunkt exfiltrieren — ausgehende Aufrufe sind auf die Allowlist beschränkt
Ein Agent kann seine Berechtigungen nicht ausweiten, um andere Bases zu lesen — jede Agenten-Instanz ist Base-scoped

Wie es für Tools gilt

Tools — eingebaute und benutzerdefinierte — werden nicht bedingungslos als vertrauenswürdig eingestuft. Jeder Tool-Aufruf:

Verifiziert, dass der aufrufende Agent dieses Tool in seiner Allowlist hat
Wendet Rate-Limits pro Tool an
Führt eine Eingabevalidierung durch (Payload-Größe, Schema-Konformität)
Erfasst den Aufruf im Audit-Log
Wendet eine Schwärzung der Ausgabe an, wenn das Tool Daten zurückgibt, die der Aufrufer nicht sehen darf

Wie es für Workflows gilt

Workflows erben die Berechtigungen des Benutzers oder Agenten, der sie auslöst. Ein Workflow, der drei Tool-Aufrufe durchführt, von denen jeder sensible Daten berührt, schlägt bei Schritt zwei fehl, wenn dem Aufrufer der Zugriff fehlt — er fährt nicht mit veralteter Autorisierung zu Schritt drei fort.

Berechtigungsmodell

Principal	Kann Berechtigungen halten auf…
User	Bases, Collections, Dokumente, Agenten, Workflows, Tools
Group	Dasselbe — Gruppen vererben an Mitglieder
Agent	Knowledge-Scope (read), Tool-Allowlist (execute), Output-Schema
Service Account	Wie ein User — aber nur API, keine interaktive Session
External User	Zeitlich begrenzter, gescopeter Zugriff, kein Default

Richtlinienauswertung

Berechtigungen werden von oben nach unten ausgewertet, wobei ein explizites Deny über einem Allow gewinnt. Die Reihenfolge:

Explizites Deny für diesen konkreten Principal + diese Ressource
Explizites Allow für diesen konkreten Principal + diese Ressource
Von Gruppen vererbte Berechtigungen
Base-Default-Berechtigungen
Deny (implizit)

Session-Verwaltung

Session-Lebensdauer — standardmäßig 12 Stunden, pro Base konfigurierbar
Re-Auth-Auslöser — risikoreiche Aktionen (Datenexport, Konfigurationsänderung) können eine erneute Authentifizierung erfordern
Device-Binding — Sessions können an Geräte-Fingerabdrücke gebunden werden
Kill Switch — Admins können alle aktiven Sessions sofort widerrufen

Zero-Trust auf Netzwerkebene

mTLS zwischen allen internen Diensten
Data-Plane-Isolation pro Tenant
Egress durch explizite Allowlist gesteuert — Agenten können nur konfigurierte Ziele erreichen
Web Application Firewall am Ingress