AI / Financial controls / Leadership

Human in the loop: Validating MCP-generated key reports for SOX

By John Biersmith · October 27, 2026 · 7 min read

How to assess reliance, design an independent tie-out, and retain evidence when an MCP-enabled reporting path sits outside SOX scope.

When an AI assistant produces a polished report, the next question is often who needs to approve it. For a SOX professional, I think the more useful question is what that approval establishes.

A human can read an output, recognize the terminology, and approve a conclusion while missing an incomplete population or an incorrect calculation. Human involvement becomes a meaningful control when the review is designed to detect errors relevant to the financial-reporting risk.

My starting point for an MCP-generated key report is straightforward: where the connector and reporting path are outside the controls being relied upon, management needs an independent basis for validating the information used. Tying the relevant output back to reliable evidence from an in-scope SOX system is a practical way to build that basis.

Define the reporting path and the reliance

Model Context Protocol (MCP) enables an AI application to use tools exposed by a server, such as database queries or API calls. The protocol does not make every output an AI-generated calculation. A connector might retrieve an existing report unchanged, execute a parameterized query, or supply data that a model subsequently summarizes.^[1]

Those are different reporting paths with different failure points. I would document the source system, connector or server, retrieval logic, transformations, model involvement, and final report before deciding what the control must validate.

Then define the reliance. Is the output helping a reviewer navigate information, supplying the population for a control, calculating a balance, or determining which exceptions receive attention? A narrative can influence a financial-reporting decision even when no number is copied into a journal entry.

The assessment should name what “outside scope” means. Perhaps the source application is in scope but the connector’s extraction and transformation controls are not. Perhaps the tool retrieves data from an application outside the current scope. An in-scope source does not automatically establish the reliability of a new downstream report.

Assess the ways the output could fail

I would evaluate the report against its intended use and the errors the control needs to detect. This is the practical assessment I would put in front of finance, technology, and the control owner:

Swipe horizontally to compare all columns.

Read-only access can reduce the risk of changing source records. It does not establish that the resulting report is complete or accurate. If write access is possible, validating the report alone will not address the risk of an unauthorized source-system change.

Make the tie-out independent

The reviewer needs a dependable comparison. Asking the same assistant to confirm its own result through the same unvalidated connector can reproduce the same error twice. Agreement between those outputs adds little comfort about a shared failure.

A stronger approach is for management to obtain the relevant source evidence through an independently established reporting path—for example, a controlled native-system report or a separately validated extraction. The control should establish that the comparison report itself is appropriate and reliable for the purpose, including its parameters and any subsequent processing.

“It came from an in-scope system” is a starting point for that assessment, not a substitute for it. The reviewer still needs to know which report or query was used, what it includes, and how its completeness and accuracy are supported.

This fits established evidence principles. SEC guidance takes a risk-based approach to management’s assessment and supporting evidence. For external auditors, PCAOB AS 1105.10 addresses the accuracy, completeness, precision, and detail of company-produced information used as audit evidence.^[2][3] These sources provide a foundation for the reasoning; they do not prescribe an MCP-specific tie-out for every use case.

Match the validation to the decision

Consider a hypothetical monthly billing-exception report. An MCP-enabled assistant retrieves transactions, identifies exceptions, and writes a summary that management uses to decide whether further investigation is needed. The reporting path is outside the controls currently relied upon for SOX.

I would expect the validation to address the population and the exception determination. Management could compare the retrieved population with an independently obtained source-system report, investigate differences, and independently apply or validate the relevant exception rules. The reviewer would then trace significant narrative conclusions to the underlying records.

A matching grand total may be useful, but errors can offset. A record can also be assigned to the wrong entity or excluded from an exception list without changing the overall balance. If the control depends on exception identification, the review must be capable of detecting missed exceptions—not just confirming that the listed exceptions exist.

A summary introduces another layer. “No significant exceptions were identified” is a conclusion requiring support. Checking that a quoted revenue total agrees does not validate that conclusion or a proposed explanation for a variance.

The necessary granularity, thresholds, and extent of checking depend on the financial-reporting risk and control design. A small sample is not automatically sufficient for the whole report. The assessment should explain what each procedure establishes and what uncertainty remains.

Define a review that can challenge the output

The reviewer should have the competence, source access, time, and authority to challenge the report. A human-in-the-loop design needs more than an approval box. I would specify:

• The report’s purpose, population, period, and financial-reporting use.
• The independent comparison evidence and how its reliability is established.
• The required checks, level of detail, and basis for investigation criteria.
• How differences and unsupported statements are resolved before reliance.
• Who can reject the output, require rework, or escalate a recurring issue.

If that review is the basis for reliance, I would perform it for each relevant report instance unless an evaluated control design supports a different approach. A successful check during a pilot does not establish that later periods, permissions, or reporting logic will behave the same way.

For model-generated commentary, I would also separate supported facts from interpretation. The reviewer should be able to remove an unsupported explanation even when it sounds plausible and is consistent with expectations.

Retain the reasoning behind the sign-off

A useful evidence package connects the original output to the validation and the final approved version. I would retain the report identifier and run time; relevant prompts, tool calls, and parameters; the source comparison and period; the checks performed; identified differences; their resolution; and the reviewer’s conclusion. Sensitive data should stay within approved access and retention arrangements.

The objective is to show how management established confidence. A signature documents approval; the accompanying work should explain why approval was justified.

Revisit scope as reliance grows

An independent tie-out can support a practical interim design. The scope decision still needs to reflect the actual dependency. If the connector becomes the only feasible source of a control population, if transformations cannot be independently checked, or if management relies on automated exception detection, the assessment may need to bring relevant components and controls into scope.

I would document the boundary, the validation that supports it, and the triggers for reassessment. Those triggers could include a new tool version, a change in source permissions, an added data source, a revised calculation, or repeated validation failures.

There is also an investment decision here. If reviewers must substantially rebuild every report to validate it, leadership should compare that recurring effort with the cost of establishing a controlled reporting path. The best design should support both dependable evidence and a sustainable operating model.

For me, human in the loop means accountable judgment backed by independent evidence. MCP can make information easier to reach and explain. Management’s control design must establish why that information is fit for the financial-reporting decision being made.