Zum Hauptinhalt springen
Ein Finanz-Agent gleicht Bücher ab, stellt Erstattungen aus, bewegt Geld und liest Karten- und Kontodaten. Der Blast-Radius eines schlechten Tool-Calls — eine außer Kontrolle geratene Erstattungs-Schleife, ein DROP auf einer Ledger-Tabelle, Kartennummern, die in einen Prompt leaken — wird in Dollar und Audit-Befunden gemessen. Dieses Rezept stellt die Kontrollen zusammen, die einen solchen Agenten sicher zum Betreiben machen: enge Autonomie als Boden, menschliche Freigabe auf den geldbewegenden Tools, eine Pro-Lauf-Kosten-Cap als Schutzschalter und ein installierbares SOC-2- / PCI-Compliance-Pack, das die Policy und die signierte Evidenz materialisiert, nach der ein Auditor fragen wird.
Alles hier wird in der Konsole konfiguriert (Firewall → Posture / Policies, Guardrails, Compliance). Diese Management-Routen verwenden Ihre Konsolen-Session, nicht einen Relay-Schlüssel — nur die /v1/*-Aufrufe, die Ihr Agent macht, tragen einen sk-orca-…-Schlüssel. Policy-Bearbeitungen erfordern die Rolle Developer; Compliance-Install / Go-live / Residency erfordern Workspace-Admin und einen kostenpflichtigen Plan.

1. Warum ein sicherer Finanz-KI-Agent mehr als Guardrails braucht

Content-Screening fängt eine Kartennummer in einem Prompt. Es hält den Agenten nicht davon ab, refund.issue zehntausendmal aufzurufen, einen internen 10.x-Host zu erreichen oder eine destruktive Migration auszuführen. Eine Haltung in Finanzqualität muss beide Ebenen auf einmal steuern:

Die Textebene

Guardrails prüfen Request- und Response-Text — PII maskiert, Secrets blockiert, bevor das Modell sie je sieht.

Die Aktionsebene

Die Firewall steuert jeden Tool-Call, MCP-Dispatch und ausgehenden Request — allow, audit, deny, sanitize, hold oder Kosten begrenzen.
Dieses Rezept legt vier Kontrollen übereinander. Lesen Sie zuerst die Secure-Agents-Baseline und Guardrails vs. Firewall, falls die zwei Ebenen noch nicht klar sind.

2. Boden: enge Autonomie anwenden

Starten Sie von der stärksten Ein-Schalter-Haltung. Wenden Sie in Firewall → Posture das tight-Autonomie-Level an (Rolle Developer). In einer einzigen Transaktion setzt es beide Ebenen:
EbeneWas tight materialisiert
FirewallDefault-deny; destruktive Shell ablehnen; SSRF-Egress ablehnen (fetch-förmige Tool-Namen)
GuardrailsPII Shield + Secrets Blocker auf Requests durchgesetzt
Der Autonomie-Schalter schreibt echte, editierbare autonomy_*-Policy- und Guardrail-Zeilen — es ist ein Seed, keine Black Box. Er hat Ein-Klick-Undo aus einem Audit-Snapshot.
Auf einem geldbewegenden Agenten flippen Sie in Produktion nicht direkt auf tight. Wenden Sie es im Shadow-Mode an (oder starten Sie bei balanced), sodass jedes durchsetzende Verdikt mit einem [shadow] would …-Grund auf audit herabgestuft wird. Beobachten Sie Firewall → Events / Runs, bestätigen Sie, dass die Policy auf das feuert, was Sie erwarten, und setzen Sie dann durch.

3. Freigaben: die geldbewegenden Tools für einen Menschen zurückhalten (HITL)

Default-Deny stoppt, was Sie nicht erlaubt haben. Die Tools, die Sie doch erlauben, die aber Geld bewegen — refund.issue, payment.send, ledger.adjust — sollten weder auto-erlaubt noch auto-abgelehnt werden. Geben Sie ihnen das pending_approval-Verdikt, sodass ein Mensch out-of-band abnickt. Fügen Sie in Firewall → Policies eine Regel über Ihrem Default hinzu:
  • Tool-Glob: refund.* (oder payment.send, ledger.adjust, …)
  • Verdikt: pending_approval
Wenn der Agent es aufruft:
  1. Der zurückgehaltene Aufruf gibt HTTP 400 firewall_approval_pending mit einer Approval-ID zurück; der Aufruf erreicht das Tool nicht.
  2. Ein Prüfer löst es auf — aus der Konsole (Developer+) oder über einen HMAC-signierten Webhook-Callback an Ihr eigenes Approval-System unter POST /api/v1/firewall/approvals/:id/callback.
  3. Der Agent pollt GET /api/v1/firewall/approvals/:id, reicht dann den ursprünglichen Aufruf mit einem einmal nutzbaren X-OrcaRouter-Firewall-Approval-Header erneut ein — das Gateway lässt ihn dieses eine Mal durch.
Pinnen Sie ein Argument-Prädikat, sodass nur die großen Operationen einen Menschen brauchen: Glob refund.issue mit der JSONPath-Klausel {"path":"$.amount_cents","op":"gt","value":50000}, Verdikt pending_approval. Kleine Erstattungen fließen; eine Erstattung über 500 $ wartet auf einen Prüfer. Siehe Firewall-Regeln für den vollständigen Operator-Satz (eq, contains, regex, in, cidr_match, gt, lt).

4. Schutzschalter: die Kosten eines Laufs begrenzen

Ein Finanz-Agent, der in einer Retry-Schleife feststeckt, ist sowohl ein Korrektheits- als auch ein Abrechnungs-Bug. Eine cap_cost-Regel ist der Schutzschalter für außer Kontrolle geratene Schleifen: Sie lehnt einen Tool-Call ab, sobald die kumulierten Ausgaben des Agentenlaufs eine Pro-Regel-Cent-Cap überschreiten. Fügen Sie eine Regel mit Verdikt cap_cost und einer cap_cost_cents-Obergrenze hinzu — z. B. 2000 (USD 20,00 $) — eingegrenzt auf die Tools Ihres Agenten. Sobald die laufenden Ausgaben eines Laufs die Obergrenze überschreiten, werden weitere Aufrufe in diesem Lauf abgelehnt; ein frischer Lauf startet sauber.
cap_cost begrenzt die Ausgaben des Agentenlaufs, nicht das Lebenszeit-Budget eines einzelnen Schlüssels. Für eine harte Obergrenze auf einem Schlüssel setzen Sie credit_limit_usd auf dem API-Key selbst (0 = unbegrenzt) — die zwei komponieren: Das Schlüssel-Budget begrenzt die Gesamtausgaben, cap_cost begrenzt jeden einzelnen Lauf.

5. Doppelt abgesichert auf der Textebene

tight setzt bereits PII Shield und Secrets Blocker durch. Für einen Finanz-Agenten stützen Sie sich auf die Spezifika:
Das Secrets Blocker-Guardrail fängt API-Keys und Credentials im Prompt, bevor das Modell sie sieht. Für Kartendaten lehnt eine pii-Regel mit credit_card auf die block-Aktion gesetzt (über Pro-Entitäts- entity_actions) den Request ganz ab mit HTTP 400 guardrail_blocked — und ein Block kostet kein Kontingent (Input-Blocks feuern vor dem Metering). Siehe Guardrails §5.
Das PII-Shield-Preset ist eine einzelne pii-Regel, mask, Stage both. Input-Stage-Masking ist live: ein iban oder ssn im Request wird als [IBAN] / [SSN] gerendert, bevor das Modell aufgerufen wird. (Live-Output-/Streaming-Masking ist auf der Roadmap; Output-block wird heute auf Streaming und Nicht-Streaming durchgesetzt.)
Ein Firewall-sanitize-Verdikt redigiert gematchte Teilstrings aus den Argumenten eines Tool-Calls vor der Weiterleitung — es schreibt nie um, was ein Tool zurückgibt. Um ein Secret ganz aus einem Request herauszuhalten, ist das die Aufgabe des Secrets-Blocker-Guardrails auf der Textebene.

6. Das Compliance-Pack: SOC 2 und PCI in einer Installation

Die Kontrollen oben sind die Implementierung. Ein Auditor will die Evidenz. Die Compliance-Ebene schließt diesen Kreis: Durchsuchen Sie den Framework-Katalog (kostenlos, jedes Mitglied), installieren Sie dann ein Pack als Workspace-Admin auf einem kostenpflichtigen Plan. Das Installieren eines Packs materialisiert Guardrails und Firewall-Policies, die auf die Kontrollen des Frameworks abbilden — sodass dieselbe Installation, die Ihnen das Audit-Artefakt gibt, auch echte Durchsetzung aufstellt.
# Console action (UserAuth session) — install the PCI DSS pack
POST /api/compliance/packs/pci_dss/install
# then, when you're ready to enforce:
POST /api/compliance/packs/pci_dss/golive
Bestätigte Packs, die für einen Finanz-Agenten relevant sind, umfassen soc2 (AICPA SOC 2 Trust Services Criteria), pci_dss (PCI DSS 4.0), glba (Gramm-Leach-Bliley) und dora_eu (Digital Operational Resilience Act) — neben Datenschutz-Frameworks (gdpr, uk_gdpr, ccpa), Sicherheits-/KI-Frameworks (iso_27001, iso_42001, nist_ai_rmf, eu_ai_act, nist_800_53) und dem owasp_llm-Pack (OWASP Top 10 for LLM Applications). Durchsuchen Sie den Live-Katalog für den vollständigen Satz.

Der Report, den ein Auditor verifizieren kann

WasDetail
SignaturEd25519 über einen SHA-256-Evidenz-Hash — manipulationssicher
FormateCSV / JSON / PDF
VerifizierenÖffentlich — GET /api/public/compliance/pubkey, POST /api/public/compliance/verify
TeilenEin schreibgeschützter Auditor-Link: GET /api/public/compliance/share/:token
Der kostenlose Plan enthält einen Report; CSV-/JSON-Export und zusätzliche Reports sind kostenpflichtig. Einen Report zu generieren und live zu gehen sind serverseitig auf kostenpflichtige Pläne beschränkt — die Katalog- und Readiness-Ansichten bleiben kostenlos.

7. Datenresidenz, Aufbewahrung und Löschung

Eine Haltung in Finanzqualität muss „wo ist die Evidenz und wie lange behalten Sie die Logs” beantworten.
  • Residency ist die Region des Compliance-Report-Artefaktsus, eu, uk, ap, cn oder global, gesetzt über PUT /api/compliance/residency (Admin). Cross-Region-Lesungen werden zurückgehalten. (Das pinnt das Artefakt, nicht wo die Inferenz läuft.)
  • Aufbewahrung — Request-Logs sind per Default 30 Tage und werden serverseitig auf ein hartes Maximum von 180 Tagen begrenzt.
  • Löschung — eine Self-Service-Kontolöschung tritt in ein 30-Tage-Grace-Fenster, dann kaskadiert ein irreversibler PII-Scrub durch Guardrail-Matches, Request-Logs und Firewall-Events.
Jede Policy-, Regel- und Compliance-Änderung schreibt eine Audit-Zeile (Workspace + zentral). Guardrail- und Firewall-Änderungen sind auch versioniert — diffen und reverten Sie jedes Guardrail aus seinem History-Tab.

8. Verifizieren, bevor Sie sich darauf verlassen

Liefern Sie keine Finanz-Policy auf gut Glück aus. Beide Ebenen haben eine Sandbox, die nichts persistiert und nichts dispatcht:
  • Guardrails → Test — fügen Sie ein Sample ein, wählen Sie eine Stage, sehen Sie das Verdikt und den gerenderten (maskierten) Text.
  • Firewall → Test (Developer+) — dry-runnen Sie einen Beispiel-Tool-Call und sehen Sie das Verdikt, die gematchte Regel und den Grund.
Einmal live, ist Firewall → Events / Runs der Pro-Lauf-Datensatz jeder Auswertung, und der Anomalie-Feed flaggt Raten-/Kosten-Spikes gegen die gelernte Hour-of-week-Baseline des Workspaces, retry_loop und nie zuvor gesehene Tool-Pfade — genau die Signale, die einem finanziellen Vorfall vorausgehen.

Rückblick

Secure-Agents-Baseline

Was tight materialisiert und wie man vor dem Anwenden simuliert.

Firewall-Regeln

Argument-Prädikate, Kosten-Caps, Egress und Sequenzen im Detail.

SOC-2-Evidenz

Die materialisierten Kontrollen in ein signiertes Audit-Artefakt verwandeln.

PII-sicheres Logging

Karten- und Kontodaten aus Ihren Request-Logs heraushalten.

Enforcement-Modi

Observe → shadow → enforce, das sichere Ausrollen für geldbewegende Tools.

Gefährliche Tool-Calls

Die Bedrohung, gegen die sich die Tool-Allowlist eines Finanz-Agenten verteidigt.