Was die Begriffe bedeuten
Jede Prüfung, die in einem Request-Pfad liegt, kann keine Antwort liefern: Eine Abhängigkeit läuft in ein Timeout, ein Signal fehlt, ein Schlüssel kann nicht abgerufen werden. Fail-open bedeutet, dass die Anfrage weiterläuft, als wäre die Prüfung nicht vorhanden. Fail-closed bedeutet, dass die Anfrage den strengeren Pfad nimmt: Sie wird verweigert, herausgefordert oder an eine bereits vorhandene stärkere Kontrolle übergeben.
Keines von beidem ist allgemein richtig. Die passende Wahl hängt davon ab, was die Route tut und was eine falsche Entscheidung kostet.
Warum das für Actor-Checks wichtig ist
Actor-Checks fügen Anfragen Kontext hinzu: ob die Interaktion menschlich wirkt, KI-unterstützt, agentengesteuert oder unbekannt ist. Wenn dieser Kontext nicht verfügbar ist, muss die Anwendung trotzdem reagieren. Zwei Fehlermuster sind häufig:
- Unbeabsichtigtes Fail-closed. Ein Timeout oder ein fehlendes Signal wird als verdächtig behandelt, und echte Nutzer werden bei einer Störung blockiert.
- Unbeabsichtigtes Fail-open bei sensiblen Aktionen. Ein fehlendes Ergebnis wird stillschweigend als menschlich behandelt, und eine Aktion mit hoher Auswirkung läuft mit weniger Prüfung als beabsichtigt weiter.
Beides entsteht, wenn die Wahl implizit bleibt. Die Lösung ist, sie explizit pro Route festzulegen. Unser Beitrag zu Richtlinien auf App-Ebene für Menschen und KI-Agenten zeigt, wie sich das Fehlverhalten in eine Richtlinie pro Route einfügt.
Wie Sie wählen
Ein praktischer Ansatz ist, Routen in Risikostufen einzuteilen:
- Geringe Auswirkung (öffentliche Seiten, Dokumentation, schreibgeschützte Katalog-Routen): Fail-open. Ein fehlendes Actor-Ergebnis sollte nichts verändern.
- Mittlere Auswirkung (Anmeldungen, Formularübermittlungen, Suchen mit Kosten): meist Fail-open mit Protokollierung oder eine leichte Anpassung wie ein Standard-Rate-Limit.
- Hohe Auswirkung (Kontenänderungen, Datenexporte, irreversible Aktionen): Fail-closed zu Ihrer bestehenden stärkeren Kontrolle, etwa erneute Authentifizierung oder Bestätigung. Ziel ist nicht das Blockieren, sondern der Rückgriff auf die Prüfung, die Sie ohnehin verwenden würden.
Definieren Sie dann dasselbe Verhalten für verwandte Fälle:
- Timeout: Die Prüfung hat nicht rechtzeitig geantwortet.
- Fehlende Telemetrie: Die Integration lief nicht oder ein Signal fehlte.
- Unknown: Die Prüfung lief, aber die Evidenz reichte nicht für eine Feststellung aus.
- Veraltete Evidenz: Das Ergebnis stammt aus der Vergangenheit und sollte für eine sensiblere Aktion nicht erneut verwendet werden.
Häufige Missverständnisse
- "Fail-closed ist sicherer." Es verlagert die Kosten auf legitime Nutzer. Bei Routen mit geringer Auswirkung kann ein Fail-closed während eines Vorfalls mehr Schaden anrichten als das Risiko, das es verhindert.
- "Unknown ist ein Fehler." Unknown ist ein gültiges Ergebnis. Es verdient eine eigene explizite Behandlung, die mit Ihrem Timeout-Handling übereinstimmen kann, aber nicht muss.
- "Ein fehlendes Ergebnis bedeutet Mensch." Leiten Sie niemals eine Actor-Klasse allein aus dem Fehlen von Evidenz ab.
Wie Proof of Actor damit umgeht
Proof of Actor weist bei einem Timeout oder einem Unknown-Ergebnis nie Human zu, und die Installation blockiert nichts: Teams beginnen im Observation Mode. Das Fail-open- oder Fail-closed-Verhalten für jede Route und Risikostufe liegt in der Entscheidung des Anwendungsinhabers und wird in Ihrem eigenen Code über Route umgesetzt. So bleibt die Durchsetzung vorhersehbar, und Sie können Ergebnisse prüfen, bevor eine Richtlinie live geht.
Lesen Sie wie Routing-Entscheidungen hier hineinspielen, oder beantragen Sie frühen Zugang.