Fail Open vs Fail Closed für Enterprise AI Agents
Ein Fail-Open vs. Fail-Closed-Framework für KI-Agenten von Unternehmen, die mit veralteten Widerrufsdaten, Replay-Store-Fehlern und Vertrauensausfällen konfrontiert sind.
Fail open vs. fail closed ist die falsche Frage, wenn es als ein globaler Switch behandelt wird. Ein Enterprise AI Agent bittet um 02:13 eine Datenbank-Anmeldeinformationen zu drehen. Das Gateway kann die Anforderungssignatur überprüfen, aber der Vertrauens-Lookup-Service läuft ab. Sein Widerrufs-Cache ist sieben Minuten alt. Der Wiederholungsspeicher hat das Quorum verloren. Das Wartungsfenster endet in 12 Minuten.
Sollte die Aktion laufen?
Dies ist keine einzige Verfügbarkeitsentscheidung. Es sind mehrere Entscheidungen über verschiedene Arten von Staaten: Identität, Autorität, Richtlinie, Widerruf, Wiederholung, Nutzung und Beweise. failOpen: true Switch kann das Risiko nicht ausdrücken.
Die nützliche Designfrage ist: Was ist der minimale Frischzustand, der erforderlich ist, um diese genaue Aktion zu genehmigen, und welche fehlende Abhängigkeit macht die Antwort unerkennbar?
Fail open vs fail closed beginnt mit separaten Flugzeugen
Die Kontrollebene verwaltet langsam wechselnde Objekte und Verwaltung:
- Emittent und wesentliche Veröffentlichung
- Lebenszyklus von Pass und Mandat
- Policy Authoring und Bundle Distribution
- Widerruf
- Trust-Anker-Konfiguration
- Genehmigungsworkflows
Die Datenebene verarbeitet Live-Anfragen:
- Überprüfung der Unterschrift und des Publikums
- Request-Context Binding
- Wiederholungsmeldungen
- deterministische Richtliniebewertung
- Nutzungsreservierung
- Upstream-Ausführung
- Erzeugung von Zertifikaten
Wenn jede Data-Plane-Anfrage einen zentralen SaaS-Service aufruft, wird eine Netzwerkpartition zu einem Geschäftsausfall. Es entsteht auch ein verlockender Bypass: Betreiber unter Druck können das Gateway zur Wiederherstellung des Dienstes deaktivieren.
Lokale Verifizierung vermeidet diese Abhängigkeit, aber sie beseitigt keine Frischefragen. Ein zwischengespeicherter Schlüssel wurde möglicherweise kompromittiert. Ein Mandat wurde möglicherweise widerrufen. Ein Richtlinienpaket wurde möglicherweise ersetzt. Die lokale Durchsetzung muss wissen, wie veraltet jede Eingabe für jede Risikoklasse werden kann.
Klassifizieren von Aktionen vor dem Ausfall
Erfinden Sie während eines Vorfalls kein Ausfallverhalten, sondern legen Sie jede Operation in eine explizite Klasse.
action_classes:
public_read:
materiality: low
trust_unavailable: allow_with_stale_cache
max_revocation_age: 30m
receipt_required: true
internal_sensitive_read:
materiality: medium
trust_unavailable: deny
max_revocation_age: 5m
credential_rotate:
materiality: high
trust_unavailable: deny
replay_unavailable: deny
usage_unavailable: deny
approval_required: true
supplier_payment:
materiality: high
trust_unavailable: deny
reconciliation_unavailable: hold
Die Namen gehören Ihnen. Der wichtige Teil ist, dass das Verhalten eng, überprüfbar und überprüfbar ist. Eine Fail-Open-Regel sollte normalerweise nur risikoarme Lesevorgänge mit begrenzter Datenexposition abdecken. Sie sollte niemals aus einer gefangenen Ausnahme tief in Middleware hervorgehen.
Paket genug Vertrauensstaat für lokale Entscheidungen
Ein signiertes Policy-Bundle kann einem Gateway eine stabile lokale Basis für Entscheidungen geben:
{
"bundle_id": "policy:prod-eu:2026-08-10.4",
"tenant_id": "tenant:acme",
"valid_from": "2026-08-10T00:00:00Z",
"refresh_after": "2026-08-10T00:05:00Z",
"expires_at": "2026-08-10T00:20:00Z",
"trust_anchors": ["oati:issuer:intelliger:root-1"],
"actions": {
"credential.rotate": {
"required_assurance": "production",
"max_proof_age_seconds": 120,
"approval_roles": ["security_on_call"],
"on_trust_unknown": "deny"
}
},
"digest": "sha256:...",
"proof": { "type": "DataIntegrityProof", "...": "..." }
}
Überprüfen Sie das Bündel, wenn es ankommt, speichern Sie es atomar und behalten Sie die letzte bekannte gute Version bis zu ihrem harten Ablauf. refresh_after Sagt dem Gateway, ein neueres Bundle zu suchen. expires_at Sagt es, wenn das Bündel nicht mehr eine gültige Grundlage für die Materialgenehmigung ist.
Diese Unterscheidung ist wichtig. Ein Auffrischungsfehler ist eine Warnung. Ablauf ist ein politisches Ereignis.
Das lokale Paket kann Emittentenketten, Verifizierungsschlüssel, signierte Serviceprofile und einen kompakten Widerrufsstatus enthalten. Private Nutzdaten aus dem Paket heraushalten. Jedes Artefakt unterschreiben oder ein Manifest unterschreiben, das jeden Artefakt verdaut.
Widerrufsfrische ist aktionsspezifisch
Kurzlebige Anmeldeinformationen reduzieren die Exposition, aber sie verhindern nicht den Widerruf: Ein Mitarbeiter kann ausscheiden, ein Agentenschlüssel kann kompromittiert oder ein Mandat kann vor Ablauf widerrufen werden.
Definieren Sie ein maximales Widerrufsalter pro Aktionsklasse: Das Gateway zeichnet auf, wann es zuletzt eine authentifizierte Statusansicht erhalten hat, und nicht nur, wenn ein Cache-Eintrag gelesen wurde.
function revocationUsable(action: ActionClass, cache: RevocationSnapshot, now: Date) {
if (!verifySnapshot(cache)) return false
const ageMs = now.getTime() - Date.parse(cache.observed_at)
return ageMs <= action.maxRevocationAgeMs
}
"Nicht widerrufen" ist eine Aussage mit einer Frischegrenze, keine dauerhafte Eigenschaft. Positive Widerrufe können normalerweise durch das natürliche Verfallsdatum des Objekts zwischengespeichert werden.
Wenn die Konnektivität zurückkehrt, werden die betroffenen Objekte durch die Ziel-ID ungültig gemacht. Das Drehen eines Schlüssels sollte nicht das Löschen des Vertrauens-Caches jedes Mandanten erfordern, aber das Verlassen eines kompromittierten Schlüssels im Prozessspeicher ist schlimmer als ein breiter Cache-Verpass.
Replay Storage ist der Status der Live-Autorisierung
Ein Gateway kann Signaturen und Richtlinien offline verifizieren, aber der Wiedergabeschutz muss koordiniert werden, wenn mehrere Replikate dieselbe Zielgruppe bedienen.
Ein prozesslokales Fallback ist unsicher, es sei denn, das Routing garantiert, dass alle Anfragen für den relevanten Umfang einen Prozess erreichen, und diese Garantie überlebt Failover.
const claim = await replayStore.claim({
key: `${verificationMethod}\0${audience}\0${nonce}`,
expiresAt: proof.expires
})
if (claim === 'duplicate') return deny('REPLAY_DETECTED')
if (claim === 'unavailable') return deny('REPLAY_STATE_UNAVAILABLE')
Bei Lesevorgängen mit geringem Risiko kann eine andere Richtlinie verwendet werden, z. B. ein lokaler begrenzter Cache und ein Antwortmarker.
Ausfallverhalten gehört ins Entscheidungsergebnis
Ein Generikum 503 Service Unavailable Geben Sie eine strukturierte Ablehnung zurück, ohne sensible Infrastrukturdetails offenzulegen:
{
"decision": "deny",
"reason_code": "TRUST_STATE_UNAVAILABLE",
"transaction_id": "urn:oati:txn:01K...",
"retryable": true,
"retry_after_seconds": 30,
"safe_to_retry_with_same_idempotency_key": true,
"correlation_id": "req-7f2c..."
}
Agents sollten nicht immer wieder eine verbotene Aktion versuchen, sie können einen vorübergehenden Vertrauensausfall wiederholen, aber nur mit dem gleichen Business-Idempotenz-Schlüssel.
Geben Sie keine detaillierte Liste der fehlenden internen Dienste an einen nicht vertrauenswürdigen Anrufer zurück.
Partielle Ausführung ist der härtere Ausfall
Das Gateway kann eine Aktion autorisieren, ihre Nutzung reservieren, sie vorab senden und die Konnektivität verlieren, bevor es das Ergebnis erhält.
Modellieren Sie den Zustand explizit:
RECEIVED
-> VERIFIED
-> AUTHORIZED
-> RESERVED
-> DISPATCHED
-> SUCCEEDED | FAILED | UNCERTAIN
-> RECONCILED
Wenn ein versendeter Text unsicher wird, halten Sie sein Budget oder seine einmalige Autorität vorbehalten, fragen Sie das vorgelagerte System unter Verwendung des ursprünglichen Idempotenzschlüssels oder der Anbieterreferenz, fragen Sie das Sprachmodell nicht, ob ein Wiederholungsversuch sicher erscheint.
Sie können eine unterschriebene Quittung ausstellen, die besagt, dass die Anfrage autorisiert wurde und der Versand versucht wurde. Sie können das Geschäftsergebnis nicht wahrheitsgetreu als erfolgreich markieren, bis das vorgelagerte Ergebnis bekannt ist.
{
"result_status": "uncertain",
"authorization_decision": "allow",
"execution": {
"dispatched_at": "2026-08-10T02:13:41Z",
"provider_reference": null
},
"degraded_dependencies": ["upstream_response_path"]
}
Eine Beweisaufzeichnung sollte ein unsicheres Ereignis nicht vollständig aussehen lassen.
Erholung braucht monotone Regeln
Wenn die Kontrollebene zurückkehrt, kann ein neuerer Zustand Annahmen, die während des Ausfalls gemacht wurden, ungültig machen.
Versionen oder Epochen für Policy- und Widerrufs-Snapshots verwenden. Rollback ablehnen, sofern kein autorisierter Rollback-Record existiert. Objektstatus anwenden ändert sich nach Möglichkeit monoton: Ein widerrufenes Mandat sollte nicht aktiv werden, weil ein älterer Cache-Snapshot verspätet angekommen ist.
Dann abgleichen Sie jede Transaktion, die in RESERVED, DISPATCHED oder UNCERTAIN:
- Holen Sie sich das Ergebnis des Anbieters per idempotency Schlüssel oder Referenz.
- Bestätigen Sie den genauen Anfrage-Fingerabdruck.
- Verpflichten oder veröffentlichen Sie die Reservierung gemäß den Richtlinien.
- Ausstellung einer endgültigen Quittung oder eines damit verbundenen Korrekturprotokolls.
- Warnung, wenn kein maßgebliches Ergebnis festgestellt werden kann.
Niemals eine signierte Quittung mutieren, einen neuen signierten Datensatz anfügen, der auf den vorherigen verweist.
Führen Sie Fehlerübungen als Abnahmeprüfungen durch
Unit-Tests für Cache-Helfer sind nicht genug. Üben Sie den gesamten Pfad mit injizierten Fehlern.
| Ausfall | Erwartetes Materialhandlungsverhalten |
|---|---|
| Trust Lookup-Zeiten aus, gültiges lokales Bundle bleibt frisch | lokal bewerten |
| Lokales Bundle verstreicht die Aktualisierungszeit, aber keinen harten Ablauf | nur bewerten, wenn die Handlungspolitik es erlaubt |
| Lokales Bundle ist abgelaufen | Leugnen |
| Widerruf Snapshot übersteigt Aktion Frische | Leugnen |
| Replay Store ist nicht verfügbar | Leugnen vor der Hinrichtung |
| Usage Vergleich-und-Set verliert Rennen | bestehendes Vorhaben ablehnen oder zurückgeben |
| Policy Bundle Signatur fehlschlägt | Reject Bundle, letztes gültiges Bundle behalten, wenn es nicht abgelaufen ist |
| Kontrollflugzeug sendet niedrigere Version | Reject Rollback |
| Upstream-Zeiten nach dem Versand | unsicher markieren und abgleichen |
| Empfängerunterzeichner vor Materialversand nicht verfügbar | Halten oder leugnen |
| Empfängerunterzeichner versagt nach dem Versand | Zeichen Beweis Zustand unsicher und abgleichen, ohne die Aktion zu wiederholen |
| Kontrollflugzeug erholt sich mit einem Widerruf | zukünftige Nutzung ablehnen, Outage-Fenster-Aktionen untersuchen |
Messen Sie mehr als Verfügbarkeit. Notieren Sie, wie viele Aktionen im veralteten Zustand ausgeführt wurden, wie alt dieser Zustand war, wie viele Hinrichtungen unsicher wurden und wie lange die Abstimmung dauerte.
Halten Sie den Notfallpfad innerhalb des Modells
Einige Organisationen brauchen eine kaputte Route. Sie sollte eine stärkere Identität, engere Befehle, einen kurzen Ablauf und separate Beweise verwenden. Das Umgehen des Gateways mit einem gemeinsamen Administrator-Token zerstört die Audit-Kette im Moment, in dem es am wichtigsten ist.
Ein praktisches Notfallmandat kann binden:
- Vorfall oder Änderungsticket
- einen benannten Betreiber und eine verantwortliche Organisation
- Eine Aktion auf eine Ressource
- ein Fünf-Minuten-Fenster
- einen zweiten Genehmiger
- a proofbound temporary credential
- obligatorische nachträgliche Überprüfung
Der Notweg sollte während des normalen Betriebs geprüft werden.
Verwandte technische Anleitungen
- Platzieren Sie das Ausfallverhalten innerhalb des breiteren Enterprise AI Agents Deployment Architektur.
- Verwendung Just-in-Time-Zugriff für AI-Agenten in der Produktion die Fähigkeit zu beschränken, die die Autorisierung überlebt.
- Test verschlechtert Eindeutigkeit garantiert mit der Replay Attack Prevention Guide.
Was OATI heute unterstützt
OATI Entwicklervorschau umfasst lokale Signatur- und Vertrauensüberprüfung, Publikums- und Zeitüberprüfungen, Replay-Schutz, deterministische Mandatsbewertung, zielspezifische Aufhebung und einen Referenz-Envoy-Autorisierungspfad. Lookup und Discovery eine vertikale Schicht einsetzen; signierte Empfangsprimitive können offline überprüft werden.
Der vollständige Produktionsanspruch ist bewusst enger. Ein Produktions-Gateway-Ausfall- und Cache-Ausfall-Bohrer bleibt ausstehend. Der dauerhafte Beweis- und Streitarbeiter ist unvollständig und die unabhängige kryptographische und Protokollüberprüfung ist noch offen. Der Richtlinien-Compiler und der Paketdienst sind Zielzustandskomponenten und kein fertiges Produktions-Subsystem.
Checkliste der Durchführung
- Klassifizieren Sie jede Aktion nach Wesentlichkeit vor dem Einsatz.
- Definieren Sie harte Ablauf und aktualisieren Sie Timing für lokale Vertrauen Artefakte.
- Unterschreiben Sie Bündel und binden Sie jedes enthaltene Artefakt durch Digest.
- Stellen Sie die Widerrufsfrische nach Aktionsklasse ein.
- Verweigern Sie materielle Aktionen, wenn der Status Vertrauen, Wiederholung oder Nutzung unbekannt ist.
- Machen sie jedes fehlgeschlagene verhalten explizit und auf begrenzte lesungen beschränkt.
- Geben Sie strukturierte, retry-bewusste Entscheidungen mit Korrelations-IDs zurück.
- Tragen sie den gleichen idempotenzschlüssel über sichere retries.
- Reservieren Sie Reservierungen nach unsicherem Versand.
- Abstimmung mit dem maßgeblichen vorgelagerten System.
- Fügen Sie Korrekturbeweise anstelle von mutierenden Quittungen hinzu.
- Ablehnung von Richtlinie und Widerruf Rollback.
- Halten Sie die Notfallbehörde eng, kurzlebig und genehmigt.
- Injizieren Sie Lookup, Cache, Replay, Signer und Upstream-Ausfälle in Akzeptanztests.
Das Ziel ist nicht, das Vertrauenskontrollflugzeug unmöglich zu verlieren. Verteilte Systeme bieten dieses Schnäppchen nicht. Das Ziel ist es, jede degradierte Entscheidung vorhersehbar, begrenzt und rekonstruierbar zu machen, bevor ein Ausfall das Problem erzwingt.