How agents draft audit findings without taking over the GRC system
An internal-audit agent does not own the issue. It reads testing evidence, drafts a finding, names the control that failed, and waits for an audit-team approval before anything is posted to the GRC system. AuditBoard and ServiceNow GRC stay the system of record for the issue itself. Dock holds the interpretation, the reviewer, and the timestamp. Findings only move from draft to published after a human approves them inside Dock.
The architecture
AuditBoard and ServiceNow GRC stay the system of record for the raw audit data: the issue records, the control library, the testing populations, the workpapers. Dock is the system of record for what the agent interprets from that data. Each Dock row carries a pointer back to the platform record (auditboard_issue_id or servicenow_grc_finding_id), the agent identity that drafted the finding, the auditor who approved or rejected it, and the timestamp on every state change. The agent re-fetches platform data via fresh API reads when it needs current state, so a stale draft cannot be published against a control that the second-line team already updated.
This is the same split described in the Dock-for-compliance pillar and the agent audit and compliance overview: the agent edits Dock, not the platform.
The Dock surface: an Audit Findings table
| finding_id | auditboard_issue_id | control | agent_draft_summary | proposed_rating | drafted_by | reviewer | status |
|---|---|---|---|---|---|---|---|
| F-2026-0411 | AB-ISS-88231 | ITGC-04 user access reviews | 3 of 42 sampled terminations retained SaaS access more than 7 days past offboard date | Significant deficiency | agent:audit-drafter-v3 | jamie.k | Approved, posted to AuditBoard |
| F-2026-0418 | AB-ISS-88247 | FIN-CTL-12 segregation of duties | Two AP clerks held both invoice-entry and payment-release roles in NetSuite during Q1 | Material weakness candidate | agent:audit-drafter-v3 | priya.s | In review |
| F-2026-0422 | SNGRC-F-44102 | SOX-302 quarterly attestation | Three regional controllers signed Q1 attestations after the sub-cert deadline | Observation only | agent:audit-drafter-v3 | dana.w | Rejected, agent revising scope |
The columns matter. drafted_by is the agent identity that produced the draft. reviewer is the human who owns the call. status only flips to "posted" after a two-key handshake confirms the auditor pressed approve.
A worked workflow
The agent pulls a testing population from AuditBoard for control ITGC-04. It samples terminations, re-fetches access logs from Okta and the named SaaS apps, and identifies three accounts that kept access past the seven-day cutoff. It writes a draft finding into the Dock row above, citing the evidence and proposing a rating. The auditor opens the row, reads the draft, rejects the rating because two of the three accounts were dormant test fixtures, and approves a revised draft. Only after that approval does the agent call the AuditBoard API to post the finding under the auditor's name, with the Dock row id stamped in the issue description for back-reference.
The post is a dangerous operation. It is bounded, named, and gated. The agent cannot fire it without the recorded approval.
Why this matters
Internal audit lives on documentation discipline. The IIA's 2024 Global Internal Audit Standards place engagement documentation inside Domain V, where Principle 13 requires sufficient and reliable information to support conclusions (theiia.org). An agent that drafts findings without a reviewer record breaks that principle. An agent that drafts inside Dock, with reviewer and timestamp captured per row, satisfies it.
COSO's Internal Control Integrated Framework is built on five components, with information and communication and monitoring activities depending on traceable records (coso.org). The agent identity column is how that traceability survives once agents start touching control work.
The same approval discipline shows up in Dock for accounting, where AP and close workflows also depend on an agent identity the auditor can name.
Try it
Spin up an Audit Findings table in Dock, point your agent at one AuditBoard control, and require approval before any post. Start with one control. Watch the reviewer column fill.
FAQ
Does the agent ever edit the AuditBoard issue directly? Only after a recorded human approval inside Dock. The draft lives in Dock; the post to AuditBoard is the gated step.
What if AuditBoard already has its own AI features? Those features act on the platform record. Dock holds the cross-agent interpretation layer, the reviewer, and the identity trail, which is what auditors are asked to produce during external review.
Can ServiceNow GRC replace AuditBoard in this pattern?
Yes. The pointer column becomes servicenow_grc_finding_id. The architecture is unchanged because Dock is not coupled to either vendor.
How do we keep the agent from posting stale findings? The agent re-fetches platform state before any post, and the approval token expires if the underlying issue changes. The contract is described in the irreversibility post linked above.
