Let the Agent Analyze. Keep the Financial Decision Human.

Financial teams want AI agents to do more than summarize documents. An agent might search policies, reconcile transactions, explain a forecast variance, or prepare a recommendation. The question is how to let it do useful work without allowing a plausible but mistaken answer to become an unreviewed financial action.

In “Trust in Depth: Giving agents more autonomy without losing control,” AWS argues that approving every step is not a scalable answer. As approvals accumulate, reviewers can become fatigued and miss the decisions that deserve their attention. The article instead describes layered trust: scope the agent’s job, know its identity and authority, bound its actions, and observe what it does. Let it act independently where the action can be verified; reserve human judgment for consequential or ambiguous decisions.

That principle fits the central message of Ed Freitas’s The Impact of AI in Financial Decisions: AI can process information and recommend a course of action, but a human must decide whether that output deserves to influence the business. The goal is not to approve every model sentence. It is to design the workflow so people retain authority over which outputs become financial decisions.

Human oversight is a decision right, not a button

“Human in the loop” can mean anything from a meaningful review to a person clicking approve on a screen they do not have time to assess. A control is meaningful only when the reviewer has the evidence, expertise, authority, and time to challenge the recommendation—and the system gives them a real choice to approve, change, defer, or reject it.

The book’s fraud-detection example illustrates a useful division of responsibility. The model scores transactions; a human analyst reviews cases above an agreed threshold. The example reports improved detection and fewer false positives in that scenario. It does not suggest that those results are guaranteed elsewhere. Its practical point is the allocation of work: AI prioritizes evidence, while an accountable analyst decides what action follows.

The book’s lending workflow uses a similar boundary. AI can collect and verify documents, flag discrepancies, and produce a preliminary underwriting recommendation. The human underwriter reviews the recommendation and supporting documents, makes the credit decision, and signs off (p. 58). In its closing discussion, the book states that outputs become decisions only through the judgment of the person who reads them (p. 204). That is a governance design choice, not a claim that a model can be made infallible.

Autonomy works best inside boundaries the agent cannot rewrite

An agent can follow several individually permitted steps and still reach an unintended result. A finance agent might retrieve a valid policy, select a permitted spreadsheet tool, and draft an accurate journal narrative—then post a journal entry that no one intended it to submit. Instructions in a prompt are not an adequate safeguard because the model itself interprets those instructions.

Separate the agent’s reasoning from the controls that authorise action. Define what it may read and do through access permissions, deterministic rules, approval gates, and system-side limits. The agent can propose an action, but it cannot raise its own payment limit, grant itself new access, or bypass a human approval requirement. Log the evidence used, the tools called, the controls applied, and the final disposition so a reviewer can reconstruct the path.

AWS’s four questions help organise that design:

• Scope: What job is the agent doing, what information and tools does it need, and which decisions must stay with a person?
• Know: Which named agent acted, under whose authority, and can each action be traced to that identity?
• Bound: What rules are enforced outside the model, across the entire sequence of actions?
• Observe: Can the team reconstruct what the agent saw, did, and returned—and detect when the result was wrong?

For a finance workflow, add a human decision point wherever interpretation, materiality, policy exceptions, customer impact, or irreversible action matters. Keep automatic checks for matters that can be precisely tested, such as arithmetic, required fields, duplicate identifiers, and approved thresholds.

Example: a variance agent that cannot move the budget

Imagine an agent helping investigate a department whose expenses are above forecast. Give it read-only access to an approved ledger extract, the budget, prior-period totals, and the relevant expense policy. Ask it to calculate the variance using a specified formula, cite source rows, flag missing evidence, and propose several explanations with evidence that would confirm or weaken each one.

The agent can prepare a review pack. It cannot edit the ledger, transfer budget, change a forecast, or send a conclusion to executives. A finance professional checks the figures, speaks with the budget owner, decides which explanation fits the facts, and authorizes any adjustment. If an approved system later executes that adjustment, it should recheck the authorised amount and account at the point of action.

This is not needless friction. The book’s decision exercises ask finance leaders to compare proposed AI pilots by business value and implementation risk, and highlight why autonomous trading can be an unsuitable first project for an organisation whose expertise and controls are not ready for it (p. 187). The principle is to match autonomy to the stakes and the organisation’s ability to govern it.

A prompt that supports judgment without pretending to replace it

Prompts can define an analysis task and expose uncertainty. They cannot enforce permissions. Use them alongside technical controls, not in place of them:

You are a finance decision-support assistant. Review the approved data provided
for this variance investigation.

1. Recalculate the variance using the stated formula and show the inputs.
2. Separate verified facts from hypotheses. Cite the source file and row for each.
3. Give up to four possible explanations and identify evidence for and against each.
4. State what information is missing and what question a finance reviewer should ask.
5. Do not change records, transfer funds, alter forecasts, contact anyone, or make
   a final accounting or management decision. Return recommendations for review.

For a higher-stakes decision, ask the agent to challenge the preferred option:

Act as a skeptical reviewer of this proposed finance decision. Identify the
assumptions that could change the result, plausible alternatives we have not
considered, downside scenarios, and evidence that would disconfirm our preferred
option. Distinguish facts from estimates. Do not choose or execute an option.
Name the human role that must make the decision and list the checks required
before any action is authorised.

Then make the technical workflow match the prompt: read-only credentials for analysis, strict schemas for any structured output, independently calculated figures, a named reviewer, and a system-enforced approval before a consequential action. Never rely on the model to police its own access.

Use different approval levels for different risks

Requiring approval for every low-risk action can exhaust reviewers. Allow routine, reversible work—such as classifying an item into a review queue—to proceed automatically if the process has clear limits, monitoring, and a way to correct mistakes. Let an agent prepare analysis and draft recommendations for a person to review. Require explicit human authorization for material credit, investment, accounting, customer, regulatory, or payment decisions. Keep actions outside the agent’s permissions if they cannot be made safe with enforceable controls.

Before expanding autonomy, test the complete workflow with normal cases, edge cases, misleading documents, missing data, and attempted prompt injection. Track extraction errors, unsupported recommendations, reviewer overrides, approval delays, policy violations, and the time needed to stop or reverse an action. If reviewers routinely approve without checking, the control exists on paper but not in practice.

Human control means owning the outcome

No organisation can promise that every AI output will be correct. Human control means something more concrete: the organisation decides what the agent may access, which actions it can take, what conditions require escalation, who has approval authority, and how a mistake is contained. For high-impact financial choices, a qualified person remains responsible for the final decision and can reject or amend the recommendation.

That is how the book’s approach and AWS’s layered trust idea reinforce each other. Let AI do more of the search, comparison, calculation, and drafting. Put hard limits around its tools and permissions. Make uncertainty visible. Give people enough evidence and authority to make the call. Well-designed controls let an agent contribute at speed without handing it the organisation’s decision rights.

The most useful question is not “How autonomous can we make this agent?” It is “Which work can it complete safely, which outcomes require a person’s judgment, and what controls prove the difference?”