Passer au contenu principal
Un agent finance réconcilie des grands livres, émet des remboursements, déplace de l’argent, et lit des données de carte et de compte. Le rayon d’explosion d’un seul mauvais appel d’outil — une boucle de remboursement emballée, un DROP sur une table de grand livre, des numéros de carte fuitant dans un prompt — se mesure en dollars et en constatations d’audit. Cette recette assemble les contrôles qui rendent un tel agent sûr à exécuter : l’autonomie tight comme plancher, l’approbation humaine sur les outils qui déplacent de l’argent, un plafond de coût par exécution comme disjoncteur, et un pack de conformité SOC 2 / PCI installable qui matérialise la politique et la preuve signée qu’un auditeur demandera.
Tout ici est configuré dans la console (Firewall → Posture / Politiques, Guardrails, Conformité). Ces routes de gestion utilisent votre session de console, pas une clé de relais — seuls les appels /v1/* que votre agent effectue portent une clé sk-orca-…. Les éditions de politique nécessitent le rôle Developer ; l’installation de conformité / le go-live / la résidence nécessitent Admin de l’espace de travail et un plan payant.

​
1. Pourquoi un agent IA finance sécurisé a besoin de plus que des guardrails

Le dépistage de contenu attrape un numéro de carte dans un prompt. Il n’empêche pas l’agent d’appeler refund.issue dix mille fois, d’atteindre un hôte interne 10.x, ou d’exécuter une migration destructrice. Une posture de qualité finance doit gouverner les deux plans à la fois :

Le plan texte

Les Guardrails filtrent le texte de requête et de réponse — PII masquée, secrets bloqués, avant que le modèle ne les voie jamais.

Le plan action

Le Firewall gouverne chaque appel d’outil, dispatch MCP, et requête sortante — allow, audit, deny, sanitize, hold, ou cap cost.
Cette recette superpose quatre contrôles les uns sur les autres. Lisez d’abord le référentiel Secure Agents et Guardrails vs Firewall si les deux plans ne sont pas encore clairs.

​
2. Plancher : appliquez l’autonomie tight

Partez de la posture à un seul interrupteur la plus forte. Dans Firewall → Posture, appliquez le niveau d’autonomie tight (rôle Developer). En une seule transaction, il définit les deux plans :
PlanCe que tight matérialise
FirewallDeny par défaut ; refuse le shell destructeur ; refuse l’egress SSRF (noms d’outils de forme « fetch »)
GuardrailsPII Shield + Secrets Blocker appliqués sur les requêtes
L’interrupteur d’autonomie écrit de vraies lignes de politique et de guardrail autonomy_* éditables — c’est une graine, pas une boîte noire. Il dispose d’une annulation en un clic à partir d’un snapshot d’audit.
Sur un agent qui déplace de l’argent, ne basculez pas directement sur tight en production. Appliquez-le en mode shadow (ou commencez à balanced) afin que chaque verdict appliquant soit rétrogradé en audit avec une raison [shadow] would …. Surveillez Firewall → Events / Runs, confirmez que la politique se déclenche sur ce que vous attendez, puis appliquez.

​
3. Approbations : mettez les outils qui déplacent de l’argent en attente d’un humain (HITL)

Le deny par défaut arrête ce que vous n’avez pas autorisé. Les outils que vous autorisez bel et bien mais qui déplacent de l’argent — refund.issue, payment.send, ledger.adjust — ne devraient être ni auto-autorisés ni auto-refusés. Donnez-leur le verdict pending_approval afin qu’un humain donne son aval hors-bande. Dans Firewall → Policies, ajoutez une règle au-dessus de votre défaut :
  • Glob d’outil : refund.* (ou payment.send, ledger.adjust, …)
  • Verdict : pending_approval
Quand l’agent l’appelle :
  1. L’appel mis en attente renvoie une HTTP 400 firewall_approval_pending avec un id d’approbation ; l’appel n’atteint pas l’outil.
  2. Un relecteur le résout — depuis la console (Developer+), ou via un callback webhook signé HMAC vers votre propre système d’approbation à POST /api/v1/firewall/approvals/:id/callback.
  3. L’agent interroge GET /api/v1/firewall/approvals/:id, puis re-soumet l’appel d’origine avec un en-tête X-OrcaRouter-Firewall-Approval à usage unique — la passerelle le laisse passer cette fois-là.
Épinglez un prédicat d’argument afin que seules les grandes opérations nécessitent un humain : glob refund.issue avec la clause JSONPath {"path":"$.amount_cents","op":"gt","value":50000}, verdict pending_approval. Les petits remboursements circulent ; un remboursement de 500 $+ attend un relecteur. Voir Règles du firewall pour le jeu d’opérateurs complet (eq, contains, regex, in, cidr_match, gt, lt).

​
4. Disjoncteur : plafonnez le coût d’une exécution

Un agent finance bloqué dans une boucle de retry est à la fois un bug de correction et un bug de facturation. Une règle cap_cost est le coupe-circuit de boucle emballée : elle refuse un appel d’outil une fois que la dépense accumulée de l’exécution de l’agent franchit un plafond en centimes par règle. Ajoutez une règle avec le verdict cap_cost et un plafond cap_cost_cents — par ex. 2000 (USD 20,00 $) — scopée aux outils de votre agent. Une fois que la dépense courante d’une exécution dépasse le plafond, les appels ultérieurs de cette exécution sont refusés ; une nouvelle exécution démarre proprement.
cap_cost plafonne la dépense de l’exécution de l’agent, pas le budget à vie d’une seule clé. Pour un plafond strict sur une clé, définissez credit_limit_usd sur la clé API elle-même (0 = illimité) — les deux se composent : le budget de la clé borne la dépense totale, cap_cost borne toute exécution unique.

​
5. Ceinture et bretelles sur le plan texte

tight applique déjà PII Shield et Secrets Blocker. Pour un agent finance, appuyez-vous sur les spécificités :
Le guardrail Secrets Blocker attrape les clés API et identifiants dans le prompt avant que le modèle ne les voie. Pour les données de carte, une règle pii avec credit_card réglé sur l’action block (via entity_actions par entité) rejette la requête purement et simplement avec une HTTP 400 guardrail_blocked — et un block ne coûte aucun quota (les blocks d’input se déclenchent avant le metering). Voir Guardrails §5.
Le preset PII Shield est une seule règle pii, mask, stage both. Le masquage au stade input est actif : un iban ou un ssn dans la requête est rendu comme [IBAN] / [SSN] avant que le modèle ne soit appelé. (Le masquage en direct output/streaming est sur la feuille de route ; le block de sortie est appliqué en streaming et non-streaming aujourd’hui.)
Un verdict sanitize du Firewall redacte les sous-chaînes correspondantes des arguments d’un appel d’outil avant de transmettre — il ne réécrit jamais ce qu’un outil renvoie. Pour garder un secret entièrement hors d’une requête, c’est le travail du guardrail Secrets Blocker sur le plan texte.

​
6. Le pack de conformité : SOC 2 et PCI en une seule installation

Les contrôles ci-dessus sont l’implémentation. Un auditeur veut la preuve. Le plan Conformité ferme cette boucle : parcourez le catalogue de frameworks (gratuit, tout Member), puis installez un pack en tant qu’Admin de l’espace de travail sur un plan payant. Installer un pack matérialise des guardrails et politiques firewall qui correspondent aux contrôles du framework — de sorte que la même installation qui vous donne l’artefact d’audit met aussi en place une application réelle. 
# 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
Les packs confirmés pertinents pour un agent finance incluent soc2 (AICPA SOC 2 Trust Services Criteria), pci_dss (PCI DSS 4.0), glba (Gramm-Leach-Bliley), et dora_eu (Digital Operational Resilience Act) — aux côtés des frameworks de confidentialité (gdpr, uk_gdpr, ccpa), des frameworks de sécurité/IA (iso_27001, iso_42001, nist_ai_rmf, eu_ai_act, nist_800_53), et du pack owasp_llm (OWASP Top 10 for LLM Applications). Parcourez le catalogue en direct pour le jeu complet.

​
Le rapport qu’un auditeur peut vérifier

QuoiDétail
SignatureEd25519 sur un hash de preuve SHA-256 — inviolable
FormatsCSV / JSON / PDF
VérifierPublic — GET /api/public/compliance/pubkey, POST /api/public/compliance/verify
PartagerUn lien auditeur en lecture seule : GET /api/public/compliance/share/:token
Le plan gratuit inclut un rapport ; l’export CSV/JSON et les rapports supplémentaires sont payants. Générer un rapport et passer en direct sont soumis côté serveur aux plans payants — le catalogue et les vues d’état de préparation restent gratuits.

​
7. Résidence des données, rétention et effacement

Une posture de qualité finance doit répondre à « où est la preuve, et combien de temps gardez-vous les journaux ».
  • La résidence est la région de l’artefact de rapport de conformité — us, eu, uk, ap, cn, ou global, définie via PUT /api/compliance/residency (Admin). Les lectures inter-régions sont refusées. (Cela épingle l’artefact, pas l’endroit où l’inférence s’exécute.)
  • Rétention — les journaux de requêtes valent 30 jours par défaut et sont bornés côté serveur à un max strict de 180 jours.
  • Effacement — une suppression de compte en libre-service entre dans une fenêtre de grâce de 30 jours, puis un nettoyage PII irréversible se propage en cascade à travers les matches de guardrail, les journaux de requêtes, et les événements firewall.
Chaque changement de politique, de règle et de conformité écrit une ligne d’audit (espace de travail + central). Les changements de guardrail et de firewall sont aussi versionnés — comparez et restaurez n’importe quel guardrail depuis son onglet History.

​
8. Vérifiez avant d’en dépendre

Ne déployez pas une politique finance sur la foi. Les deux plans ont une sandbox qui ne persiste rien et ne dispatche rien :
  • Guardrails → Test — collez un échantillon, choisissez un stage, voyez le verdict et le texte rendu (masqué).
  • Firewall → Test (Developer+) — exécutez en dry-run un appel d’outil d’échantillon et voyez le verdict, la règle correspondante et la raison.
Une fois en direct, Firewall → Events / Runs est l’enregistrement par exécution de chaque évaluation, et le flux d’anomalies signale les pics de débit/coût contre la baseline heure-de-la-semaine apprise de l’espace de travail, retry_loop, et les chemins d’outils jamais vus auparavant — exactement les signaux qui précèdent un incident financier.

​
Récapitulatif

Référentiel Secure Agents

Ce que tight matérialise, et comment simuler avant d’appliquer.

Règles du firewall

Prédicats d’arguments, plafonds de coût, egress, et séquences en profondeur.

Preuve SOC 2

Transformez les contrôles matérialisés en un artefact d’audit signé.

Journalisation sans PII

Gardez les données de carte et de compte hors de vos journaux de requêtes.

Modes d'application

Observe → shadow → enforce, le déploiement sûr pour les outils qui déplacent de l’argent.

Appels d'outils dangereux

La menace contre laquelle l’allow-list d’outils d’un agent finance se défend.