Vai al contenuto principale
Un agent finanziario riconcilia registri contabili, emette rimborsi, muove denaro e legge dati di carte e conti. Il blast radius di una sola chiamata a tool sbagliata — un loop di rimborsi fuori controllo, un DROP su una tabella di registro, numeri di carta che trapelano in un prompt — si misura in dollari e finding di audit. Questa ricetta assembla i controlli che rendono sicuro eseguire un tale agent: autonomia tight come pavimento, approvazione umana sui tool che muovono denaro, un cap di costo per esecuzione come interruttore di sicurezza, e un compliance pack SOC 2 / PCI installabile che materializza la policy e l’evidenza firmata che un auditor chiederà.
Tutto qui è configurato nella console (Firewall → Posture / Policies, Guardrails, Compliance). Quelle rotte di gestione usano la tua sessione di console, non una chiave di relay — solo le chiamate /v1/* che il tuo agent fa portano una chiave sk-orca-…. Le modifiche alla policy richiedono il ruolo Developer; install / go-live / residency di compliance richiedono Admin del workspace e un piano a pagamento.

​
1. Perché un agent AI finanziario sicuro ha bisogno di più dei guardrail

Lo screening dei contenuti coglie un numero di carta in un prompt. Non impedisce all’agent di chiamare refund.issue diecimila volte, di raggiungere un host interno 10.x, o di eseguire una migrazione distruttiva. Una postura di grado finanziario deve governare entrambi i piani in una volta:

Il piano del testo

I Guardrails filtrano il testo di richiesta e risposta — PII mascherate, segreti bloccati, prima che il modello li veda mai.

Il piano delle azioni

Il Firewall governa ogni chiamata a tool, dispatch MCP e richiesta in uscita — allow, audit, deny, sanitize, hold, o cap di costo.
Questa ricetta sovrappone quattro controlli l’uno sull’altro. Leggi prima la baseline Secure Agents e Guardrails vs Firewall se i due piani non sono ancora chiari.

​
2. Pavimento: applica l’autonomia tight

Parti dalla postura a un solo interruttore più forte. In Firewall → Posture, applica il livello di autonomia tight (ruolo Developer). In una singola transazione imposta entrambi i piani:
PianoCosa materializza tight
FirewallDefault-deny; nega la shell distruttiva; nega l’egress SSRF (nomi di tool a forma di fetch)
GuardrailsPII Shield + Secrets Blocker applicati sulle richieste
L’interruttore di autonomia scrive righe autonomy_* di policy e guardrail reali e modificabili — è un seme, non una scatola nera. Ha undo a un clic da uno snapshot di audit.
Su un agent che muove denaro, non passare dritto a tight in produzione. Applicalo in shadow mode (o parti da balanced) così ogni verdetto applicativo viene declassato a audit con una motivazione [shadow] would …. Osserva Firewall → Events / Runs, conferma che la policy scatti su ciò che ti aspetti, poi applica.

​
3. Approvazioni: metti in attesa di un umano i tool che muovono denaro (HITL)

Il default-deny ferma ciò che non hai consentito. I tool che consenti ma che muovono denaro — refund.issue, payment.send, ledger.adjust — non dovrebbero essere né auto-consentiti né auto-negati. Dai loro il verdetto pending_approval così un umano firma fuori banda. In Firewall → Policies, aggiungi una regola sopra il tuo default:
  • Tool glob: refund.* (o payment.send, ledger.adjust, …)
  • Verdetto: pending_approval
Quando l’agent la chiama:
  1. La chiamata held restituisce HTTP 400 firewall_approval_pending con un id di approvazione; la chiamata non raggiunge il tool.
  2. Un revisore la risolve — dalla console (Developer+), o tramite un webhook callback firmato con HMAC verso il tuo sistema di approvazione a POST /api/v1/firewall/approvals/:id/callback.
  3. L’agent fa polling su GET /api/v1/firewall/approvals/:id, poi ri-invia la chiamata originale con un header monouso X-OrcaRouter-Firewall-Approval — il gateway la lascia passare quella sola volta.
Fissa un predicato sugli argomenti così solo le operazioni grandi hanno bisogno di un umano: glob refund.issue con la clausola JSONPath {"path":"$.amount_cents","op":"gt","value":50000}, verdetto pending_approval. I piccoli rimborsi scorrono; un rimborso di 500$+ aspetta un revisore. Vedi Regole del firewall per l’insieme completo di operatori (eq, contains, regex, in, cidr_match, gt, lt).

​
4. Interruttore di sicurezza: limita il costo di un’esecuzione

Un agent finanziario bloccato in un loop di retry è sia un bug di correttezza sia uno di fatturazione. Una regola cap_cost è l’interruttore per i loop fuori controllo: nega una chiamata a tool una volta che la spesa accumulata dell’esecuzione dell’agent supera un cap in centesimi per regola. Aggiungi una regola con verdetto cap_cost e un tetto cap_cost_cents — es. 2000 (USD $20.00) — con scope sui tool del tuo agent. Una volta che la spesa corrente di un’esecuzione supera il cap, ulteriori chiamate in quell’esecuzione vengono negate; una nuova esecuzione parte pulita.
cap_cost limita la spesa dell’esecuzione dell’agent, non il budget di vita di una singola chiave. Per un tetto rigido su una chiave, imposta credit_limit_usd sulla chiave API stessa (0 = illimitato) — i due si compongono: il budget della chiave limita la spesa totale, cap_cost limita una qualsiasi esecuzione.

​
5. Cintura-e-bretelle sul piano del testo

tight applica già PII Shield e Secrets Blocker. Per un agent finanziario, appoggiati alle specifiche:
Il guardrail Secrets Blocker coglie chiavi API e credenziali nel prompt prima che il modello le veda. Per i dati di carta, una regola pii con credit_card impostato sull’azione block (tramite entity_actions per-entità) respinge del tutto la richiesta con HTTP 400 guardrail_blocked — e un block non costa quota (i block di input scattano prima del metering). Vedi Guardrails §5.
Il preset PII Shield è una singola regola pii, mask, stage both. Il masking allo stage di input è attivo: un iban o un ssn nella richiesta è reso come [IBAN] / [SSN] prima che il modello venga chiamato. (Il masking live output/streaming è nella roadmap; il block dell’output è applicato su streaming e non-streaming oggi.)
Un verdetto sanitize del Firewall redige le sottostringhe corrispondenti dagli argomenti di una chiamata a tool prima di inoltrare — non riscrive mai ciò che un tool restituisce. Per tenere del tutto un segreto fuori da una richiesta, quello è il compito del guardrail Secrets Blocker sul piano del testo.

​
6. Il compliance pack: SOC 2 e PCI in un’installazione

I controlli sopra sono l’implementazione. Un auditor vuole l’evidenza. Il piano Compliance chiude quel loop: sfoglia il catalogo dei framework (gratuito, qualsiasi Member), poi installa un pack come Admin del workspace su un piano a pagamento. Installare un pack materializza guardrail e policy del firewall che mappano sui controlli del framework — così la stessa installazione che ti dà l’artefatto di audit erige anche un’applicazione reale. 
# Azione di console (sessione UserAuth) — installa il pack PCI DSS
POST /api/compliance/packs/pci_dss/install
# poi, quando sei pronto ad applicare:
POST /api/compliance/packs/pci_dss/golive
I pack confermati rilevanti per un agent finanziario includono soc2 (AICPA SOC 2 Trust Services Criteria), pci_dss (PCI DSS 4.0), glba (Gramm-Leach-Bliley), e dora_eu (Digital Operational Resilience Act) — accanto a framework sulla privacy (gdpr, uk_gdpr, ccpa), framework di sicurezza/AI (iso_27001, iso_42001, nist_ai_rmf, eu_ai_act, nist_800_53), e il pack owasp_llm (OWASP Top 10 for LLM Applications). Sfoglia il catalogo live per l’insieme completo.

​
Il report che un auditor può verificare

CosaDettaglio
FirmaEd25519 su un hash di evidenza SHA-256 — a prova di manomissione
FormatiCSV / JSON / PDF
VerificaPubblica — GET /api/public/compliance/pubkey, POST /api/public/compliance/verify
CondivisioneUn link auditor in sola lettura: GET /api/public/compliance/share/:token
Il piano gratuito include un report; l’export CSV/JSON e i report aggiuntivi sono a pagamento. Generare un report e andare live sono server-gated ai piani a pagamento — le viste catalogo e readiness restano gratuite.

​
7. Data residency, retention e cancellazione

Una postura di grado finanziario deve rispondere a “dov’è l’evidenza, e per quanto tieni i log”.
  • La Residency è la regione dell’artefatto del report di compliance — us, eu, uk, ap, cn, o global, impostata tramite PUT /api/compliance/residency (Admin). Le letture cross-region sono negate. (Questo fissa l’artefatto, non dove gira l’inferenza.)
  • La Retention — i request-log sono di default 30 giorni e sono clampati lato server a un max rigido di 180 giorni.
  • La Cancellazione — una cancellazione self-service dell’account entra in una finestra di grace di 30 giorni, poi una purga irreversibile delle PII fa cascata attraverso i guardrail match, i request-log e i firewall event.
Ogni modifica a policy, regola e compliance scrive una riga di audit (workspace + centrale). Le modifiche a guardrail e firewall sono anche versionate — fai diff e revert di qualsiasi guardrail dal suo tab History.

​
8. Verifica prima di farci affidamento

Non spedire una policy finanziaria sulla fiducia. Entrambi i piani hanno una sandbox che non persiste nulla e non dispatcha nulla:
  • Guardrails → Test — incolla un campione, scegli uno stage, vedi il verdetto e il testo renderizzato (mascherato).
  • Firewall → Test (Developer+) — esegui in dry-run una chiamata a tool di esempio e vedi il verdetto, la regola corrispondente e la motivazione.
Una volta live, Firewall → Events / Runs è il record per-esecuzione di ogni valutazione, e il feed delle anomalie segnala picchi di rate/costo rispetto alla baseline ora-della-settimana appresa del workspace, retry_loop e percorsi di tool mai visti prima — esattamente i segnali che precedono un incidente finanziario.

​
Ricapitolando

Baseline Secure Agents

Cosa materializza tight, e come simulare prima di applicare.

Regole del firewall

Predicati sugli argomenti, cap di costo, egress e sequenze in profondità.

Evidenza SOC 2

Trasforma i controlli materializzati in un artefatto di audit firmato.

Logging PII-safe

Tieni i dati di carta e conto fuori dai tuoi request-log.

Modalità di applicazione

Observe → shadow → enforce, il rollout sicuro per i tool che muovono denaro.

Chiamate a tool pericolose

Il threat contro cui la allow-list di tool di un agent finanziario si difende.