Governance & Audit

SOX in one page

Sarbanes-Oxley (2002) requires public-company management to attest that internal controls over financial reporting (ICFR) are effective. The two clauses you should know:

• Section 302: CEO/CFO certify the accuracy of financial statements and the effectiveness of controls each quarter.
• Section 404: Management documents and tests ICFR annually; external auditor opines.

Auxiliary vocabulary:

• ICFR — Internal Controls over Financial Reporting. The set of policies, procedures, and automated checks that ensure financial statements are not materially misstated.
• Key control — a control that, if it failed, could lead to material misstatement.
• COSO framework — the conceptual framework most companies use for ICFR.
• Walkthrough — an auditor traces a transaction through the system, asking about each control along the way.
• Deficiency / significant deficiency / material weakness — escalating categories of control failure. Material weakness is bad — disclosed to investors.
• Segregation of duties (SoD) — same person cannot create and approve.
• PCAOB — Public Company Accounting Oversight Board, regulates the external auditors.

You don't need to be a SOX expert. You need to sound aware, and you need to design as if every agent action is in scope.

The risk-tier framework

Reprinting from chapter 01 for muscle memory — and adding the governance artifacts each tier requires.

The Process Owner contract

The JD names this concept explicitly: "No build goes to production without a named Process Owner." Define what they sign up for:

• Owns the business outcome: same accountability as for a human performing the task.
• Approves the risk tier: signs off on classification.
• Approves the design doc: data flows, controls preserved or redesigned, HITL gates.
• Approves the eval baseline: what "good enough to ship" means quantitatively.
• Holds the kill switch: can halt the agent at any time without engineering involvement.
• Reviews quarterly: signs off on continued operation based on eval drift + override rate.

This formalizes the "humans gate the risky bits" principle in a way auditors can walk through.

Data classification

Before any data flows to an LLM, classify it. A typical scheme:

The cleanest design: classify the fields, not just the records. account_balance is Internal; vendor_legal_name is Confidential; employee_ssn is Restricted. Build an automatic redactor that strips Restricted fields before LLM calls.

Audit log schema

Every agent action gets a row. Minimal schema:

{
    "run_id": "01HXR2K8...",          # ULID
    "parent_run_id": null,             # for sub-agents / planner-worker
    "agent_class": "bank_recon_v3",
    "agent_version": "3.7.2",
    "model_id": "claude-sonnet-4-5",
    "model_version_pin": "2025-09-29",
    "prompt_hash": "sha256:a1b2...",
    "tool_catalog_hash": "sha256:c3d4...",
    "step_id": "S4",
    "step_type": "tool_call",
    "tool_name": "propose_reconciling_item",
    "inputs_hash": "sha256:...",
    "inputs_redacted": {"...": "..."},   # data-classification aware
    "outputs": {"...": "..."},
    "decision": "proposed",              # proposed | approved | rejected | escalated | halted
    "approver_user_id": "u_42",
    "approver_role": "Controller",
    "approval_ts": "2026-05-10T18:14:22Z",
    "latency_ms": 1240,
    "tokens_in": 12044,
    "tokens_out": 318,
    "cost_usd": "0.0432",
    "process_owner_id": "u_17",
    "risk_tier": 2,
    "entity_id": "KRK-US",
    "period": "2026-04",
    "idempotency_key": "sha256:...",
    "result": "ok",
    "error": null,
}

Storage:

• Append-only. Use a write-once store or a database with row-level immutability.
• Retention: 7 years for SOX-relevant records (longer in some jurisdictions).
• Queryability: indexed by run_id, agent_class, entity, period, approver. Auditors will ask "show me every proposed JE in March that was rejected" — must be one query.
• Tamper-evidence: optional hash chain across rows for tamper detection.

HITL checkpoints — what counts

"Human in the loop" can mean many things. Define yours precisely:

An anti-pattern to call out: "the human always clicks approve." If a Process Owner is approving 1,000 items a day without reading, the HITL is fictional. Track override rate and effective-review-time per approver; if either drops below sanity thresholds, raise the gate.

Audit-ready design documentation

Every production agent gets a design doc. The shape that survives a SOX walkthrough:

1. Purpose — one-paragraph business outcome.
2. Process Owner — named role; named individual.
3. Risk tier — 1/2/3 with justification.
4. Inputs & data classification — every field, its source, its class.
5. Tool catalog — every tool, its read/write nature, its MCP server.
6. Workflow diagram — step-by-step including HITL gates.
7. Controls preserved / redesigned — which manual controls disappear; which are replaced by automated checks; which remain unchanged.
8. Failure modes — table of failures and mitigations (chapter 08).
9. Eval baseline & thresholds — metrics that gate change.
10. Change management — who approves changes; how regression runs gate them.
11. Audit log fields — exact schema.
12. Rollback plan — how to undo or reverse.
13. Approval signatures — Process Owner, SOX Lead, Engineering Lead.

Keep it living. Each release amends and re-signs.

Change management for agents

This is the topic that separates candidates with regulated-environment experience from those without. Every change to a production agent is a controlled release:

• Prompt change → regression suite must pass thresholds; release notes attached; Process Owner approves.
• Model version change → same regression suite + an Opus comparator + Process Owner approves; SOX walkthrough updated if material.
• Tool catalog change → if new write tools or expanded scopes, full design-doc amendment.
• MCP server change → integration regression; backwards compat or coordinated release.
• Eval set change → versioned; previous version archived; rationale documented.

"We rolled out the new Sonnet because it's better" is not an acceptable answer to an auditor. "We promoted Sonnet 2026-X after running the regression suite on the v5 golden set, with all critical metrics at or above baseline, approved by [Controller] on [date]" is.

Halt vs. redesign

The JD explicitly mentions the responsibility to halt or redesign builds that pose regulatory risk. Have a posture on this.

A senior architect halts without ego when the situation demands it. Have one story where you halted something. Even if it's a prototype, the story shape — "I noticed X, escalated, we paused, here's what we changed" — is the same.

The Automate Everything Center of Excellence

The JD calls out: "Serve as the Finance domain representative in the company's Automate Everything Center of Excellence, contributing to governance standards and cross-functional build alignment."

What this likely means in practice:

• Cross-functional body (Legal, HR, Compliance, Finance, Eng) that sets standards for automated builds.
• Shared catalog of MCP servers, tool patterns, audit log schemas.
• Risk-tier framework applied across domains.
• Pre-build review for any Tier 2+ build, across domains.
• You bring Finance-specific concerns (SOX, ICFR, SoD) into a shared playbook.

In your interview, if asked how you'd contribute to the CoE, the answer is: "I'd bring the SOX-flavored risk tiering and audit-log schema we use in Finance and propose making them the default across domains, with domain-specific extensions." That signals you think of yourself as a platform contributor, not just a builder.