Every state-changing action your AI agent takes lives in exactly one of four tiers. The tier determines the routing; the routing determines the audit posture; the audit posture determines whether your audit committee signs off. This article walks the model in detail, with concrete finance examples for each tier.

The model at a glance

T0 Read or propose — no state change T1 Reversible, below materiality, with audit T2 Reversible above materiality OR sensitive account — HITL T3 Irreversible — dual HITL with full SoD chain

The tier is assigned at MCP tool registration time with a decorator:

@register_tool(tier=Tier.T2, name="confirm_match")
def confirm_match(match_id: str, ...): ...

The decorator fails if the tier isn’t specified. The runtime checks the tier on every invocation. There’s no path to ship a tool that bypasses the tier model.

T0 Read-only · auto — the agent’s full-speed lane

The rule: doesn’t change state. Doesn’t propose state change either — pure read or pure pre-decision computation.

Examples (closegate):

  • query_audit — read the audit log
  • recon://status — read the KPI snapshot
  • recon://exceptions — read the open-exception list
  • investigate_exception — load entry + curated near-misses
  • generate_close_summary — synthesize a read-only summary

Routing: always automatic. No HITL check. No SoD check. The LLM runs full speed.

Why it matters: T0 is most of what a well-designed agent does. The LLM reads state, reasons, and decides what to propose. If your agent is spending most of its time on T1+ tools, the workflow is wrong.

T1 Reversible · auto + audit — reversible with audit evidence

The rule: changes state, but the change is reversible by anyone with the right actor identity, and the amount is below the materiality threshold.

Examples:

  • reject_match — reject a proposed match; entries go back to UNMATCHED
  • flag_exception — mark an entry as EXCEPTION with rationale
  • escalate_match — surface a match to a named approver
  • ap_confirm_invoice_coding — RECEIVED → CODED transition (still reversible until APPROVED)

Routing: automatic. But every action writes an audit row with verbatim policy clause text + JSON-pointer source.

Why it matters: T1 is where most low-risk automation lives. The temptation is to skip audit logging for T1 because the actions are reversible. Resist. The audit log isn’t preventing malice (you’re trusting reversibility for that); it’s giving the external auditor a reproducible trace for sampling.

T2 HITL required — the audit-committee threshold

The rule: changes state. Reversible in theory, but either (a) above the materiality threshold, OR (b) touches a sensitive account, OR (c) match type is in the no-auto-confirm list.

Examples:

  • confirm_match — confirm a GL/SL match (SoD + materiality + sensitive-account + match-type checks fire)
  • ap_approve_invoice_for_payment — invoice approval (SoD: actor ≠ PO requestor; HITL)
  • ap_propose_payment_run — group APPROVED invoices into a draft run
  • ap_approve_payment_run — approve the payment run (SoD: approver ≠ requestor)

Routing: HITL required. The LLM proposes; a different human actor confirms. SoD enforced server-side.

Why it matters: T2 is where your audit committee actually pays attention. The first question on a SOX walkthrough: “show me an above-materiality match that was confirmed by a human, not the LLM.” The answer should be one query against the audit log; the result should show the verbatim clause text + the human actor’s OIDC-bound identity.

T3 Dual HITL · irreversible — the bank-transfer threshold

The rule: irreversible. Once it happens, you can’t take it back without a multi-step external process (wire reversal, fraud claim, period reopen).

Examples:

  • ap_submit_payment_run — payment hits the bank/ACH
  • close_period — close the accounting period (post-close edits are restricted)
  • post_to_closed_period — post a journal entry to a previously-closed period (extremely rare; high audit scrutiny)

Routing: DUAL HITL. Three distinct actor identities. requestor ≠ approver ≠ payer. No prompt can override; no LLM can claim to be a human; no engine can play any of the three roles.

Why it matters: T3 is the AP-fraud-prevention pattern. Same human can’t both approve a payment to a vendor and release it to the bank. The audit committee’s most-cited control is exactly this; closegate enforces it server-side.

If the same actor tries to play all three roles, the gate denies with SOD_SAME_ACTOR and writes a POLICY_VIOLATION audit event.

Edge cases

”It’s reversible, but only with audit-committee approval”

E.g., period close. Technically reversible until books lock, but the reversal requires an audit-committee resolution. closegate’s convention: classify as T3. The model isn’t about pure technical reversibility; it’s about the operational cost of undoing.

”It’s irreversible, but the amount is tiny”

E.g., a $10 stamp purchase processed via expense automation. Technically T3 (money moves), but the cost of dual-HITL on every $10 transaction is silly. closegate’s convention: bundle small transactions into a periodic batch (e.g., daily expense run) and treat the batch as T3. Individual transactions inside the batch are T1.

”It’s reversible above materiality, but the agent’s confidence is very high”

E.g., the matcher returns macro-F1 = 0.99 on this match. closegate’s convention: confidence doesn’t change the tier. The tier is about consequence, not confidence. Always route T2 to HITL.

”We’re a 2-person startup; HITL = ‘myself again 5 minutes later’”

closegate’s convention: SoD still requires different actor identities, but the time-of-day or session-context can vary. Practically, this means the same person logs in once as human:alice@startup.com (proposer) and once via a different session as human:alice@startup.com (confirmer) — and the gate denies same-actor proposal-and-confirm regardless.

The honest answer for 2-person startups: SoD doesn’t work the same way it does in larger teams. Many startup teams accept this risk; some delegate the confirmer role to a board member or fractional CFO. closegate enforces the rule; the org chart fills in the second actor.

What this gives you

  • A canonical 4-tier vocabulary your auditor, engineer, controller, and CFO share
  • Executable routing: tier annotation → runtime check → audit evidence
  • Defense against the LLM-impersonates-human attack at every tier
  • Dual-HITL on irreversible actions, enforced at the database boundary