Saltar al contenido principal
Un agente financiero concilia libros mayores, emite reembolsos, mueve dinero y lee datos de tarjeta y cuenta. El radio de explosión de una mala llamada a herramienta — un bucle de reembolsos descontrolado, un DROP en una tabla de libro mayor, números de tarjeta filtrándose a un prompt — se mide en dólares y hallazgos de auditoría. Esta receta ensambla los controles que hacen seguro ejecutar tal agente: autonomía tight como suelo, aprobación humana en las herramientas que mueven dinero, un tope de coste por ejecución como interruptor de circuito, y un pack de cumplimiento SOC 2 / PCI instalable que materializa la política y la evidencia firmada que un auditor pedirá.
Todo aquí se configura en la consola (Firewall → Posture / Policies, Guardrails, Compliance). Esas rutas de gestión usan tu sesión de consola, no una clave de relay — solo las llamadas /v1/* que hace tu agente llevan una clave sk-orca-…. Las ediciones de política requieren el rol Developer; la instalación de cumplimiento / go-live / residencia requieren Admin del espacio de trabajo y un plan de pago.

​
1. Por qué un agente de IA financiero seguro necesita más que guardrails

El cribado de contenido captura un número de tarjeta en un prompt. No detiene al agente de llamar a refund.issue diez mil veces, alcanzar un host interno 10.x, o ejecutar una migración destructiva. Una postura de grado financiero tiene que gobernar ambos planos a la vez:

El plano de texto

Los Guardrails criban el texto de solicitud y respuesta — PII enmascarada, secretos bloqueados, antes de que el modelo los vea siquiera.

El plano de acción

El Firewall gobierna cada llamada a herramienta, despacho MCP y solicitud saliente — allow, audit, deny, sanitize, retener o limitar coste.
Esta receta superpone cuatro controles uno sobre otro. Lee la línea base de Agentes Seguros y Guardrails vs Firewall primero si los dos planos aún no están claros.

​
2. Suelo: aplica autonomía tight

Empieza desde la postura de un solo interruptor más fuerte. En Firewall → Posture, aplica el nivel de autonomía tight (rol Developer). En una sola transacción establece ambos planos:
PlanoQué materializa tight
FirewallDefault-deny; deniega shell destructivo; deniega egress SSRF (nombres de herramienta con forma de fetch)
GuardrailsPII Shield + Secrets Blocker aplicados en las solicitudes
El interruptor de autonomía escribe filas de política y guardrail autonomy_* reales y editables — es una semilla, no una caja negra. Tiene deshacer de un clic desde un snapshot de auditoría.
En un agente que mueve dinero, no saltes directo a tight en producción. Aplícalo en modo shadow (o empieza en balanced) para que cada veredicto de aplicación se degrade a audit con una razón [shadow] would …. Vigila Firewall → Events / Runs, confirma que la política se dispara en lo que esperas, luego aplica.

​
3. Aprobaciones: retén las herramientas que mueven dinero para un humano (HITL)

El default-deny detiene lo que no permitiste. Las herramientas que sí permites pero que mueven dinero — refund.issue, payment.send, ledger.adjust — no deberían ser ni auto-permitidas ni auto-denegadas. Dales el veredicto pending_approval para que un humano lo apruebe fuera de banda. En Firewall → Policies, añade una regla por encima de tu valor por defecto:
  • Glob de herramienta: refund.* (o payment.send, ledger.adjust, …)
  • Veredicto: pending_approval
Cuando el agente la llama:
  1. La llamada retenida devuelve HTTP 400 firewall_approval_pending con un id de aprobación; la llamada no alcanza la herramienta.
  2. Un revisor la resuelve — desde la consola (Developer+), o vía un callback de webhook firmado con HMAC a tu propio sistema de aprobación en POST /api/v1/firewall/approvals/:id/callback.
  3. El agente hace polling de GET /api/v1/firewall/approvals/:id, luego reenvía la llamada original con una cabecera X-OrcaRouter-Firewall-Approval de un solo uso — el gateway la deja pasar esa única vez.
Fija un predicado de argumentos para que solo las operaciones grandes necesiten un humano: glob refund.issue con la cláusula JSONPath {"path":"$.amount_cents","op":"gt","value":50000}, veredicto pending_approval. Los reembolsos pequeños fluyen; un reembolso de $500+ espera a un revisor. Ver Reglas del firewall para el conjunto completo de operadores (eq, contains, regex, in, cidr_match, gt, lt).

​
4. Interruptor de circuito: limita el coste de una ejecución

Un agente financiero atascado en un bucle de reintento es tanto un bug de corrección como uno de facturación. Una regla cap_cost es el interruptor de bucles descontrolados: deniega una llamada a herramienta una vez que el gasto acumulado de la ejecución del agente cruza un tope de centavos por regla. Añade una regla con veredicto cap_cost y un techo cap_cost_cents — p. ej. 2000 (USD $20.00) — con alcance a las herramientas de tu agente. Una vez que el gasto en curso de una ejecución excede el tope, las llamadas posteriores en esa ejecución se deniegan; una ejecución nueva empieza limpia.
cap_cost limita el gasto de la ejecución del agente, no el presupuesto de por vida de una sola clave. Para un techo duro en una clave, establece credit_limit_usd en la clave API misma (0 = ilimitado) — los dos se componen: el presupuesto de la clave acota el gasto total, cap_cost acota cualquier ejecución.

​
5. Cinturón y tirantes en el plano de texto

tight ya aplica PII Shield y Secrets Blocker. Para un agente financiero, apóyate en los detalles:
El guardrail Secrets Blocker captura claves API y credenciales en el prompt antes de que el modelo las vea. Para datos de tarjeta, una regla pii con credit_card establecido a la acción block (vía entity_actions por entidad) rechaza la solicitud por completo con HTTP 400 guardrail_blocked — y un bloqueo no cuesta cuota (los bloqueos de entrada se disparan antes de la medición). Ver Guardrails §5.
El preset PII Shield es una única regla pii, mask, etapa both. El enmascarado en la etapa de entrada está en vivo: un iban o ssn en la solicitud se renderiza como [IBAN] / [SSN] antes de que el modelo sea llamado. (El enmascarado de salida/streaming en vivo está en el roadmap; el block de salida se aplica en streaming y no-streaming hoy.)
Un veredicto sanitize de Firewall redacta las subcadenas coincidentes de los argumentos de una llamada a herramienta antes de reenviar — nunca reescribe lo que una herramienta devuelve. Para mantener un secreto fuera de una solicitud por completo, ese es el trabajo del guardrail Secrets Blocker en el plano de texto.

​
6. El pack de cumplimiento: SOC 2 y PCI en una instalación

Los controles de arriba son la implementación. Un auditor quiere la evidencia. El plano de Compliance cierra ese bucle: navega el catálogo de marcos (gratis, cualquier Member), luego instala un pack como Admin del espacio de trabajo en un plan de pago. Instalar un pack materializa guardrails y políticas de firewall que mapean a los controles del marco — así que la misma instalación que te da el artefacto de auditoría también levanta aplicación 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
Los packs confirmados relevantes para un agente financiero incluyen soc2 (AICPA SOC 2 Trust Services Criteria), pci_dss (PCI DSS 4.0), glba (Gramm-Leach-Bliley) y dora_eu (Digital Operational Resilience Act) — junto a marcos de privacidad (gdpr, uk_gdpr, ccpa), marcos de seguridad/IA (iso_27001, iso_42001, nist_ai_rmf, eu_ai_act, nist_800_53) y el pack owasp_llm (OWASP Top 10 for LLM Applications). Navega el catálogo en vivo para el conjunto completo.

​
El informe que un auditor puede verificar

QuéDetalle
FirmaEd25519 sobre un hash de evidencia SHA-256 — a prueba de manipulación
FormatosCSV / JSON / PDF
VerificarPúblico — GET /api/public/compliance/pubkey, POST /api/public/compliance/verify
CompartirUn enlace de auditor de solo lectura: GET /api/public/compliance/share/:token
El plan gratuito incluye un informe; la exportación CSV/JSON y los informes adicionales son de pago. Generar un informe e ir en vivo están restringidos por servidor a planes de pago — el catálogo y las vistas de disposición se mantienen gratis.

​
7. Residencia de datos, retención y borrado

Una postura de grado financiero tiene que responder “dónde está la evidencia, y cuánto tiempo conservas los registros.”
  • La Residencia es la región del artefacto de informe de cumplimiento — us, eu, uk, ap, cn o global, establecida vía PUT /api/compliance/residency (Admin). Las lecturas inter-región se retienen. (Esto fija el artefacto, no dónde se ejecuta la inferencia.)
  • La Retención — los registros de solicitudes por defecto son 30 días y están acotados por el servidor a un máximo duro de 180 días.
  • El Borrado — una eliminación de cuenta autoservicio entra en una ventana de gracia de 30 días, luego una limpieza de PII irreversible cae en cascada a través de las coincidencias de guardrail, los registros de solicitudes y los eventos de firewall.
Cada cambio de política, regla y cumplimiento escribe una fila de auditoría (espacio de trabajo + central). Los cambios de guardrail y firewall también están versionados — diff y revierte cualquier guardrail desde su pestaña History.

​
8. Verifica antes de depender de ello

No lances una política financiera por fe. Ambos planos tienen un sandbox que no persiste nada y no despacha nada:
  • Guardrails → Test — pega una muestra, elige una etapa, ve el veredicto y el texto renderizado (enmascarado).
  • Firewall → Test (Developer+) — ejecuta en seco una llamada a herramienta de muestra y ve el veredicto, la regla coincidente y la razón.
Una vez en vivo, Firewall → Events / Runs es el registro por ejecución de cada evaluación, y el feed de anomalías marca picos de tasa/coste contra la línea base aprendida de hora-de-la-semana del espacio de trabajo, retry_loop y rutas de herramienta nunca antes vistas — exactamente las señales que preceden a un incidente financiero.

​
Resumen

Línea base de Agentes Seguros

Qué materializa tight, y cómo simular antes de aplicar.

Reglas del firewall

Predicados de argumentos, topes de coste, egress y secuencias en profundidad.

Evidencia SOC 2

Convierte los controles materializados en un artefacto de auditoría firmado.

Registro seguro de PII

Mantén los datos de tarjeta y cuenta fuera de tus registros de solicitudes.

Modos de aplicación

Observe → shadow → enforce, el lanzamiento seguro para herramientas que mueven dinero.

Llamadas a herramientas peligrosas

La amenaza contra la que la lista de permitidos de herramientas de un agente financiero defiende.