Saltar para o conteúdo principal
Um agente financeiro reconcilia ledgers, emite reembolsos, move dinheiro e lê dados de cartão e de conta. O raio de explosão de uma chamada de ferramenta ruim — um loop de reembolso descontrolado, um DROP numa tabela de ledger, números de cartão vazando para um prompt — é medido em dólares e achados de auditoria. Esta receita monta os controles que tornam tal agente seguro de rodar: autonomia tight como o piso, aprovação humana nas ferramentas que movem dinheiro, um limite de custo por run como o disjuntor e um pack de compliance SOC 2 / PCI instalável que materializa a política e a evidência assinada que um auditor vai pedir.
Tudo aqui é configurado no console (Firewall → Posture / Policies, Guardrails, Compliance). Essas rotas de gerenciamento usam a sua sessão de console, não uma chave de relay — apenas as chamadas /v1/* que o seu agente faz carregam uma chave sk-orca-…. Edições de política exigem o papel Developer; install / go-live / residência de compliance exigem Admin do workspace e um plano pago.

​
1. Por que um agente de IA financeiro seguro precisa de mais que guardrails

A triagem de conteúdo captura um número de cartão num prompt. Ela não impede o agente de chamar refund.issue dez mil vezes, alcançar um host interno 10.x ou rodar uma migração destrutiva. Uma postura de nível financeiro tem que governar ambos os planos de uma vez:

O plano de texto

Os Guardrails filtram o texto de requisição e resposta — PII mascarada, segredos bloqueados, antes que o modelo os veja.

O plano de ação

O Firewall governa cada chamada de ferramenta, dispatch de MCP e requisição outbound — allow, audit, deny, sanitize, retém ou limita o custo.
Esta receita sobrepõe quatro controles uns sobre os outros. Leia a linha de base de Agentes Seguros e Guardrails vs. Firewall primeiro se os dois planos ainda não estão claros.

​
2. Piso: aplique autonomia tight

Comece pela postura de um interruptor mais forte. Em Firewall → Posture, aplique o nível de autonomia tight (papel Developer). Em uma única transação ele define ambos os planos:
PlanoO que tight materializa
FirewallDefault-deny; nega shell destrutivo; nega egress SSRF (nomes de ferramenta no formato de fetch)
GuardrailsPII Shield + Secrets Blocker aplicados nas requisições
O interruptor de autonomia escreve linhas de política autonomy_* e de guardrail reais e editáveis — é uma semente, não uma caixa-preta. Ele tem desfazer em um clique a partir de um snapshot de auditoria.
Em um agente que move dinheiro, não vire direto para tight em produção. Aplique-o em shadow mode (ou comece em balanced) para que todo veredito de enforcement seja rebaixado para audit com um motivo [shadow] would …. Observe Firewall → Events / Runs, confirme que a política dispara no que você espera, depois aplique enforcement.

​
3. Aprovações: retenha as ferramentas que movem dinheiro para um humano (HITL)

Default-deny para o que você não permitiu. As ferramentas que você de fato permite mas que movem dinheiro — refund.issue, payment.send, ledger.adjust — não deveriam ser nem auto-permitidas nem auto-negadas. Dê a elas o veredito pending_approval para que um humano aprove fora de banda. Em Firewall → Policies, adicione uma regra acima do seu padrão:
  • Tool glob: refund.* (ou payment.send, ledger.adjust, …)
  • Veredito: pending_approval
Quando o agente a chama:
  1. A chamada retida retorna HTTP 400 firewall_approval_pending com um id de aprovação; a chamada não chega à ferramenta.
  2. Um revisor a resolve — a partir do console (Developer+), ou via um callback de webhook assinado por HMAC para o seu próprio sistema de aprovação em POST /api/v1/firewall/approvals/:id/callback.
  3. O agente consulta GET /api/v1/firewall/approvals/:id, depois reenvia a chamada original com um header X-OrcaRouter-Firewall-Approval de uso único — o gateway a deixa passar aquela única vez.
Fixe um predicado de argumento para que apenas as operações grandes precisem de um humano: glob refund.issue com a cláusula JSONPath {"path":"$.amount_cents","op":"gt","value":50000}, veredito pending_approval. Reembolsos pequenos fluem; um reembolso de $500+ espera por um revisor. Veja Regras de firewall para o conjunto completo de operadores (eq, contains, regex, in, cidr_match, gt, lt).

​
4. Disjuntor: limite o custo de uma run

Um agente financeiro preso num loop de retry é tanto um bug de correção quanto de billing. Uma regra cap_cost é o disjuntor de loop descontrolado: ela nega uma chamada de ferramenta assim que o gasto acumulado da run do agente cruza um limite por regra em centavos. Adicione uma regra com veredito cap_cost e um teto cap_cost_cents — ex.: 2000 (USD $20,00) — escopado às ferramentas do seu agente. Assim que o gasto corrente de uma run excede o limite, as chamadas seguintes naquela run são negadas; uma run nova começa limpa.
cap_cost limita o gasto da run do agente, não o orçamento vitalício de uma única chave. Para um teto rígido em uma chave, defina credit_limit_usd na própria chave de API (0 = ilimitado) — os dois se compõem: o orçamento da chave limita o gasto total, cap_cost limita qualquer run individual.

​
5. Reforço duplo no plano de texto

tight já aplica PII Shield e Secrets Blocker. Para um agente financeiro, apoie-se nas especificidades:
O guardrail Secrets Blocker captura chaves de API e credenciais no prompt antes que o modelo as veja. Para dados de cartão, uma regra pii com credit_card definido para a ação block (via entity_actions por entidade) rejeita a requisição de imediato com HTTP 400 guardrail_blocked — e um block custa nenhuma cota (blocks de input disparam antes da medição). Veja Guardrails §5.
O preset PII Shield é uma única regra pii, mask, stage both. A máscara no stage input está disponível: um iban ou ssn na requisição é renderizado como [IBAN] / [SSN] antes do modelo ser chamado. (A máscara ao vivo de output/streaming está no roadmap; o block de output é aplicado em streaming e não-streaming hoje.)
Um veredito de Firewall sanitize redige substrings correspondentes dos argumentos de uma chamada de ferramenta antes de encaminhar — ele nunca reescreve o que uma ferramenta retorna. Para manter um segredo inteiramente fora de uma requisição, essa é a tarefa do guardrail Secrets Blocker no plano de texto.

​
6. O pack de compliance: SOC 2 e PCI em um install

Os controles acima são a implementação. Um auditor quer a evidência. O plano de Compliance fecha esse ciclo: navegue pelo catálogo de frameworks (gratuito, qualquer Member), depois instale um pack como Admin do workspace em um plano pago. Instalar um pack materializa guardrails e políticas de firewall que mapeiam para os controles do framework — então o mesmo install que lhe dá o artefato de auditoria também levanta enforcement real. 
# 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
Packs confirmados relevantes para um agente financeiro incluem soc2 (AICPA SOC 2 Trust Services Criteria), pci_dss (PCI DSS 4.0), glba (Gramm-Leach-Bliley) e dora_eu (Digital Operational Resilience Act) — ao lado de frameworks de privacidade (gdpr, uk_gdpr, ccpa), frameworks de segurança/IA (iso_27001, iso_42001, nist_ai_rmf, eu_ai_act, nist_800_53) e o pack owasp_llm (OWASP Top 10 for LLM Applications). Navegue pelo catálogo ao vivo para o conjunto completo.

​
O relatório que um auditor pode verificar

O quêDetalhe
AssinaturaEd25519 sobre um hash de evidência SHA-256 — à prova de adulteração
FormatosCSV / JSON / PDF
VerificarPúblico — GET /api/public/compliance/pubkey, POST /api/public/compliance/verify
CompartilharUm link de auditor somente leitura: GET /api/public/compliance/share/:token
O plano gratuito inclui um relatório; export CSV/JSON e relatórios adicionais são pagos. Gerar um relatório e ir ao ar são controlados pelo servidor para planos pagos — o catálogo e as visões de prontidão permanecem gratuitos.

​
7. Residência de dados, retenção e apagamento

Uma postura de nível financeiro tem que responder “onde está a evidência, e por quanto tempo você mantém os logs.”
  • Residência é a região do artefato de relatório de compliance — us, eu, uk, ap, cn ou global, definida via PUT /api/compliance/residency (Admin). Leituras cross-region são retidas. (Isso fixa o artefato, não onde a inferência roda.)
  • Retenção — os request logs têm padrão de 30 dias e são limitados pelo servidor a um máximo rígido de 180 dias.
  • Apagamento — uma exclusão de conta self-service entra em uma janela de carência de 30 dias, depois uma limpeza irreversível de PII cascateia através de guardrail matches, request logs e firewall events.
Toda mudança de política, regra e compliance escreve uma linha de auditoria (workspace + central). Mudanças de guardrail e firewall também são versionadas — compare e reverta qualquer guardrail a partir de sua aba History.

​
8. Verifique antes de depender disso

Não lance uma política financeira na fé. Ambos os planos têm um sandbox que não persiste nada e não despacha nada:
  • Guardrails → Test — cole uma amostra, escolha um stage, veja o veredito e o texto renderizado (mascarado).
  • Firewall → Test (Developer+) — faça um dry-run de uma chamada de ferramenta de amostra e veja o veredito, a regra correspondente e o motivo.
Uma vez ao vivo, Firewall → Events / Runs é o registro por run de cada avaliação, e o feed de anomalias sinaliza picos de taxa/custo contra a baseline aprendida de hora-da-semana do workspace, retry_loop e caminhos de ferramenta nunca antes vistos — exatamente os sinais que precedem um incidente financeiro.

​
Recapitulação

Linha de base de Agentes Seguros

O que tight materializa, e como simular antes de aplicar.

Regras de firewall

Predicados de argumento, limites de custo, egress e sequências em profundidade.

Evidência SOC 2

Transforme os controles materializados em um artefato de auditoria assinado.

Logging seguro de PII

Mantenha dados de cartão e de conta fora dos seus request logs.

Modos de enforcement

Observe → shadow → enforce, o rollout seguro para ferramentas que movem dinheiro.

Chamadas de ferramenta perigosas

A ameaça contra a qual a allow-list de ferramentas de um agente financeiro defende.