Spend Controls Configurator — Guide

An agent that can execute payments without limits is a significant operational risk. A single software bug, misconfigured retry loop, or malicious prompt injection could drain funds before any engineer notices. The Spend Controls Configurator generates the configuration and infrastructure that caps what an agent can spend — and stops it automatically when limits are hit.

The tool addresses Agent Safety Layer 6 — the financial guardrails layer in a defence-in-depth architecture. Other layers handle identity (Layer 1), network segmentation (Layer 2), idempotency (Layer 3), and observability (Layer 5). This layer ensures that even if all other controls fail, there is a hard financial ceiling on what an agent can execute autonomously.

The output is a policy JSON document plus Terraform HCL that creates the DynamoDB spend counters, CloudWatch alarms, and Step Functions approval workflow your agent needs at runtime.

1. Click one of the 6 agent type chips at the top: Payment Router, Fraud Detector, Settlement Agent, Refund Agent, Compliance Checker, or Webhook Processor. This pre-loads sensible default limits for that agent's typical transaction profile.
2. Enter an Agent Name — this appears in the generated output as a label to identify which agent instance this configuration belongs to.
3. Select a currency (GBP, USD, EUR, AUD, or CAD). All limit values in the generated output will be denominated in this currency. For multi-currency systems, generate a separate configuration per currency.

1. Per-transaction limit: the maximum value of a single payment the agent can execute. Any payment intent above this value is automatically rejected before execution. Set this to the highest single payment your agent legitimately needs to process.
2. Daily limit: the cumulative total the agent can spend in a 24-hour rolling window. Enforced via an atomic DynamoDB counter. When this is hit, all further payments are blocked until the window resets.
3. Monthly limit: the cumulative total for the calendar month. Useful for budget control — e.g. a reconciliation agent that should not process more than £500k in bulk payouts per month.
4. Hard cap: an absolute ceiling that cannot be overridden by any retry or approval mechanism. This is your final safety net. Set it conservatively — you can always raise it, but it is much harder to explain a breach to a regulator.

1. Cooldown period: minimum seconds between consecutive executions. Prevents runaway loops where an agent retries the same failed payment at full speed. For most payment agents, 30–60 seconds is appropriate.
2. Max retries: how many times the agent can attempt the same payment before giving up and escalating. Works in combination with cooldown — 3 retries at 30-second cooldown means 90 seconds maximum retry window before human escalation.
3. Freeze on breach: when enabled, hitting the hard cap sets a frozen flag on the agent's DynamoDB record. Your agent must check this flag before each execution. A frozen agent requires manual intervention to re-enable — it will not auto-unfreeze.
4. Alert on approach: enables a CloudWatch Alarm that fires when spend reaches a percentage of the daily limit (you set the threshold). Use this for early warning — e.g. alert at 80% so your team can investigate before the limit is hit.

1. Approval threshold: any single transaction above this value requires approval before execution. This is separate from the per-transaction limit — it is the value at which the approval workflow kicks in, not where payments are blocked.
2. Approval method: choose None (fully autonomous), Step Functions (programmatic waitForTaskToken pause), Human Review (SNS notification to a reviewer), or Dual Auth (two independent approvers required). The Terraform output changes significantly based on this choice.
3. Escalation channel: where approval requests are sent. Options are SNS (generic pub/sub), PagerDuty (incident-based), Slack (webhook), Email, or SQS Queue. For PCI DSS compliance, use SNS or PagerDuty — they provide an audit trail of notification delivery that you can show to a QSA.
4. The Escalation timeline panel (below the dropdowns) shows a readable prose description of the exact sequence of events when an approval is triggered. Review this to confirm the workflow matches your runbook.

1. Switch between Policy JSON and Terraform HCL tabs. The JSON is your runtime configuration document. The HCL creates the AWS infrastructure.
2. Store the policy JSON in SSM Parameter Store or a DynamoDB config table. Your agent reads it at startup and validates each transaction against it before execution.
3. For Terraform: place the .tf file in your infrastructure repo. Definevar.approval_lambda_arn pointing to your approval handler. Run terraform init && terraform apply — this creates the DynamoDB table, CloudWatch alarms, and Step Functions state machine.

A common configuration mistake is setting a daily limit that cannot be reached in practice because the per-transaction limit is already so low. For example: a £500 per-transaction limit with a £200 daily limit — every transaction would be blocked after the first one. The live summary helps you spot these misconfigurations before generating output.