# AI agent audit workpaper: trace one action from permission to outcome **Version:** 1.0 **Last updated:** 2026-10-19 **Source:** KLA Digital (kla.digital/blog/how-to-audit-ai-agent-system) **Spreadsheet version:** kla.digital/downloads/ai-agent-audit-workpaper.csv --- ## About this workpaper This is a completed workpaper for a **synthetic** audit of a credit-disposition agent at a fictional EU retail bank. Every bank, person, identifier, amount and finding in it is invented. Sample S-01 uses the public synthetic record `complete-execution.json` from the KLA [AI agent execution record](https://kla.digital/resources/ai-agent-execution-record) reference, so a reviewer can check each field against a published file. Samples S-02 and S-03 are invented cases written in the same audit-event v1 field names. They show an approval mismatch and a missing tool result. Field names follow the vendor-neutral [AI agent audit log schema](https://kla.digital/resources/ai-agent-audit-log-schema). Replace them with the names in your own records and keep the test logic. This document is for information only. It is not legal advice or an audit opinion. --- ## 1. Engagement | Item | Entry | | ------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Audit objective | Determine whether credit-disposition actions taken by the agent were authorized, governed by the policy in force, approved where policy required it, and recorded accurately in the system of record | | System | Credit review agent `agent_credit_review`, release `release-2026.07.21.3` | | Process | Credit disposition, `credit-review-process` version 12 | | Period | 2026-07-01 to 2026-09-30 | | Criteria | Bank lending policy LP-12; agent delegation standard DS-3; credit-disposition-policy 4.2.1; records standard RS-2 | | Accountable owner | Head of credit operations (`role_head_credit_operations`) | | Prepared by / reviewed by | Internal audit senior / audit manager (synthetic) | ## 2. Population and sample | Step | Result | | ---------------------------- | -------------------------------------------------------------------------------------------------------- | | Originating events | 1,286 application events in the loan system | | Agent runs with audit events | 1,284 | | Unmatched | 2 applications without a run (finding F-01) | | Population freeze | Query PQ-07, frozen 2026-10-03 | | Sample | 25 runs: 10 highest-amount, 5 policy `require_approval`, 3 `block`, 2 timeouts, 5 random (seed 20261003) | | Shown in this workpaper | S-01 (complete record), S-02 (approval mismatch), S-03 (missing result) | ## 3. Test areas Each sample is tested across the same seven areas: 1. **Scope:** the action belongs to the reconciled population. 2. **Delegated authority:** the agent acted for a named principal within its delegated scope and data boundary. 3. **Policy version:** the policy version in force evaluated the action before execution. 4. **Human decision:** a reviewer with the required role approved the action that executed, before it executed. 5. **Tool result:** each tool call has a recorded result or a recorded failure. 6. **Business outcome:** the recorded outcome agrees with the system of record. 7. **Evidence limits:** the record is intact, and the workpaper states what it cannot show. ## 4. Sample S-01: complete record (public synthetic example) Run `run_01JZ8V4K2D9A6N3P7M5R1C8X0E`. Action `credit.application.set_disposition`, EUR 24,000. | Test area | Expected result | Observed result | Evidence reference | Limitation | Finding | | ------------------- | ------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------ | ---------------------------------------------------------------------------------------------------- | ------- | | Delegated authority | Delegation active at request time; `boundary_eu_credit_restricted` in scope | Delegation DEL-1842 active; boundary in scope | `/audit_event/actors`, `/audit_event/requested_action` | Delegation register change history not tested | None | | Policy version | `credit-disposition-policy` 4.2.1 in force; `policy_digest` matches archive; evaluated before tool call | Digest matches; `evaluated_at` 09:14:29.188Z precedes tool call 09:14:31.944Z; `require_approval`, rule `manual-review-above-20000` | `/audit_event/policy` | Re-evaluation from recorded inputs shows the policy logic; it does not show the inputs were accurate | None | | Human decision | Reviewer holds `senior_underwriter`; decision before tool call and before expiry | `usr_underwriter_031` holds the role; decided 09:14:31.902Z; expiry 10:14:29.214Z | `/audit_event/approval` | Rationale read under authorized access from a tokenized reference | None | | Tool result | Arguments digest matches approved request; result recorded | Match; `succeeded` at 09:14:32.433Z; `result_digest` present; one call for the idempotency key | `/audit_event/tool_calls/0` | The result digest commits to the tool response; it does not prove what the downstream system stored | None | | Business outcome | Core banking shows the approved disposition | `effect_synthetic_91084` present; amount and after-state digest agree with extract CB-0721 | `/audit_event/tool_calls/0/downstream_effects` | Confirmed from the bank extract; the audit event alone does not prove the external effect | None | | Evidence limits | `record_hash` and Ed25519 signature valid; manifest resolves and verifies | Valid; `bundle_manifest_synthetic_20260721_01` verifies | `/integrity` | Integrity checks show the record is unchanged since signing; they do not show it is complete or true | None | ## 5. Sample S-02: approval mismatch (invented case) Run `syn_run_0207`. Policy 4.2.1 returned `require_approval` for EUR 24,000. | Time (UTC) | Event | | ---------- | ------------------------------------------------------------------------------- | | 10:02:11 | Policy returns `require_approval`; rule `manual-review-above-20000` | | 10:05:40 | Senior underwriter approves Decision Request `syn_apr_0207` for EUR 24,000 | | 10:05:52 | Agent re-reads the application; the requested amount is now EUR 42,000 | | 10:06:02 | Tool call executes `set_disposition` for EUR 42,000 under the original approval | | Test area | Expected result | Observed result | Finding | | ---------------- | ----------------------------------------------------------------------------- | -------------------------------------------------------------------- | ---------------------- | | Human decision | Approved request and executed call carry the same amount and arguments digest | Approved EUR 24,000; executed EUR 42,000; `arguments_digest` differs | **F-02 (high)** | | Tool result | Arguments match the approval | Mismatch; status `succeeded` | Linked to F-02 | | Business outcome | Core banking agrees with the approved amount | Core banking shows EUR 42,000 | Linked to F-02 | | Evidence limits | Record intact | Hash and signature valid; the record shows the mismatch | No integrity exception | **F-02 (high): approval did not cover the executed action.** A material input change after approval did not invalidate the approval or trigger a new Decision Request. The policy was not re-evaluated at EUR 42,000, so no record shows which outcome that amount would have received at execution time. Owner: head of credit operations. Action: bind approvals to the arguments digest and re-evaluate policy when a bound field changes; credit risk to review the EUR 42,000 disposition. Due: 2026-11-30. ## 6. Sample S-03: missing tool result (invented case) Run `syn_run_0311`. Policy 4.2.1 returned `allow` for EUR 8,500. | Test area | Expected result | Observed result | Finding | | ---------------- | ---------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | ---------------------- | | Policy version | `allow` under 4.2.1 | `allow` at 14:20:07Z; re-evaluation from recorded inputs returns `allow` | None | | Tool result | `succeeded` or `failed`, with `completed_at` and `result_digest` | Status `timeout`; no `completed_at`, `result_digest` or `downstream_effects`; no retry | **F-03 (medium)** | | Business outcome | Outcome supported by the tool result or by reconciliation | `business_outcome.status` is `achieved`, set from the agent's final message. Core banking shows the disposition applied at 14:20:31Z | Linked to F-03 | | Evidence limits | Record intact; replay matches | Hash and signature valid; policy replay returns `allow` | No integrity exception | **F-03 (medium): a timed-out tool call was closed without reconciliation.** The governed record does not support the recorded outcome. The auditor confirmed the outcome only through an alternative procedure: a core-banking query by idempotency key. Owner: platform owner. Action: mark runs with an unresolved tool result as `outcome_unknown` and reconcile them against the system of record before closing. Due: 2026-12-15. ## 7. Evidence limits for the engagement - A valid hash and signature show that a record has not changed since it was signed. They do not show that the record is complete or that its contents are true. - A replayed policy decision shows what the recorded policy version returns for the recorded inputs. It does not prove that an external system applied, rejected or later reversed the action. - Proof of a business outcome comes from the system of record, through a downstream receipt, a state digest or a reconciliation extract. - Population completeness comes from reconciliation with originating systems. A single complete record does not prove a complete population. ## 8. Findings summary | ID | Severity | Finding | Owner | Due | | ---- | -------- | --------------------------------------------------------------------------------------------- | ------------------------- | ---------- | | F-01 | Low | 2 applications without a run; both withdrawn before routing, closure evidence obtained | Credit operations | Closed | | F-02 | High | Approval did not cover the executed action after a material input change | Head of credit operations | 2026-11-30 | | F-03 | Medium | Timed-out tool call closed without reconciliation; outcome unsupported by the governed record | Platform owner | 2026-12-15 | ## 9. Conclusion (synthetic) For the sampled population, delegated authority, policy version control and record integrity operated as designed. Approval binding (F-02) and outcome reconciliation (F-03) did not. The conclusion on the accuracy of recorded business outcomes is qualified for runs with a timed-out or missing tool result until those runs are reconciled.