Why Your AP Automation Needs a Kill Switch (And How to Build One)

Category: Financial Services | Reading time: 5 min

---

The Runaway Agent Problem

In early 2024, a software company deployed an AI agent to handle invoice processing. The agent worked well — until a database issue caused vendor statuses to return null instead of "approved" or "blocked." The agent, trained to process invoices efficiently, interpreted null as non-blocking and continued processing. In four hours, it queued $1.4 million in payments to vendors that should have been held.

No malice. No hack. Just an AI doing exactly what it was designed to do — process payments — without any mechanism to detect that the world had changed.

Every AP automation deployment needs a kill switch. Not a "pause button" buried in a settings menu — a hard, deterministic, kernel-level halt that fires automatically when conditions aren't safe to proceed.

---

What "Kill Switch" Actually Means

A real kill switch for AI payment workflows has three properties:

1. It fires before the irreversible action The kill switch needs to stop the agent before the wire goes out, before the ERP is updated, before the ledger is committed. Not after.

2. It's policy-driven, not code-driven If the kill switch is implemented in application code, it can have bugs. If it's a database flag, it can be bypassed. The only reliable kill switch is one evaluated by a separate, purpose-built policy engine that runs outside the agent's own code path.

3. It rolls back what's already happened Stopping a workflow halfway through can leave partial state — an invoice marked "processing" with no corresponding payment, an ERP entry without a bank confirmation. A real kill switch also triggers compensation to clean up the mess.

---

Taos: Kill Switch as First-Class Kernel Feature

The Taos governance kernel implements all three properties via its combination of Rego policy evaluation, denial_mode, and saga compensation.

Before any payment step executes, the kernel evaluates the vendor payment policy:

# If vendor_status is anything other than "approved" — stop
deny_non_approved_vendor {
    input.vendor_status != "approved"
    input.vendor_status != "pending"  # pending goes to approval gate, not deny
}

allow {
    not deny_blocked_vendor
    not deny_non_approved_vendor
    input.is_ofac_cleared == true
}

action = "deny" { not allow }

If the policy returns deny, the kernel stamps denial_mode = "hard" on the PolicyDenied message. The ADK or Genkit plugin receives this and raises a PolicyDeniedError immediately — before returning anything to the LLM. The step that would have executed — submitPayment — never runs.

This hard mode is the technical definition of the kill switch. A soft denial would instead pass a structured message to the LLM, which could reformulate it and continue. That is explicitly not what a kill switch does. Every step definition governing a payment action carries denial_mode = "hard" in the Taos manifest — this is not a default you hope is set; it is a declaration in the step registry, auditable and version-controlled.

---

Saga Compensation: Undoing What's Already Done

In a multi-step workflow, "stop" isn't enough. Consider this sequence:

1. ✅ extractInvoice — invoice data fetched and validated
2. ✅ evaluatePolicy — policy passed (vendor was approved at check time)
3. ✅ submitPayment — payment record created in DB
4. ❌ updateERP — ERP system returns an error

Without compensation, you now have a payment record in the DB with no corresponding ERP entry — a data integrity problem that could result in double payment or a missing ledger entry.

With Taos saga compensation, every completed step registers a rollback function. When step 4 fails, the kernel runs compensation in LIFO order (Last In, First Out):

Step	Compensation action
submitPayment	Mark payment as voided, write audit event
evaluatePolicy	Log compensation (no DB state to reverse)
extractInvoice	Mark invoice as pending (reset to pre-processing state)

The result: clean state, full audit trail of what happened and why, no orphaned records.

---

Building the Kill Switch: Three Configuration Points

Setting up the Taos kill switch for your AP workflow requires three things:

1. Policy rules that cover your failure modes

Think about every condition under which you don't want a payment to proceed:

• Vendor blocked or OFAC-flagged
• Invoice amount exceeds submitter's authority
• Vendor is new (pending approval)
• ERP connection unavailable
• Duplicate invoice detected

Each of these becomes a Rego rule. No code deployment — just a policy update.

2. Compensation functions on every step

Every step that creates state registers a rollback:

taos.register_compensation(
    "submitPayment",
    lambda: db.void_payment(payment_id)
)

If any later step fails, this function fires automatically.

3. A monitoring hook on PolicyDeniedError

When the kill switch fires, you want to know immediately:

except PolicyDeniedError as e:
    await alert_channel.send(
        f"Payment blocked: {e.reason} [rule={e.rule_fired}]"
    )
    # The compensation has already run — state is clean

---

The Scenario That Started This Post

Back to the company with the null vendor status issue. With Taos:

1. The Rego policy receives input.vendor_status = null
2. null != "approved" — the deny_non_approved_vendor rule fires
3. PolicyDeniedError raised — submitPayment never executes
4. Saga compensation resets invoice status to pending
5. Alert fires: "Payment blocked — vendor status null for invoice #INV-4421"
6. Operations team investigates the database issue

Total payments incorrectly processed: zero. Time to detect: milliseconds.

---

The Bottom Line

AP automation without a kill switch is a liability, not an asset. The question is not whether something will go wrong — it will. The question is whether your system stops cleanly or cascades into a financial mess.

Build the kill switch into the kernel, not the application. Make it policy-driven, not code-driven. And make sure it rolls back cleanly when it fires.

---

Tags: AP automation, AI kill switch, saga compensation, payment governance, Rego policy, financial AI safety