Przejdź do głównej treści
Agent finansowy uzgadnia księgi, wydaje zwroty, porusza pieniędzmi i odczytuje dane kart i kont. Promień rażenia jednego złego wywołania narzędzia — rozbiegana pętla zwrotów, DROP na tabeli księgi, numery kart wyciekające do promptu — jest mierzony w dolarach i ustaleniach audytu. Ten przepis składa kontrole, które czynią takiego agenta bezpiecznym do uruchomienia: ciasna autonomia jako podłoga, zatwierdzenie przez człowieka na narzędziach poruszających pieniędzmi, limit kosztu per uruchomienie jako bezpiecznik oraz instalowalna paczka zgodności SOC 2 / PCI, która materializuje politykę oraz podpisany dowód, o który poprosi audytor.
Wszystko tutaj jest konfigurowane w konsoli (Firewall → Posture / Policies, Guardrails, Compliance). Te trasy zarządzania używają twojej sesji konsoli, nie klucza relay — tylko wywołania /v1/*, które robi twój agent, niosą klucz sk-orca-…. Edycje polityki wymagają roli Developer; instalacja zgodności / go-live / rezydencja wymagają Admin przestrzeni roboczej i płatnego planu.

​
1. Dlaczego bezpieczny agent finansowy AI potrzebuje więcej niż guardrails

Prześwietlanie treści wychwytuje numer karty w promptcie. Nie powstrzymuje agenta przed wywołaniem refund.issue dziesięć tysięcy razy, sięgnięciem do wewnętrznego hosta 10.x ani uruchomieniem destrukcyjnej migracji. Postawa klasy finansowej musi zarządzać obiema płaszczyznami naraz:

Płaszczyzna tekstu

Guardrails prześwietlają tekst żądania i odpowiedzi — PII zamaskowane, sekrety zablokowane, zanim model je kiedykolwiek zobaczy.

Płaszczyzna akcji

Firewall zarządza każdym wywołaniem narzędzia, dyspozycją MCP i żądaniem wychodzącym — allow, audit, deny, sanitize, wstrzymaj lub ogranicz koszt.
Ten przepis nakłada cztery kontrole jedna na drugą. Przeczytaj najpierw bazę Secure Agents oraz Guardrails vs Firewall, jeśli dwie płaszczyzny nie są jeszcze jasne.

​
2. Podłoga: zastosuj ciasną autonomię

Zacznij od najsilniejszej postawy jednoprzełącznikowej. W Firewall → Posture zastosuj poziom autonomii tight (poziom autonomii) (rola Developer). W jednej transakcji ustawia obie płaszczyzny:
PłaszczyznaCo materializuje tight
FirewallDomyślna odmowa; odmów destrukcyjnego shella; odmów egress SSRF (nazwy narzędzi w kształcie fetch)
GuardrailsPII Shield + Secrets Blocker egzekwowane na żądaniach
Przełącznik autonomii zapisuje prawdziwe, edytowalne wiersze polityki i guardrailu autonomy_* — to ziarno, nie czarna skrzynka. Ma cofnięcie jednym kliknięciem z migawki audytu.
Na agencie poruszającym pieniędzmi nie przełączaj wprost na tight na produkcji. Zastosuj go w trybie cienia (lub zacznij na balanced), aby każdy egzekwujący werdykt był degradowany do audit z powodem [shadow] would …. Obserwuj Firewall → Events / Runs, potwierdź, że polityka odpala na tym, czego oczekujesz, potem egzekwuj.

​
3. Zatwierdzenia: wstrzymaj narzędzia poruszające pieniędzmi dla człowieka (HITL)

Domyślna odmowa zatrzymuje to, czego nie dopuściłeś. Narzędzia, które jednak dopuszczasz, ale które poruszają pieniędzmi — refund.issue, payment.send, ledger.adjust — nie powinny być ani auto-dozwolone, ani auto-odmówione. Daj im werdykt pending_approval, aby człowiek podpisał poza pasmem. W Firewall → Policies dodaj regułę ponad swoją domyślną:
  • Glob narzędzia: refund.* (lub payment.send, ledger.adjust, …)
  • Werdykt: pending_approval
Gdy agent to woła:
  1. Wstrzymane wywołanie zwraca HTTP 400 firewall_approval_pending z id zatwierdzenia; wywołanie nie dociera do narzędzia.
  2. Recenzent rozstrzyga je — z konsoli (Developer+) lub przez podpisany HMAC webhook callback do twojego własnego systemu zatwierdzeń na POST /api/v1/firewall/approvals/:id/callback.
  3. Agent odpytuje GET /api/v1/firewall/approvals/:id, potem ponownie wysyła oryginalne wywołanie z jednorazowym nagłówkiem X-OrcaRouter-Firewall-Approval — brama przepuszcza je ten jeden raz.
Przypnij predykat argumentu, aby tylko duże operacje wymagały człowieka: glob refund.issue z klauzulą JSONPath {"path":"$.amount_cents","op":"gt","value":50000}, werdykt pending_approval. Małe zwroty płyną; zwrot 500 $+ czeka na recenzenta. Zobacz Reguły firewalla dla pełnego zestawu operatorów (eq, contains, regex, in, cidr_match, gt, lt).

​
4. Bezpiecznik: ogranicz koszt uruchomienia

Agent finansowy utknięty w pętli ponawiania to zarazem błąd poprawności i rozliczeń. Reguła cap_cost to bezpiecznik rozbieganej pętli: odmawia wywołania narzędzia, gdy zakumulowane wydatki uruchomienia agenta przekroczą limit w centach per reguła. Dodaj regułę z werdyktem cap_cost i pułapem cap_cost_cents — np. 2000 (20,00 USD) — ograniczoną do narzędzi twojego agenta. Gdy bieżące wydatki uruchomienia przekroczą limit, dalsze wywołania w tym uruchomieniu są odmawiane; świeże uruchomienie startuje czyste.
cap_cost ogranicza wydatki uruchomienia agenta, nie dożywotni budżet pojedynczego klucza. Dla twardego pułapu na kluczu ustaw credit_limit_usd na samym kluczu API (0 = bez limitu) — oba się komponują: budżet klucza ogranicza całkowite wydatki, cap_cost ogranicza dowolne pojedyncze uruchomienie.

​
5. Pas i szelki na płaszczyźnie tekstu

tight już egzekwuje PII Shield i Secrets Blocker. Dla agenta finansowego oprzyj się na specyfice:
Guardrail Secrets Blocker wychwytuje klucze API i poświadczenia w promptcie, zanim model je zobaczy. Dla danych kart reguła pii z credit_card ustawionym na akcję block (przez entity_actions per encja) odrzuca żądanie wprost z HTTP 400 guardrail_blocked — a block kosztuje zero kwoty (bloki input odpalają przed metrowaniem). Zobacz Guardrails §5.
Preset PII Shield to pojedyncza reguła pii, mask, etap both. Maskowanie na etapie input jest dostępne: iban lub ssn w żądaniu jest renderowane jako [IBAN] / [SSN], zanim model zostanie wywołany. (Maskowanie na żywo output/strumień jest na mapie drogowej; block na wyjściu jest dziś egzekwowany na strumieniu i poza nim.)
Werdykt sanitize Firewalla redaguje dopasowane podłańcuchy z argumentów wywołania narzędzia przed przesłaniem — nigdy nie przepisuje tego, co narzędzie zwraca. Aby trzymać sekret całkowicie poza żądaniem, to zadanie guardrailu Secrets Blocker na płaszczyźnie tekstu.

​
6. Paczka zgodności: SOC 2 i PCI w jednej instalacji

Kontrole powyżej to implementacja. Audytor chce dowodu. Płaszczyzna Compliance domyka tę pętlę: przeglądaj katalog frameworków (bezpłatnie, każdy Member), potem zainstaluj paczkę jako Admin przestrzeni roboczej na płatnym planie. Instalacja paczki materializuje guardrails i polityki firewalla, które mapują się na kontrole frameworku — więc ta sama instalacja, która daje ci artefakt audytu, też stawia prawdziwe egzekwowanie. 
# 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
Potwierdzone paczki istotne dla agenta finansowego obejmują soc2 (AICPA SOC 2 Trust Services Criteria), pci_dss (PCI DSS 4.0), glba (Gramm-Leach-Bliley) oraz dora_eu (Digital Operational Resilience Act) — obok frameworków prywatności (gdpr, uk_gdpr, ccpa), frameworków bezpieczeństwa/AI (iso_27001, iso_42001, nist_ai_rmf, eu_ai_act, nist_800_53) oraz paczki owasp_llm (OWASP Top 10 for LLM Applications). Przejrzyj żywy katalog dla pełnego zestawu.

​
Raport, który audytor może zweryfikować

CoSzczegół
PodpisEd25519 nad hashem dowodu SHA-256 — odporny na manipulację
FormatyCSV / JSON / PDF
WeryfikacjaPubliczna — GET /api/public/compliance/pubkey, POST /api/public/compliance/verify
UdostępnianieLink audytora tylko do odczytu: GET /api/public/compliance/share/:token
Darmowy plan obejmuje jeden raport; eksport CSV/JSON i dodatkowe raporty są płatne. Generowanie raportu i wyjście na żywo są bramkowane po stronie serwera do planów płatnych — widoki katalogu i gotowości pozostają bezpłatne.

​
7. Rezydencja danych, retencja i usunięcie

Postawa klasy finansowej musi odpowiedzieć na „gdzie jest dowód i jak długo trzymasz logi”.
  • Rezydencja to region artefaktu raportu zgodności — us, eu, uk, ap, cn lub global, ustawiany przez PUT /api/compliance/residency (Admin). Odczyty z innego regionu są wstrzymywane. (To przypina artefakt, nie miejsce, gdzie działa inferencja.)
  • Retencja — logi żądań domyślnie wynoszą 30 dni i są ograniczane po stronie serwera do twardego maksimum 180 dni.
  • Usunięcie — samoobsługowe usunięcie konta wchodzi w okno 30-dniowej karencji, potem nieodwracalne szorowanie PII kaskaduje przez dopasowania guardrailu, logi żądań i zdarzenia firewalla.
Każda zmiana polityki, reguły i zgodności zapisuje wiersz audytu (przestrzeń robocza + centralny). Zmiany guardrailu i firewalla są też wersjonowane — zdiffuj i przywróć dowolny guardrail z jego zakładki History.

​
8. Zweryfikuj, zanim na tym polegniesz

Nie wdrażaj polityki finansowej na wiarę. Obie płaszczyzny mają piaskownicę, która nic nie persystuje i nic nie dyspozytuje:
  • Guardrails → Test — wklej próbkę, wybierz etap, zobacz werdykt i wyrenderowany (zamaskowany) tekst.
  • Firewall → Test (Developer+) — przepuść na sucho przykładowe wywołanie narzędzia i zobacz werdykt, dopasowaną regułę i powód.
Gdy jest na żywo, Firewall → Events / Runs to zapis per uruchomienie każdej ewaluacji, a strumień anomalii flaguje skoki tempa/kosztu wobec wyuczonej bazowej linii godziny-tygodnia przestrzeni roboczej, retry_loop oraz nigdy wcześniej niewidziane ścieżki narzędzi — dokładnie sygnały, które poprzedzają incydent finansowy.

​
Podsumowanie

Baza Secure Agents

Co materializuje tight i jak symulować przed zastosowaniem.

Reguły firewalla

Predykaty argumentów, limity kosztu, egress i sekwencje w głąb.

Dowody SOC 2

Zamień zmaterializowane kontrole w podpisany artefakt audytu.

Logowanie bezpieczne dla PII

Trzymaj dane kart i kont poza logami żądań.

Tryby egzekwowania

Obserwuj → cień → egzekwuj, bezpieczne wdrożenie dla narzędzi poruszających pieniędzmi.

Niebezpieczne wywołania narzędzi

Zagrożenie, przed którym broni lista dozwolonych narzędzi agenta finansowego.