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.
2. Boden: enge Autonomie anwenden
Starten Sie von der stärksten Ein-Schalter-Haltung. Wenden Sie in Firewall → Posture dastight-Autonomie-Level
an (Rolle Developer). In einer einzigen Transaktion setzt es beide Ebenen:
| Ebene | Was tight materialisiert |
|---|---|
| Firewall | Default-deny; destruktive Shell ablehnen; SSRF-Egress ablehnen (fetch-förmige Tool-Namen) |
| Guardrails | PII Shield + Secrets Blocker auf Requests durchgesetzt |
autonomy_*-Policy- und
Guardrail-Zeilen — es ist ein Seed, keine Black Box. Er hat Ein-Klick-Undo aus
einem Audit-Snapshot.
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.*(oderpayment.send,ledger.adjust, …) - Verdikt:
pending_approval
- Der zurückgehaltene Aufruf gibt HTTP 400
firewall_approval_pendingmit einer Approval-ID zurück; der Aufruf erreicht das Tool nicht. - 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. - Der Agent pollt
GET /api/v1/firewall/approvals/:id, reicht dann den ursprünglichen Aufruf mit einem einmal nutzbarenX-OrcaRouter-Firewall-Approval-Header erneut ein — das Gateway lässt ihn dieses eine Mal durch.
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. Einecap_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:
Kartennummern und Secrets aus Requests blockieren
Kartennummern und Secrets aus Requests blockieren
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.PII auf dem Weg hinein maskieren
PII auf dem Weg hinein maskieren
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.)Args bereinigen, Ergebnissen nie vertrauen
Args bereinigen, Ergebnissen nie vertrauen
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.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
| Was | Detail |
|---|---|
| Signatur | Ed25519 über einen SHA-256-Evidenz-Hash — manipulationssicher |
| Formate | CSV / JSON / PDF |
| Verifizieren | Öffentlich — GET /api/public/compliance/pubkey, POST /api/public/compliance/verify |
| Teilen | Ein 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-Artefakts —
us,eu,uk,ap,cnoderglobal, gesetzt überPUT /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.
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.
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.
