For auditors

The 5-minute auditor one-pager.

For external and internal auditors evaluating finance teams running closegate. Control mapping, evidence collection, and the five non-negotiables that should be present in every deployment.

closegate is an open-source policy chokepoint for finance AI agents. It sits between the LLM and the general ledger, enforcing segregation of duties, materiality thresholds, sensitive-account routing, and tamper-evident audit logging. For an auditor, the relevant question isn't "does the AI work" — it's "are the controls demonstrably effective." This page walks the controls.

The five non-negotiable controls

Every deployment of closegate has these by default. If any are missing, the deployment is misconfigured:

  1. Per-agent identity bound to the transport. Every MCP call carries an X-Actor-Id header of the form human:<id>, llm:<session-id>, or engine:<process>. The actor is set by the gateway, not by the tool caller. An LLM session cannot impersonate a human.
  2. Segregation of Duties (SoD) enforced server-side. The gate denies action=CONFIRM when proposed_by == actor.id, with a verbatim policy clause and a JSON-pointer to the rule. Same actor cannot propose and confirm regardless of prompt or chat history.
  3. Materiality routing with per-entity overrides. materiality_threshold_usd + entity_materiality_overrides (e.g. US parent $10K, JP sub ¥1M, IN sub ₹500K). Above threshold → forced HITL routing.
  4. Sensitive-account flagging. always_human_accounts (cash, legal accruals, intercompany clearing, vendor bank-change events) forces HITL regardless of materiality.
  5. Tamper-evident audit log. SQLite BEFORE UPDATE and BEFORE DELETE triggers refuse mutation at the database layer. Hash-chained for replay-detection. closegate-engine audit verify exits non-zero on any inconsistency.

The control-testing script (60 minutes)

For an external auditor doing an operating-effectiveness walkthrough:

  1. 0:00–0:05 — Confirm the deployment environment (CLOSEGATE_ENV=prod) and authentication backend (CLOSEGATE_AUTH_BACKEND). Both should be set; dev mode falls through unauthenticated requests as a demo actor.
  2. 0:05–0:20 — Read policy.yaml. Confirm materiality threshold, sensitive accounts, and per-entity overrides match what the controller represented to management. Note the policy_version at the head of the file.
  3. 0:20–0:35 — Pull a sample of 20 audit events from the period under test. closegate-engine audit tail --since 2026-04-01 --limit 20. For each event, confirm the verbatim policy clause text matches the rule in policy.yaml at the time of the decision (cross-reference with git blame).
  4. 0:35–0:45 — Probe the SoD enforcement. Ask: "give me an event where an LLM proposed and a human confirmed." Confirm proposed_by starts with llm: and confirmed_by starts with human:. Then ask for a denied event with reason SOD_SAME_ACTOR.
  5. 0:45–0:55 — Probe the materiality routing. Ask for a forced-HITL event above threshold. Confirm the routing happened automatically (no manual escalation), and that the HITL approval landed with a different actor identity.
  6. 0:55–1:00 — Run closegate-engine audit verify against the period. Confirm the hash chain is intact.

Evidence collection

For a SOC 2 Type 2 or SOX walkthrough, the standard PBC bundle is produced by:

closegate-engine audit-evidence-export \ --since 2026-01-01 --until 2026-03-31 \ --out evidence-2026-Q1.zip

The bundle contains seven files:

  1. audit-sample.csv — 25 random + 25 boundary events (above-materiality + sensitive-account)
  2. actors.json — full actor identity registry with first-seen and last-seen timestamps
  3. dead-letters.json — outbox dead-letter queue for the period (should be empty in a healthy deployment)
  4. policy-versions.json — every policy.yaml commit hash + timestamp + author
  5. eval-runs.json — every nightly SOC 2 monitor run with pass/fail status per dimension
  6. sweeper-runs.json — every recovery-sweeper invocation + locks released
  7. README.md — auditor-facing index with the control mapping

Framework mappings

The full control mapping document (COMPLIANCE.md) cites file.py:line. Cliff notes:

FrameworkControls addressed
SOC 2 Trust Services CriteriaCC6.1 (logical access), CC6.2 (authorization), CC6.3 (revocation), CC4.1 (monitoring), CC7.2 (detection), CC7.3 (response)
NIST AI RMF Agentic Profile (CSA 2026)Reversibility tier, per-agent identity, HITL on irreversible, tamper-evident logging, model card binding, schema fingerprint on ingestion
PCAOB AS 1215Audit documentation, retention, reconstruction (every decision replay-able from log + policy.yaml git history)
SOX 404 ICFRSoD, materiality, sensitive-account routing, period-close lock, evidence retention
EU GDPR Article 22Automated decision-making with legal effect, right to explanation (verbatim policy clause text on every event), data minimization
State sales-tax roundingPer-line vs invoice-total rounding configurable in policy_policy.money; ROUND_HALF_UP adapter for IRS reports

Detailed mapping with control-by-control implementation citations lives in COMPLIANCE.md in the repository. Recommended reading order: this page → COMPLIANCE.md § SOC 2 → security threat model.

Common pre-pilot questions

Auditors and SOX leads who've reviewed closegate deployments most often ask the same six questions; we cover them in the FAQ below. If you have a seventh, DM the maintainer — we'll add it.

Inbound

Talk to the maintainer

Two design-partner slots open this quarter. One real workflow, your real policy.yaml, monthly 30-min call, direct line. Apache-2.0, self-hosted, no seat licensing — forever.