Rules of Engagement
pattern detail

financial-actions-standing

Escalates or blocks money movement, refunds, and payment changes unless an operator has explicitly authorized the action path.

doctrinal basis

Positive Identification (PID), proportionality, and standing vs. special ROE.

Use the summary here for context, then inspect the YAML or related patterns for the concrete rule path.

What it catches

  • Prompt injection that tries to convert a support task into a refund or wire action.
  • Scope creep from “draft the response” into “issue the refund now.”
  • High-blast-radius disbursements where the amount exceeds a standing cap.

Related patterns

Download YAML Back to library
policy yaml

The downloadable policy stays available below, but the inline YAML now wraps cleanly for narrow screens.

name: financial-actions-standing
version: 1.1.0
doctrinal_basis: Standing ROE / standing rules for use of force map to always-on financial authority boundaries; proportionality and collateral damage estimation map to amount_usd blast-radius caps; escalation of force maps to human approval before higher-risk financial actions proceed.
description: Standing financial-action guardrails for agent-initiated refunds, transfers, payouts, vendor bank-account changes, tax filings, credential access, and financial reads.
rules:
  - id: deny-financial-credential-access
    applies_to:
      action_class:
        - financial.credentials.*
        - financial.payment_method.secret.*
    decision: deny
    reasoning: Standing financial ROE denies direct credential or payment-secret access; use a scoped payment provider operation instead.

  - id: deny-high-value-money-movement
    applies_to:
      action_class:
        - financial.refund
        - financial.transfer
        - financial.payout
        - financial.invoice.pay
    conditions:
      - type: blast_radius_max
        parameter: amount_usd
        threshold: 10000
    decision: deny
    reasoning: Requested money movement for $${amount_usd} exceeds the standing $10000 hard cap for autonomous financial movement.

  - id: escalate-money-movement
    applies_to:
      action_class:
        - financial.refund
        - financial.transfer
        - financial.payout
        - financial.invoice.pay
    decision: escalate
    escalation:
      requires: human_approval
      via: finance-ops
    reasoning: Money movement requires finance approval under standing financial ROE before execution.

  - id: escalate-vendor-bank-account-change
    applies_to:
      action_class:
        - financial.vendor.bank_account.update
        - financial.vendor.payment_method.update
    decision: escalate
    escalation:
      requires: both
      via: finance-ops
    reasoning: Vendor payment-routing changes require both operator justification and finance approval before execution.

  - id: escalate-tax-or-regulatory-filing
    applies_to:
      action_class:
        - financial.tax.filing.submit
        - financial.regulatory.report.submit
    decision: escalate
    escalation:
      requires: both
      via: finance-legal
    reasoning: Tax and regulatory submissions require both operator justification and legal/finance approval before execution.

  - id: allow-financial-readonly
    applies_to:
      action_class:
        - financial.read.*
        - financial.report.view
        - financial.invoice.view
    decision: allow
    reasoning: Read-only financial lookup is authorized under standing ROE when it does not mutate funds, credentials, routing, tax, or regulatory state.