Geführtes Sicherheitslab

Menschliche Freigabe

Eine geführte Übung dazu, wann eine menschliche Freigabe informiert, aktionsspezifisch, aktuell, authentifiziert und sicher gebunden ist: Exact-Action-Bindung, Nachweise für Prüfende, veraltete Freigaben nach wesentlichen Änderungen, vom Modell verfasste Freigabebehauptungen und feste Batch-Prüfung.

Konzeptionelle SimulationAdvanced15 Minuten2026-09-26

Konzeptionelle Simulation

Diese Übung verwendet redaktionell festgelegte, deterministische Beispiele mit fiktiven Namen und neutralen synthetischen Inhalten. Sie ruft keine Tools, APIs, Agenten oder Modelle auf und sagt nicht voraus, wie sich ein reales Modell oder System verhält.

Schritt 3 von 63/6

Lernziele

Menschliche Freigabe von deterministischer Autorisierung und Fähigkeit unterscheiden.
Die maßgeblichen anwendungsseitigen Nachweise für eine informierte Prüfung erkennen.
Freigabe an die vollständig aufgelöste exakte Aktion binden statt an eine allgemeine Absicht oder einen Tool-Namen.
Vom Modell verfasste Freigabebehauptungen und Begründungen als variablen Inhalt erkennen, nicht als Befugnis.
Veraltete Freigaben nach wesentlichen Parameter- oder Zustandsänderungen erkennen und Neubewertung und erneute Freigabe verlangen.
Identität, Berechtigung und Funktionstrennung der prüfenden Person anhand der Anwendungs-Policy bewerten.
Verstehen, wann ein aufgezählter fester Batch sicher geprüft werden kann und warum eine pauschale Freigabe künftiger Ketten nicht gleichwertig ist.
Freigegeben, autorisiert, ausgeführt, erfolgreich, fehlgeschlagen, abgebrochen, abgelaufen und unbeobachtet auseinanderhalten.

Voraussetzungen

Lab Agentenautorisierung (empfohlen)
Lab Tool-Chain-Analyse (empfohlen)

Szenario wählen

Jedes fiktive Szenario zeigt, was das Modell vorschlägt, und getrennt davon Aktionsdatensatz, Policy, prüfende Person und Freigabeereignisse, die die Anwendung erfasst. Sie beurteilen, ob eine erfasste Freigabe für die exakte Aktion gültig ist.

Exakte Freigabe einer ErstattungDer Agent schlägt eine Erstattung von 40 synthetischen Credits für Bestellung O-204 auf das verifizierte ursprüngliche Zahlungsmittel vor. Die deterministische Autorisierung erlaubt genau diese Erstattung bereits; die Policy verlangt zusätzlich eine menschliche Freigabe für Erstattungen über 25 Credits.Generische Tool-BestätigungDer Agent schlägt ein routinemäßiges internes Status-Update vor. Der Prüfdialog fragt nur "send_mail erlauben?" und zeigt eine vom Modell verfasste Begründung, obwohl der vorgeschlagene Aktionsdatensatz Empfänger, Anhang, Datenklasse und Nebenwirkungen enthält.Wesentliche Änderung nach der FreigabeEin Prüfer hat eine Erstattung von 40 synthetischen Credits für Bestellung O-305 auf das verifizierte ursprüngliche Zahlungsmittel freigegeben, gebunden an Aktionsversion v1. Vor der Ausführung ändert sich der vorgeschlagene Betrag in Version v2 auf 60 Credits.Vom Modell verfasste FreigabebehauptungDer Agent schlägt vor, den Status eines fiktiven Konto-Workflows zu ändern. Sein Vorschlag enthält die Notiz, der Nutzer habe bereits zugestimmt, aber der Freigabespeicher enthält keine authentifizierte menschliche Entscheidung für genau diese Aktion. Der Nutzer ist angemeldet.Freigabe eines aufgezählten festen BatchesDer Agent schlägt vor, genau drei abgeschlossene synthetische Berichtsentwürfe zu archivieren: R-17, R-18 und R-19. Die Policy verlangt eine Freigabe für Archivierungs-Batches mit mehr als zwei Einträgen. Die Anfrage zeigt die vollständige Liste und eine aus dem gebundenen Aktionsdatensatz erzeugte Vorschau.

Freigabepfad und Vertrauensfluss

Deterministische Policy entscheidet, ob eine Prüfung nötig ist, das Modell schlägt eine Aktion mit Begründung vor, die Anwendung löst den exakten Aktionsdatensatz auf und speichert authentifizierte Entscheidungen. Vorschlag und Begründung bleiben variabler Inhalt.

Deterministische Freigabe-PolicySystemkomponente->
ModellSystemkomponente->
Vorschlag und BegründungVariabler Inhalt->
Exakter AktionsdatensatzSystemkomponente->
Authentifizierter FreigabespeicherSystemkomponente->
Durchsetzung bei Ausführung (separat)Systemkomponente

Modellsichtbarer Vorschlag und Begründung

Was das Modell liest oder schreibt. Es ist kein Freigabenachweis.

Nutzeranfrage
Bitte Bestellung O-204 erstatten, der Artikel kam beschädigt an.
Begründung des Modells
Die Schadensmeldung passt zur Bestellung; eine volle Erstattung von 40 Credits erscheint angemessen.

Von der Anwendung erfasste Freigabenachweise

Aufgaben- und Lauf-IDs, Principal, handelnder Agent, exakte Aktionsversion, Policy und Risikostufe, gebundene Felder, wesentlicher Zustand, Identität und Berechtigung der prüfenden Person, Freigabeereignisse und Ausführungsstatus, erfasst außerhalb des Modelltexts.

Aufgabe und Lauf: Aufgabe t-204, Lauf r-204a; initiierender Principal support-user-ana; handelnder Agent refund-agent-2
Exakte Aktion: act-204 v1: refund(Bestellung O-204, Betrag 40, Ziel verifiziertes ursprüngliches Zahlungsmittel)
Policy und Risikostufe: approval-policy v7: Erstattungen über 25 Credits erfordern Prüfung; Stufe R2; deterministische Autorisierung für act-204 v1: erlaubt
Wesentlicher Zustand: O-204 zugestellt, keine frühere Erstattung, Erstattungsfenster offen
Prüfende Person und Berechtigung: Prüfer lead-omar, authentifiziert; berechtigt für Stufe R2; nicht der initiierende Principal
Freigabeereignis: act-204 v1 am 2026-09-26 um 10:14 UTC mit angezeigten gebundenen Feldern freigegeben; seitdem kein Feld geändert
Ausführungsstatus: Ausstehend; nicht ausgeführt