# Sind Touch-ID-Fallbacks für Agent-Genehmigungen sicher? Touch-ID-Genehmigungsabläufe scheitern auf ganz gewöhnliche Weise: Der Laptopdeckel ist geschlossen, die externe Tastatur ist nicht das richtige Modell, der Sensor erkennt einen Finger nicht oder macOS sperrt die Biometrie nach mehreren Fehlversuchen. Wenn ein Agent daraus einen unklaren Genehmigungsstatus machen kann, hat das System bereits den gefährlichen Fehler begangen. Der Fallback muss eindeutig sagen, ob eine Aktion noch wartet, definitiv abgelehnt wurde oder auf ein eigenes Authentifizierungsereignis wartet. Das klingt zunächst nach einer Aufgabe für die Oberfläche, bis ein Agent eine SSH-Berechtigung hält oder eine authentifizierte API-Anfrage vorbereitet. Dann wird jeder unklare Status zu einem operativen Verhalten. Ein Agent versteht «später erneut versuchen» nicht, wenn das Gateway ihm kein genaues Ergebnis liefert. Auch Menschen treffen schlechte Entscheidungen, wenn das einzige Signal eine hartnäckige biometrische Abfrage und eine Anfrage ist, die möglicherweise noch aktiv ist. Meine Designregel ist einfach: Ein biometrischer Fehler darf eine Anfrage verzögern, aber niemals die Berechtigung erweitern. Ein nicht erreichbarer Sensor darf den Weg zu einer menschlichen Entscheidung ändern, aber den Agenten niemals einen schwächeren Weg wählen lassen. Ein gesperrter Zugangsdaten-Tresor stoppt jede Arbeit mit Geheimnissen, bis sein festgelegtes Tor wieder geöffnet ist. ## Touch-ID-Verfügbarkeit ist nicht dasselbe wie eine Genehmigung Touch ID beantwortet die Frage, ob macOS eine Person in diesem Moment über einen biometrischen Sensor verifizieren kann. Eine Genehmigung beantwortet die Frage, ob diese verifizierte Person diesen Agent-Prozess oder die vorgeschlagene Aktion autorisiert. Wer beides als ein Ereignis behandelt, baut schlechte Fallbacks, weil die Ursachen des Fehlers zu unterschiedlichen Ebenen gehören. Eine sitzungsweite Genehmigung kann eine einfache menschliche Entscheidung sein: Die Person liest die Identität des anfragenden Prozesses und akzeptiert oder lehnt den Lauf ab. Eine Genehmigung pro Aufruf fragt erneut, weil der Besitzer des Zugangsschlüssels gerade diesen Schlüssel als sensibel eingestuft hat. Keine dieser Entscheidungen sagt, dass ein verschlüsselter Zugangsdaten-Tresor verfügbar ist. Der Tresor kann gesperrt sein, der Mac kann am Anmeldefenster stehen oder der physische Sensor nicht erreichbar sein. Sallyport hält diese Trennung praktisch statt nur dekorativ. Sein Tresortor ist absolut: Solange der Tresor gesperrt ist, wird jede Aktion abgelehnt. Sitzungsautorisierung und Schlüssel mit Genehmigung pro Aufruf bestimmen die Berechtigung des Agenten erst, wenn dieses Tor die Aktion zulässt. Eine angenehme Genehmigungskarte kann daher kein Hintereingang an einem gesperrten Tresor vorbei werden. Diese Unterscheidung verhindert auch eine häufige, aber nachlässige Empfehlung: «Wenn Touch ID fehlschlägt, zeige einfach eine normale Genehmigungsschaltfläche.» Das kann für eine menschliche Autorisierungsabfrage richtig sein, die ausdrücklich einen Klick zulässt. Es ist falsch, wenn die fehlgeschlagene Touch-ID-Anfrage den Zugriff auf einen Zugangsdaten-Tresor schützt. Auf demselben Bildschirm können beide Konzepte vorkommen, sie müssen aber unterschiedliche Statusänderungen auslösen. Verwende auch im Agent-Protokoll getrennte Status: - `awaiting_human_approval` bedeutet, dass die Aktion noch nicht ausgeführt wurde und ein Mensch die identifizierte Anfrage genehmigen oder ablehnen kann. - `awaiting_vault_unlock` bedeutet, dass die Aktion nicht fortgesetzt werden kann, weil die Grenze für Geheimnisse geschlossen ist. - `denied` bedeutet, dass das Gateway für diese Anfrage keine Berechtigung aufrechterhält. - `expired` bedeutet, dass die Anfrage zu lange gewartet hat und erneut vorgeschlagen werden muss. Nenne nicht alle vier Status «Genehmigung erforderlich». Diese Formulierung verschweigt die wichtigste Information für den Agenten: ob er warten, stoppen oder eine neue Anfrage vorbereiten soll. ## Der Clamshell-Modus macht den integrierten Sensor unzugänglich Ein geschlossener MacBook-Deckel macht den integrierten Touch-ID-Sensor physisch unzugänglich. Apple nennt den Clamshell-Modus als aktuelles Beispiel für einen nicht erreichbaren integrierten biometrischen Sensor unter macOS: Ein geschlossenes MacBook, das mit einem externen Monitor und einer Tastatur verbunden ist, kann den internen Touch-ID-Sensor nicht nutzen, sofern die externe Tastatur nicht über Touch ID verfügt. Für Menschen, die Coding-Agenten verwenden, ist das kein Sonderfall. Das MacBook steht unter dem Schreibtisch oder neben einem Monitor, weil es lange Zeit eingeschaltet bleibt. Wenn das Genehmigungsdesign voraussetzt, dass jemand den Einschaltknopf erreicht, funktioniert es bei einer Vorführung und scheitert im normalen Alltag. Kläre die Anordnung am Schreibtisch, bevor du den Fallback festlegst: | Physische Anordnung | Touch-ID-Weg | Richtiges Verhalten des Gateways | | --- | --- | --- | | Laptop geöffnet | Integrierter Sensor möglicherweise erreichbar | Biete Touch ID an, sofern die Kontrolle dies zulässt. | | Laptop geschlossen, externe Tastatur ohne Touch ID | Integrierter Sensor nicht verfügbar | Fordere keinen Scan an. Zeige einen vom Kontrollmodell erlaubten Genehmigungsweg oder lehne Arbeit mit Geheimnissen ab, solange der Tresor gesperrt ist. | | Laptop geschlossen, externe Tastatur mit Touch ID | Externer Sensor möglicherweise verfügbar | Biete den Scan erst an, wenn macOS meldet, dass die Biometrie nutzbar ist. | | Laptop geschlossen, Touch-ID-Tastatur getrennt oder ungeladen | Kein nutzbarer biometrischer Weg | Markiere die biometrische Genehmigung als nicht verfügbar und wende dieselbe Regel wie bei jedem nicht verfügbaren Sensor an. | Das wichtige Wort in dieser Tabelle ist «möglicherweise». Dass Hardware vorhanden ist, beweist nicht, dass sie gerade nutzbar ist. Eine kabellose Tastatur kann ausgeschaltet, getrennt, mit einem anderen Computer gekoppelt oder für die aktuelle Benutzersitzung schlicht nicht verfügbar sein. Die Anwendung sollte das Betriebssystem fragen, ob die gewünschte Richtlinie ausgeführt werden kann, bevor sie eine Aufforderung zum Berühren eines Sensors anzeigt. Mache den Clamshell-Modus nicht automatisch zum Grund, eine Aktion von einer Genehmigung pro Aufruf auf eine sitzungsweite Genehmigung herabzustufen. Diese Änderung bleibt über das physische Problem hinaus bestehen und gewährt einen größeren Umfang, als die Person gesehen hat. Wenn die Anfrage eine Entscheidung pro Aufruf braucht, bleibt sie eine Entscheidung pro Aufruf. Zeige eine Klickgenehmigung, falls diese Kontrolle sie erlaubt, oder lasse die Aktion je nach Klasse warten oder fehlschlagen. Es gibt einen praktischen Unterschied zwischen «Eine Person kann nicht scannen» und «Eine Person kann nicht genehmigen». Wer eine gewöhnliche externe Tastatur verwendet, kann eine Karte lesen und eine Genehmigungsschaltfläche anklicken. Das reicht für einen Schlüssel pro Aufruf, der für eine Ein-Klick- oder Touch-ID-Genehmigung ausgelegt ist. Es entsperrt keinen Touch-ID-geschützten Tresor. Auch die Sprache auf dem Bildschirm sollte klar sein: «Genehmigung verfügbar, Tresor gesperrt» ist besser als ein allgemeines rotes Fehlerbanner. ## Ein fehlgeschlagener Scan sollte eine Anfrage halten, keine neue Berechtigung erzeugen Ein einzelner fehlgeschlagener Fingerabdruckscan ist normal. Trockene Haut, ein ungünstiger Fingerwinkel, Rückstände auf dem Sensor und eine hastige Berührung kommen vor. Die richtige Reaktion ist ein begrenzter Wiederholungsstatus, keine sofortige Ablehnung und keine endlos aktive Anfrage. Apples Dokumentation zu LocalAuthentication unterscheidet einen einfachen Authentifizierungsfehler von einer biometrischen Sperre. Ein fehlgeschlagener Berechtigungsnachweis meldet `authenticationFailed`; die Sperre ist nach zu vielen erfolglosen Versuchen ein eigener Status. Das Gateway sollte diese Unterscheidung bewahren, weil die Wiederherstellungswege verschieden sind. Bei einem gewöhnlichen fehlgeschlagenen Scan bleibt die ursprüngliche Aktion für kurze Zeit unverändert und ausstehend. Die Person sollte sehen, was genehmigt wird, welcher Agent-Prozess angefragt hat, welcher Zielhost oder welche API betroffen ist, welches Zugangsdaten-Label gilt und welche konkrete Operation ausgeführt werden soll. Der Agent erhält ein maschinenlesbares Ergebnis «ausstehend» und keinen als Fehler getarnten Timeout. Eine sinnvolle Antwort kann so aussehen: ```json { "status": "awaiting_human_approval", "request_id": "apr_7f3c", "reason": "biometric_retry", "expires_at": "2026-07-22T18:42:00Z", "retry_after_ms": 1500, "action_started": false } ``` Die `request_id` muss an die vollständige vorgeschlagene Aktion gebunden sein, nicht nur an das Zugangsmittel. Wenn ein Agent zunächst `git push` ausführen will und nach dem erneuten Touch-ID-Versuch Remote, Branch oder Befehl ändert, handelt es sich um eine andere Anfrage. Lehne sie ab oder verlange eine neue Genehmigungskarte. Eine Genehmigung wiederzuverwenden, nur weil derselbe Prozess noch existiert, führt zu einem Confused-Deputy-Fehler. Setze zwei Grenzen. Erstens müssen UI-Versuche so begrenzt werden, dass ein fehlerhafter Agent nicht ständig aufdringliche Abfragen öffnen kann. Zweitens muss die ausstehende Anfrage nach einer kurzen, sichtbaren Zeit ablaufen. Wer zehn Minuten später zurückkommt, sollte über eine neu dargestellte Anfrage entscheiden, weil sich Repository-Zustand, API-Nutzlast oder Remotesystem inzwischen geändert haben können. Der Wiederholungsstatus darf keine Zugangsdaten im Agent-Prozess enthalten. Der Agent kann den geplanten Befehl oder den Anfrageinhalt halten, aber das Gateway darf ihm kein Token «während des Wartens» übergeben. Geheimnisse werden erst eingespeist, wenn das Gateway die genehmigte Kanaloperation ausführt. Hier platzieren Teams oft die falsche Wiederholungsschleife am falschen Ort. Sie lassen den Agenten den gesamten Tool-Aufruf alle paar Sekunden erneut versuchen. Das erzeugt doppelte Karten, erhöht die Gefahr wiederholter API-Operationen und bringt dem Modell bei, dass Beharrlichkeit ein Weg an der Zurückhaltung vorbei ist. Das Gateway verwaltet die ausstehende Anfrage. Der Agent wartet auf deren ID oder fragt sie ab. Neue Anfragen erzeugt er erst, wenn die erste abgelaufen oder abgelehnt ist. ## Eine Sensorsperre beendet den biometrischen Weg Eine Sensorsperre ist keine Anfrage, die einen weiteren Fingerabdruck braucht. macOS teilt damit mit, dass die Biometrie deaktiviert ist, bis die vom Betriebssystem geforderte Wiederherstellung erfolgt. Apple dokumentiert `biometryLockout` als Status nach zu vielen fehlgeschlagenen Versuchen und erklärt, dass zum Entsperren der Biometrie ein Passwort erforderlich ist. Für Agent-Aktionen folgt daraus direkt: Beende die Aufforderungen nach Touch ID. Ein Dialog, der nach der Sperre weiter einen Fingerabdruck verlangt, ist irreführend und kann dazu führen, dass Menschen den Sensor immer wieder berühren. Informiere die Person, dass macOS eine Kontauthentifizierung zur Wiederherstellung von Touch ID verlangt, und beende oder pausiere die Gateway-Anfrage je nach Aktionsklasse. Behandle das Kontopasswort nicht stillschweigend als gleichwertig mit Touch ID. Apples Richtlinie `deviceOwnerAuthentication` kann Touch ID, eine gekoppelte Apple Watch in der Nähe oder das macOS-Passwort verwenden. Die Richtlinie für reine Biometrie schlägt dagegen fehl, wenn die Biometrie nicht verfügbar, nicht eingerichtet oder gesperrt ist. Beide Richtlinien sind gültig, sie machen aber unterschiedliche Sicherheitsversprechen. Wenn das Tresortor Touch ID als Zugang festlegt, ändert ein Passwort-Fallback dieses Tor. Du kannst entscheiden, dass ein macOS-Passwort in einem anderen Produktdesign ein zulässiger alternativer Authentifikator ist. Diese Entscheidung muss aber an der Tresorgrenze ausdrücklich festgelegt und umgesetzt werden. Sie darf nicht versehentlich übernommen werden, nur weil ein Framework einen bequemen Standard anbietet. Bei einem an Touch ID gebundenen Tresor sollte die Sperre für jeden aktuell wartenden Aufruf mit Geheimnissen ein endgültiges operatives Ergebnis liefern: ```text status: denied reason: vault_authentication_unavailable recovery: Mit macOS authentifizieren, um Touch ID wiederherzustellen, danach eine neue Anfrage senden action_started: false ``` Das ist bewusst strenger als ein vorübergehend fehlgeschlagener Scan. Die Person muss eine Wiederherstellung außerhalb des Genehmigungsablaufs des Gateways durchführen. Die alte Anfrage währenddessen offen zu halten, erzeugt eine unschöne Unklarheit: Hat die spätere Eingabe des Kontopassworts den ursprünglichen SSH-Befehl genehmigt oder nur den Sensor wiederhergestellt? Die Antwort muss eindeutig sein. Sie hat den Sensor wiederhergestellt. Der Agent muss die Operation erneut anfordern. Bei Genehmigungen, die nicht von der Tresorentsperrung abhängen, kann das Ergebnis anders ausfallen. Eine sitzungsweite Autorisierungskarte kann als Ein-Klick-Entscheidung verfügbar bleiben, wenn ihr Design das zulässt und die Aktion selbst kein geheimes Zugangsmittel aus einem gesperrten Tresor benötigt. Die Oberfläche sollte genau benennen, was fehlgeschlagen ist. «Touch ID gesperrt, Klickgenehmigung weiterhin verfügbar» ist eine klare Meldung. «Authentifizierung fehlgeschlagen» ist es nicht. ## Wartezeit oder Abbruch muss eine Eigenschaft der Aktion sein Entscheide nicht allein anhand des Fehlercodes, ob gewartet werden soll. Berücksichtige die Folgen der Aktion, ihre Anforderungen an Aktualität und den Zustand der Grenze für Zugangsdaten. Derselbe nicht verfügbare Sensor sollte eine harmlose Statusabfrage warten lassen, einen irreversiblen Infrastruktur-Befehl stoppen und eine tresorgestützte Anfrage scheitern lassen, bis der Tresor entsperrt ist. Ich verwende drei Aktionsklassen. ### Klasse eins: kurze menschliche Antwort abwarten Halte eine Aktion nur dann zurück, wenn alle folgenden Aussagen zutreffen: - Das Gateway hat die Operation noch nicht gestartet und keine Zugangsdaten eingespeist. - Die Anfrage hat eine stabile Identität und ein sichtbares Ablaufdatum. - Eine Fortsetzung nach der Genehmigung würde die Person nicht überraschen, weil Ziel und Nutzlast unverändert bleiben. - Die Aktion ist umkehrbar, schreibgeschützt oder ausreichend idempotent, sodass eine kurze Verzögerung ihre Bedeutung nicht verändert. Beispiele sind das Lesen der Version eines privaten Pakets, das Abrufen der Einstellungen eines geschützten Repository-Branches oder eine eindeutig gekennzeichnete Dry-Run-API-Anfrage. Auch hier gehört das Warten ins Gateway und nicht in die Wiederholungsschleife eines Agenten. ### Klasse zwei: stoppen und eine neue Anfrage verlangen Stoppe eine Aktion, wenn eine Verzögerung die praktische Bedeutung des Befehls verändert. Eine Bereitstellung, eine Migration einer Produktionsdatenbank, ein Force-Push, eine Rotation von Zugangsdaten, eine Zahlungserfassung oder ein SSH-Befehl zum Löschen von Daten sollte nicht mit einer latenten Genehmigung herumliegen. Wer die Aktion später sieht, braucht eine neue Karte mit dem aktuellen Kontext. Stoppe ebenfalls, wenn die Anfrage flüchtige Werte enthält. Eine signierte API-Anfrage, ein einmaliges Bereitstellungsartefakt, eine kurzlebige URL oder ein Befehl, dessen lokaler Arbeitsbereich geändert wurde, darf nicht aus einer veralteten Absicht fortgesetzt werden. Das Gateway kann nicht allein daraus schließen, dass der Agent noch dasselbe meint, weil der Prozess noch läuft. ### Klasse drei: sofort ablehnen, weil der Tresor geschlossen ist Ein gesperrter Tresor hat Vorrang vor Bequemlichkeit. Wenn der vorgeschlagene HTTP-Aufruf oder SSH-Befehl ein gespeichertes Geheimnis benötigt und das Tresortor gesperrt ist, lehne die Aktion ab, statt sie für eine automatische Ausführung nach dem Entsperren einzureihen. Die Person kann den Tresor entsperren, danach sendet der Agent eine neue Anfrage. So bleibt die Ursache klar: erst entsperren, dann vorschlagen, zuletzt ausführen. Hier bewährt sich Sallyports feste Entscheidungskette. Das Tresortor lehnt jede Aktion im gesperrten Zustand ab. Danach greifen Sitzungsautorisierung und Genehmigung pro Aufruf. Keine Richtlinie versucht zu erraten, ob ein verzögertes `curl` harmlos genug ist, um es nach einem biometrischen Ereignis wiederzubeleben. Die verlockende Alternative ist eine Ausführungswarteschlange, die aufwacht, sobald die Person den Sensor berührt. Das wirkt in Vorführungen reibungslos. Im Alltag macht es die Authentifizierung jedoch zum Auslöser für Arbeit, die möglicherweise nicht mehr beabsichtigt ist. Eine Genehmigung sollte eine Anfrage freigeben, die die Person noch sehen kann, nicht einen während ihrer Abwesenheit aufgebauten Rückstand abarbeiten. ## Für externe Touch-ID-Tastaturen ist eine Verfügbarkeitsprüfung nötig Eine externe Touch-ID-Tastatur löst ein Clamshell-Problem, fügt aber eine weitere Abhängigkeit hinzu. Die Tastatur muss während der Genehmigung in der aktiven Mac-Sitzung vorhanden und nutzbar sein. Behandle das als aktuelle Bedingung und nicht als einmalig festgestellte Einrichtung. Zu den Fehlern von Apples LocalAuthentication gehören `biometryDisconnected` und `biometryNotPaired` für entfernbare biometrische Zubehörgeräte. Diese Codes sind wichtig, weil sie fehlende Hardware von einer Person unterscheiden, die sich nicht authentifizieren konnte. Eine getrennte Tastatur darf keinen Wiederholungsversuch verbrauchen und nicht zur Fehlerquote des Benutzers beitragen. Oberfläche und Protokoll sollten auf vier Zustände unterschiedlich reagieren: | Zustand | Was die Person sieht | Was der Agent erhält | | --- | --- | --- | | Sensor bereit | Eine klare Anfrage und ein Touch-ID-Element | `awaiting_human_approval` | | Sensor im Clamshell-Modus unzugänglich | Eine Erklärung, dass der integrierte Sensor nicht erreichbar ist | `approval_path_unavailable` oder ein erlaubter Klickweg | | Externer Sensor getrennt | Eine Aufforderung, die Tastatur anzuschließen, zu laden oder die erlaubte alternative Genehmigung zu verwenden | `approval_path_unavailable` | | Scan abgewiesen | Dieselbe unveränderliche Anfrage und ein Hinweis zum Wiederholen | `awaiting_human_approval` mit `biometric_retry` | Zeige der Person keine rohen Framework-Fehlernamen, bewahre sie aber im lokalen Aktivitätsprotokoll auf. «Externe Touch-ID-Tastatur nicht verfügbar» hilft. `LAError.biometryDisconnected` gehört in Diagnosen und Tests. Die Genehmigungskarte muss auch ohne Sensor bedienbar bleiben. Das ist eine Sicherheitsfrage und zugleich eine grundlegende Frage der Benutzbarkeit. Maus, Trackpad, Tastaturfokus und Bedienungshilfen sollten weiterhin ermöglichen, eine Anfrage abzulehnen oder eine erlaubte Klickgenehmigung auszuwählen. Ein nicht zugänglicher biometrischer Sensor darf niemanden in einer nicht beantwortbaren Abfrage festhalten. ## Die Genehmigungsoberfläche muss die blockierte Grenze benennen Die meiste Verwirrung entsteht durch ein einziges allgemeines Dialogfenster, das jede Form der Authentifizierung darstellen soll. Teile die Meldung nach der Grenze auf, auf die gewartet wird. Bei einer sitzungsweiten Anfrage zeigst du zuerst die Codesignatur-Berechtigung des anfragenden Prozesses und gibst der Person eine klare Möglichkeit zum Genehmigen oder Ablehnen. Hier entscheidet der Mensch, ob dieser Agent-Lauf arbeiten darf. Wenn Touch ID verfügbar ist, kann es die Wahl bestätigen. Wenn das Design einen Klick zulässt, darf der Clamshell-Modus die Karte nicht zu einer Sackgasse machen. Bei einem Schlüssel mit Genehmigung pro Aufruf zeigst du die genaue Aktion und das Zugangsdaten-Label. Eine Ein-Klick-Genehmigung bleibt nur dann eine Entscheidung pro Aufruf, wenn sie für eine unveränderliche einzelne Anfrage gilt und schnell abläuft. Lass einen Agenten nicht fünf Aufrufe hinter einer Schaltfläche bündeln, nur weil Touch ID an diesem Schreibtisch unbequem ist. Bei einem gesperrten Tresor muss dort stehen, dass der Tresor gesperrt ist und die Aktion nicht gestartet wurde. Stelle die Meldung nicht als abgelehnte Agent-Anfrage dar, weil die Person sonst annehmen könnte, sie müsse nur noch einmal klicken. Die Wiederherstellung gehört zum festgelegten Authentifizierungsmechanismus des Tresors. Sobald er geöffnet ist, muss für jede Aktion, die das Geheimnis benötigt, eine neue Anfrage gestellt werden. Ein gutes Audit-Protokoll trennt diese Übergänge. Zum Beispiel: ```text 2026-07-22T18:40:12Z request.created id=apr_7f3c channel=ssh action="git push origin main" 2026-07-22T18:40:13Z approval.pending id=apr_7f3c method=touch_id 2026-07-22T18:40:16Z biometric.failed id=apr_7f3c source=built_in_sensor 2026-07-22T18:41:02Z request.expired id=apr_7f3c action_started=false ``` Das Aktionsprotokoll darf einen fehlgeschlagenen Scan nicht als Autorisierungsablehnung ausgeben. Es war ein fehlgeschlagener Authentifizierungsversuch. Die Anfrage lief ohne Ausführung ab. Diese Begriffe sind bei einer Prüfung wichtig, besonders wenn ein Agent behauptet, er habe «nicht bereitstellen können» und ein Betreiber wissen muss, ob das System ihn blockiert hat, die Person abgelehnt hat oder niemand die Abfrage abgeschlossen hat. Bei manipulationssicheren Auditsystemen muss der Statusübergang aufgezeichnet werden, bevor er an den Agenten zurückgegeben wird. Sallyport erstellt seine Sessions- und Activity-Journale aus einem einzigen verschlüsselten, Hash-verketteten Log. Der Befehl `sp audit verify` prüft diese Kette offline über den Chiffretext. Ein späterer Prüfer erhält so Belege dafür, dass eine Anfrage abgelaufen oder abgelehnt worden ist, ohne dem eigenen Protokoll des Agenten vertrauen zu müssen. ## Teste den physischen Schreibtisch, nicht nur die API im Erfolgsfall Ein LocalAuthentication-Unit-Test, der Erfolgs- und Fehlercodes zurückgibt, ist nötig, sagt über einen Genehmigungsablauf aber fast nichts aus. Die Fehler, die Menschen frustrieren, entstehen dort, wo Hardwareanordnung, Desktop-Zustand und Timing des Agenten zusammentreffen. Führe diese Testfolge auf einem echten Mac aus, bevor du den Ablauf als fertig erklärst: 1. Starte eine Agent-Sitzung bei geöffnetem Laptop, sende eine Anfrage pro Aufruf, lehne sie ab, sende danach eine neue Anfrage und genehmige sie. Bestätige, dass die abgelehnte Anfrage nie ausgeführt wird. 2. Schließe den Deckel und verbinde einen externen Monitor sowie eine Tastatur ohne Touch ID. Bestätige, dass die Oberfläche nicht zum Berühren eines unerreichbaren Sensors auffordert. Teste eine genehmigungsfähige Klickanfrage und eine Anfrage mit Zugangsdaten aus dem Tresor. 3. Wiederhole den Test mit einer funktionierenden externen Touch-ID-Tastatur. Trenne sie oder schalte sie aus, während eine Genehmigung wartet. Bestätige, dass die Anfrage nicht verfügbare Hardware und keinen fehlgeschlagenen biometrischen Versuch meldet. 4. Löse wiederholt erfolglose Scans aus, bis macOS die Sperre aktiviert. Bestätige, dass biometrische Abfragen enden, Anfragen mit Geheimnissen nicht zur späteren Ausführung eingereiht werden und die Wiederherstellung eine neu eingereichte Aktion erfordert. 5. Lass eine wartende Anfrage ablaufen. Ändere Branch, Befehlsargumente oder API-Nutzlast, bevor du eine neue Anfrage sendest. Bestätige, dass der neue Vorschlag eine andere Anfrage-ID und eine neue menschliche Entscheidung erhält. Prüfe die Logs nach jedem Durchlauf. Zu sehen sein sollten ein Ereignis für die Anfrageerstellung, eine Folge von Statusänderungen und entweder genau ein Ausführungsereignis oder keines. Mehrere Ausführungen nach einem einzigen Genehmigungssignal weisen auf einen Replay- oder Wiederholungsfehler hin. Ein fehlendes Abschlussereignis zwingt den Support zu raten, ob der Agent noch wartet. Teste außerdem den Abbruch. Die Person muss ablehnen können, wenn Touch ID nicht verfügbar ist. Der Agent muss eine wartende Anfrage aufgeben können, und das Beenden der Anwendung muss aktive Genehmigungen ungültig machen. Apple unterscheidet in LocalAuthentication Benutzer-, Anwendungs- und Systemabbruch. Dein Auditmodell sollte diese Unterscheidung bewahren, auch wenn die Oberfläche sie unter der verständlichen Meldung «abgebrochen» zusammenfasst. Ein verlässlicher Fallback fühlt sich fast langweilig an, wenn er funktioniert. Der Bildschirm sagt die Wahrheit über den Sensor, der Agent erhält einen Status, dem er folgen kann, Geheimnisse bleiben im Tresor, und keine Aktion entkommt, nur weil jemand einen Laptopdeckel geschlossen hat. Das ist der Maßstab: Jeder physische Fehler führt zu einem konkreten Ergebnis, das keine Berechtigung erweitert.