RT-01
Durchsetzungspfad und Bypass
Gilt mit benannten EinschränkungenStoppt eine verweigerte Entscheidung die Aktion auf jedem vorgesehenen Pfad?
Verfahren
- 01Rufen Sie den folgenreichen Tool-Aufruf über den vorgesehenen gesteuerten Pfad mit einer blockierenden Policy auf; bestätigen Sie, dass sich der Zustand des Geschäftssystems nicht geändert hat.
- 02Versuchen Sie dieselbe Aktion über jeden alternativen, von der Architektur zugelassenen Pfad: direkte API-Aufrufe, sekundäre Integrationen und Bedienkonsolen.
- 03Lassen Sie den Anbieter die exakte Komponente nennen, die jeden Pfad durchsetzt, sowie das Team, das ihre Konfiguration besitzt.
Von jeder gesteuerten Plattform erwartet
Ein Ergebnis block oder require_approval verhindert den Seiteneffekt auf dem gesteuerten Pfad; der Anbieter kann gesteuerte und ungeschützte Pfade aufzählen.
Beobachtetes KLA-Verhalten
Auf dem Gateway-Pfad versiegelt das Governance-Gateway einen Entscheidungsbeleg im Evidence Ledger, bevor das Tool ausgeführt wird; block und require_approval beenden den Aufruf, und der Tool-Executor wird nie aufgerufen. Die Tool-Policy wird außerdem bei jeder MCP-Aufruf im Tool Hub geprüft.
Nachweis
- services/governance-pep/src/gateway.ts: decision sealed before the side effect; block and require_approval short-circuit
- governance-gateway.test.ts: 15 cases on the gateway decision path
- cmb-aml-governance-gateway.test.ts: 16 end-to-end cases on a banking workflow
- scripts/check-production-governance-gateway.mjs: deployment guard that the gateway is enabled in production
Einschränkungen
- Das Gateway wird durch die Bereitstellungskonfiguration aktiviert; die ausgelieferten Produktions- und Entwicklungs-Overlays aktivieren es, und ein selbstverwalteter Betreiber muss dies ebenfalls tun.
- Der interne Endpoint für Connector-Ausführung vertraut darauf, dass das Tool-Gate vorgelagert ausgeführt wurde; er autorisiert den Aufrufer gegen die gebundene Verbindung und führt keine zweite Policy-Prüfung durch.
RT-02
Ausfall der Policy-Engine
Durch automatisierte Tests festgehaltenWelches Ergebnis erzeugt die Plattform, wenn die Policy-Auswertung nicht verfügbar ist?
Verfahren
- 01Nehmen Sie den Policy-Entscheidungsdienst außer Betrieb oder injizieren Sie einen Transportfehler, während der Agent eine folgenreiche Aktion vorschlägt.
- 02Wiederholen Sie den Test mit einem internen Fehler der Policy-Engine: keine aufgelöste Policy, ein nicht signaturgeprüftes Policy Pack und eine nicht verfügbare Guardrails-Abhängigkeit.
- 03Dokumentieren Sie Ergebnis, Reason Code und ob eine Konfiguration einen Fehler in allow umwandeln kann.
Von jeder gesteuerten Plattform erwartet
Jeder Fehlermodus erzeugt block oder require_approval mit einem maschinenlesbaren Grund. Kein Konfigurationswert kann einen Auswertungsfehler in allow umwandeln.
Beobachtetes KLA-Verhalten
Die in der Prüfung gefundenen Schichten arbeiten ausfallsicher: Transportfehler am Durchsetzungspunkt, fehlende Policy, Signaturfehler des Packs, nicht verfügbare Guardrails-Laufzeit, Fehler des Berechtigungsanbieters, Ausfall des AI-Judges und Ausfall des Evidence Stores verweigern alle. Die Umgebungsüberschreibung akzeptiert block oder require_approval und lehnt allow ab.
Nachweis
- services/governance-pep/src/decisions.ts + environment.ts: fail-closed decision builder; override cannot be allow
- policy-evaluation-service.test.ts: 12+ fail-closed cases including pack-verification failure and “must not fail open” regression
- services/policy-engine/src/policy-pack/lint.ts: allow/warn default decision is a publish-time error
- transition-gate-decision.test.ts: errored policy outcome blocks and is excluded from human-recoverable reasons
Einschränkungen
- Außerhalb der Produktion führt ein Ausfall zu require_approval, sodass die Warteschlange anschwillt, während Aktionen pausiert bleiben.
- Der ausfallsichere Standard wird aus der Runtime-Umgebungsvariable abgeleitet; ein Produktionsdienst mit falschem NODE_ENV fällt auf require_approval zurück.
RT-03
Geänderte Parameter nach der Genehmigung
Durch automatisierte Tests festgehaltenWird die Aktion ausgeführt, wenn sich Argumente zwischen Genehmigung und Ausführung ändern?
Verfahren
- 01Lösen Sie require_approval aus, genehmigen Sie die Aktion und ändern Sie anschließend einen wesentlichen Parameter (Betrag, Begünstigter, Zieldatensatz).
- 02Senden Sie die Fortsetzungsanfrage mit der ursprünglichen Genehmigung und den geänderten Argumenten erneut.
- 03Bestätigen Sie, welche Seite die Bindung neu berechnet: die Nutzlast des Aufrufers oder die versiegelte Aufzeichnung des Servers.
Von jeder gesteuerten Plattform erwartet
Die Genehmigung ist an einen kanonischen Digest der exakten Argumente gebunden, wird beim Fortsetzen serverseitig anhand einer vom Aufrufer nicht lieferbaren Aufzeichnung erneut geprüft und blockiert bei einer Abweichung.
Beobachtetes KLA-Verhalten
Bei der Genehmigung versiegelt das Gateway einen kanonischen SHA-256-Hash der Tool-Argumente im dauerhaften Ledger. Beim Fortsetzen berechnet es den Hash aus den übermittelten Argumenten neu und vergleicht ihn mit der Ledger-Kopie; der Hash in der Fortsetzungsnutzlast wird bewusst ignoriert. Eine Abweichung und auch ein fehlender versiegelter Hash blockieren mit dem Grund tool_args_mismatch.
Nachweis
- services/governance-pep/src/gateway.ts: TOCTOU re-verification against the ledger-sealed hash only
- governance-gateway.test.ts: “TOCTOU: Phase-2 resume with mutated arguments fails closed and never executes”
- cmb-aml-governance-gateway.test.ts: “fails closed when the decision input changes after approval”
Einschränkungen
- Die kryptografische Prüfung läuft auf dem Gateway-Pfad. Gesteuerte Connector-Tools setzen über das Zustandsobjekt von agent-runtime fort und fixieren die Argumente strukturell ohne zweiten Hashvergleich.
RT-04
Veraltete Genehmigung
Gilt mit benannten EinschränkungenKann ein Prüfer nach Ablauf des Gültigkeitsfensters über eine Genehmigung entscheiden?
Verfahren
- 01Erstellen Sie eine Genehmigung mit Fälligkeitszeit, lassen Sie sie ablaufen und versuchen Sie anschließend, sie über jede angebotene Entscheidungsoberfläche zu genehmigen.
- 02Bestätigen Sie, welche Autorität eine abgelaufene Genehmigung behält und welche Oberflächen den Ablauf erzwingen.
Von jeder gesteuerten Plattform erwartet
Eine überfällige Genehmigung verweigert auf jeder Entscheidungsoberfläche Genehmigung und Ablehnung; nur Eskalation bleibt möglich.
Beobachtetes KLA-Verhalten
Genehmigungen haben eine Fälligkeitszeit (standardmäßig eine Stunde). Beide Entscheidungsoberflächen verweigern überfällige Entscheidungen: Die vom Decision Desk verwendete Control-Plane-Oberfläche berechnet den überfälligen Zustand und erlaubt nur Eskalation, während die Entscheidungsaktualisierung der Execution API voraussetzt, dass die Fälligkeitszeit noch in der Zukunft liegt, und nach Ablauf einen Konflikt zurückgibt. Die Maker-Checker-Trennung wird serverseitig auf beiden Pfaden durchgesetzt.
Nachweis
- services/api/src/routers/approvals.ts: overdue approvals accept escalate only; maker cannot check
- services/execution-api/src/routes/approvals.ts: decision update requires due_at in the future
- approval-decision-self-approval.test.ts: post-deadline decision returns 409 without signaling the workflow
- approvals.maker-checker.test.ts: 10 cases
Einschränkungen
- Tool-Gate-Genehmigungen warten absichtlich unbegrenzt; das konfigurierbare Timeout gilt für explizite menschliche Genehmigungsknoten.
RT-05
Replay über Grenzen hinweg
Durch automatisierte Tests festgehaltenKann eine Genehmigung oder Entscheidung eine zweite Aktion an anderer Stelle autorisieren?
Verfahren
- 01Erfassen Sie eine genehmigte Entscheidung und spielen Sie sie gegen einen anderen Run, einen anderen Tool-Aufruf, einen anderen Tenant und denselben Aufruf mit anderer Ausgabe erneut ab.
- 02Bestätigen Sie den Scoping-Schlüssel der gespeicherten Entscheidung.
Von jeder gesteuerten Plattform erwartet
Entscheidungen und Genehmigungen sind auf Tenant, Run und Tool-Aufruf begrenzt; kein Replay überschreitet diese Grenzen.
Beobachtetes KLA-Verhalten
Der Idempotenzschlüssel lautet tenant:execution:gate; der Input-Gate enthält die Tool-Aufruf-ID, das Output-Gate zusätzlich den Ausgabe-Hash. Ein wiederholter abgeschlossener Aufruf gibt die gespeicherte Disposition zurück; ein Schlüssel autorisiert niemals Arbeit unter einem anderen Tenant oder einer anderen Ausführung.
Nachweis
- services/governance-pep/src/idempotency.ts: key structure
- cmb-aml-governance-gateway.test.ts: “does not replay an approval across execution or tenant ledger keys”
RT-06
Retry und doppelte Zustellung
Durch automatisierte Tests festgehaltenFührt ein Absturz, Retry oder eine doppelte Zustellung den Seiteneffekt zweimal aus?
Verfahren
- 01Stellen Sie denselben gesteuerten Tool-Aufruf zweimal gleichzeitig zu; stellen Sie ihn nach einem abgeschlossenen Run erneut zu; beenden Sie den Worker zwischen Entscheidung und Abschluss und lassen Sie den Orchestrator wiederholen.
- 02Zählen Sie die Seiteneffekte und prüfen Sie die Beziehung zwischen Entscheidungen, Ausführungen und Nachweisaufzeichnungen.
Von jeder gesteuerten Plattform erwartet
Eine Aktion erzeugt bei gleichzeitigen und sequenziellen Retries genau einen Seiteneffekt; das Verhalten im Absturzfenster ist präzise angegeben.
Beobachtetes KLA-Verhalten
Ein dauerhaftes Write-Ahead-Ledger zeichnet die Absicht vor der Ausführung auf und schreibt das Ergebnis danach fest. Ein wiederholter abgeschlossener Aufruf gibt das zwischengespeicherte Ergebnis zurück; der unterlegene parallele Schreiber gibt das Ergebnis des Gewinners zurück.
Nachweis
- services/governance-pep/src/gateway.ts: write-ahead intent, committed short-circuit, one-shot output release
- governance-gateway.test.ts: “exactly-once: a replayed committed call returns the cached result without re-executing”; concurrent-loser case
- cmb-aml-governance-gateway.test.ts: re-drive across an orchestrator retry without a second side effect
Einschränkungen
- Im Absturzfenster hängt exactly-once davon ab, dass das nachgelagerte System den weitergegebenen Idempotenzschlüssel berücksichtigt; ein System, das ihn ignoriert, fällt auf at-least-once zurück.
- Die Tabelle des dauerhaften Ledgers verwendet tenant-präfixierte Schlüssel zur Isolation und hat noch keine Row-Level-Security-Policy.
RT-07
Verwahrung von Zugangsdaten
Gilt mit benannten EinschränkungenKann der Agent, das Modell oder ein abgerufenes Tool gespeicherte Zugangsdaten beobachten?
Verfahren
- 01Verfolgen Sie, wo Connector-Zugangsdaten aufgelöst werden und in welchen Prozessspeicher sie während eines gesteuerten Tool-Aufrufs gelangen.
- 02Versuchen Sie Server-Side Request Forgery über eine Connector-URL, die auf interne oder Metadaten-Adressen aufgelöst wird.
- 03Senden Sie Schreibanweisungen über einen schreibgeschützten Datenbank-Connector.
Von jeder gesteuerten Plattform erwartet
Zugangsdaten werden ausschließlich in der Control Plane aufgelöst; der Egress ist an validierte Adressen gebunden; schreibgeschützte Connectoren verweigern Schreibvorgänge auf mehreren Ebenen.
Beobachtetes KLA-Verhalten
Connector-Zugangsdaten werden in der Control Plane aufgelöst und nur in ausgehenden Request-Headern oder einem Datenbank-Client materialisiert; der Execution Worker sendet die Tool-Eingabe und empfängt das Ergebnis. Der Connector-Egress validiert jede Adresse beim Verbindungsaufbau, bindet die Verbindung an die validierte IP, behält TLS-Namen am ursprünglichen Host und verweigert Weiterleitungen.
Nachweis
- services/api/src/services/connector-execution.ts: control-plane custody; DNS-pinned egress; BEGIN READ ONLY
- connector-network-safety.ts: metadata, link-local, multicast, and documentation ranges blocked; private ranges gated by explicit configuration
- mcp-installation-secret-safety.ts: secret-pattern rejection at the API boundary
Einschränkungen
- Lokal gestartete MCP-Toolserver erben die Umgebung des Worker-Prozesses; ein schädlicher MCP-Server könnte Variablen dieses Pods lesen.
- Die Verwahrung von Zugangsdaten ist architektonisch; es gibt keinen automatisierten Negativtest, der ausschließt, dass ein Model-Prompt jemals eine Zugangsdaten enthält.
- Ein Connector kann so konfiguriert werden, dass die TLS-Prüfung übersprungen wird; diese Einstellung gehört zur Verbindungsaufzeichnung und sollte geprüft werden.
RT-08
Änderung einer Aufzeichnung
Durch automatisierte Tests festgehaltenWas erkennt eine Änderung an einer gespeicherten Entscheidungs-, Genehmigungs- oder Nachweisaufzeichnung?
Verfahren
- 01Ändern Sie über privilegierten Speicherzugriff ein Byte einer Entscheidungsaufzeichnung, einer Genehmigungs-Auditaufzeichnung und eines Evidence Receipt.
- 02Lesen Sie jede geänderte Aufzeichnung über das Produkt und exportieren Sie sie; dokumentieren Sie, wo die Erkennung auslöst.
Von jeder gesteuerten Plattform erwartet
Die Änderung jeder Governance-Aufzeichnung wird beim Lesen oder Export durch Integritätsmechanismen erkannt, die vom veränderten Speicher unabhängig sind.
Beobachtetes KLA-Verhalten
Governance-Aufzeichnungen werden über verifizierte Schreibvorgänge in ein unveränderliches Ledger geschrieben, die Schlüssel und Wert an den Transaktionsbeleg binden. Audit-Trail- und Policy-Gate-Lesevorgänge laufen über verifizierte Reads, die den Content-Hash der Aufzeichnung und ihren Inclusion-Proof neu berechnen; eine Abweichung verweigert die Ausgabe. Signierte Decision Receipts bilden eine Ed25519-Hashkette.
Nachweis
- services/api/src/services/immudb-multi-tenant.ts: hash recomputation and trusted-read verification on audit and policy-gate reads
- services/governance-pep/src/receipt-chain.ts + signing.ts: signed hash chain; 28 test cases including tamper, reorder, truncation
- export-api.receipt-ledger-bundle.test.ts: tampered receipt and tampered ledger record turn the export red
Einschränkungen
- Einige Policy-Decision-Lesevorgänge prüfen einen zusammen mit der Aufzeichnung gespeicherten Content-Hash, ohne einen serverseitigen Inclusion-Proof neu zu berechnen, und Anzeige-Read-Models wie die Control-Decision-Tabelle sind veränderliche Zeilen; eine Änderung auf diesen Pfaden wird durch den Vergleich mit dem versiegelten Ledger und beim Export festgestellt.
- Die Erkennung erfolgt beim Lesen oder Export; es gibt keinen kontinuierlichen Hintergrundjob zur erneuten Verifizierung.
- Das Abschneiden am Ende einer Receipt-Kette wird nur erkannt, wenn der Verifier einen unabhängig gespeicherten End-Hash erhält.
RT-09
Offline-Verifizierung von Nachweisen
Durch automatisierte Tests festgehaltenKann ein Auditor ein exportiertes Bundle ohne Netzwerkzugriff und ohne KLA-Konto verifizieren?
Verfahren
- 01Exportieren Sie ein Sealed Evidence Bundle für einen gesteuerten Run, übertragen Sie es auf einen vom Netz getrennten Rechner und führen Sie den veröffentlichten Verifier aus.
- 02Ändern Sie je Artefaktklasse ein Byte und führen Sie ihn erneut aus; jede Änderung muss den Run mit einer benannten Prüfung rot markieren.
Von jeder gesteuerten Plattform erwartet
Ein eigenständiger Verifier belegt Signaturen, Hashketten und Inclusion-Proofs allein aus dem Bundle, benennt klar seine Offline-Grenzen und bricht bei Manipulation ausfallsicher ab.
Beobachtetes KLA-Verhalten
Der Evidence Verifier führt ohne Netzwerkzugriff und unter Verwendung des im Bundle enthaltenen Schlüsselbestands fünf Prüfungen aus: Manifest-Signatur unter Service- und Tenant-Schlüsseln, Receipt-Signaturketten, Ledger-Hashkette, Merkle-Inclusion gegen den erhaltenen Transaktionsbeleg und Zeitstempelanker. Eine Manipulation um ein Byte in jeder Artefaktklasse markiert die entsprechende Prüfung rot.
Nachweis
- packages/evidence-verifier: five checks, command-line verifier, ~55 automated cases
- verifier.test.ts: one-byte tamper per artifact class; revoked key; path escape; malformed key set
Einschränkungen
- Der Schlüsselbestand des Verifiers befindet sich im Bundle. Ein erfolgreicher Lauf belegt die interne Konsistenz des exportierten Bundles; die Erkennung eines von einem nicht vertrauenswürdigen Exporteur neu signierten Bundles erfordert den Abgleich der Bundle-Schlüssel mit unabhängig empfangenem Schlüsselmaterial, und eine integrierte Schlüssel-Pinning-Prüfung ist ein Roadmap-Punkt.
- Die Merkle-Inclusion wird gegen den im Bundle aufbewahrten Transaktionsbeleg geprüft. Die Verifizierung gegen den unabhängig signierten Zustand des Ledgers ist ein Roadmap-Punkt, und die Bestätigung des Zeitstempelankers auf der öffentlichen Chain erfordert einen netzwerkgebundenen Schritt.
- Ein Bundle mit ausschließlich unsignierten Receipts besteht die Receipt-Prüfung mit null verifizierten Ketten; der Verifier meldet die Anzahl, und ein Auditor muss sie lesen.
