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-5-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.

✓ Check yourself

Answer from memory before opening each one.

1. On Friday evening the Process Owner loses confidence in an agent's output and wants it stopped, but engineering is offline. What design feature should make that possible, and why does it matter?

   Show answer

   A kill switch the Process Owner can use on their own, with no engineering involvement. Accountability without the power to stop the thing is a control gap an auditor will find. The same contract also gives the owner approval of the tier, the design document and the eval baseline. See the Process Owner contract.

2. A new workflow would send vendor payment history, including legal names and the contact's national ID, to a model. How do you decide what may go?

   Show answer

   Classify at the field level, not the record level. Strip Restricted fields such as national IDs with an automatic redactor before any model call, and send Confidential fields such as legal names only to approved providers under restricted prompts. Restricted data in a workflow also needs the Process Owner's explicit sign-off. See data classification.

3. An auditor asks for every proposed journal entry in March that the Controller rejected. What properties of the audit log make that one query, and why would application logs not do?

   Show answer

   Each action is a structured row with run, agent class, decision, approver, entity and period, stored append-only and indexed on those fields. Free-text application logs cannot be filtered reliably and can be altered or lost. Add a hash chain if you need tamper evidence. See the audit log.

4. A Process Owner approves about 1,000 items a day, almost all of them, in a few seconds each. Is this a working control? What do you measure?

   Show answer

   Probably not. A gate that is always passed without reading is fictional, and an auditor will say so. Track the override rate and the effective review time per approver, and raise the gate, for example with a second approver or a smaller batch, when either falls below a sane level. See HITL checkpoints.

5. A teammate adds a commit_journal_entry tool so the agent can skip the staging step. What has to happen before it ships?

   Show answer

   A new write tool or wider scope is a full design-document amendment, re-signed by the Process Owner, the SOX lead and engineering. It also very likely changes the risk tier, which brings the artifacts of the higher tier. A convenience argument does not shortcut that. See change management.

6. Case one: the override rate on an agent is rising, but its output is still useful. Case two: a hallucination reached production and the cause is unknown. Which do you halt and which do you redesign?

   Show answer

   Halt case two now, then find the cause, because it is active exposure with an unexplained mechanism. Redesign case one with a stronger gate or tighter scope, since the approach is sound and the harm is bounded. The split is whether harm is possible while you investigate. See halt versus redesign.

Takeaway

• Design as if every agent action is in SOX scope: section 302 is the quarterly certification and section 404 is the annual control assessment.
• Name the risk tier in the first minute of any design. Each tier adds required artifacts, and the autonomous tier is off by default.
• The Process Owner owns the outcome, approves the tier, design document and eval baseline, holds the kill switch and reviews quarterly.
• Classify data by field, and redact Restricted fields before any model call.
• The audit log has one append-only row per action, with model, prompt and tool catalog identifiers, approver and idempotency key, retained for seven years and queryable by run, entity and period.
• A human gate counts only if humans read what they approve, so measure override rate and review time, and let timeouts reject, not approve.
• Changes to prompts, models, tools, MCP servers and eval sets are controlled releases, and a better model is never a reason in itself.

Governance sets the rules the code must live under, so the next chapter covers the Python that implements them. → Coding Fundamentals

Further reading

• Sarbanes-Oxley Act of 2002 — US Congress, 2002. The text of sections 302 and 404.
• Management's Report on Internal Control Over Financial Reporting — SEC, 2003. The rule that defines management's assessment and ICFR.
• Internal Control, Integrated Framework — COSO, 2013. The framework most ICFR programs cite.
• AS 2201: An Audit of Internal Control Over Financial Reporting — PCAOB. Walkthroughs, testing and deficiency classification from the auditor's side.
• AS 1215: Audit Documentation — PCAOB. Documentation and retention expectations behind the seven-year figure.
• AI Risk Management Framework — NIST. A shared vocabulary for AI governance across domains.
• SR 11-7: Guidance on Model Risk Management — Federal Reserve, 2011. Model inventory, validation and change expectations.