The real change is not “more automation” but the transfer of execution authority

Finance automation is nothing new.

Automatic posting in the ERP, RPA bots downloading bank statements, Python scripts generating reports: all of these remain deterministic automation. The logic is defined by a person in advance, and the system executes fixed rules.

Agentic AI is different.

It can understand a goal, decompose the task on its own, choose tools, generate SQL, write code, read the results, notice anomalies, revise its method and run again. Anthropic’s cyber cases already show AI that is not merely “answering questions” but embedded in a complete execution chain.

Mapped onto finance, the system of the near future looks like this:

At that point AI is no longer only “assisting the finance team”. It is gradually becoming a digital employee with system permissions, data access and a degree of execution authority.

The central question of finance AI governance therefore shifts from:

“Is the AI’s answer accurate?”

to:

First challenge: enterprises must rethink the AI information boundary

When companies discussed AI security in the past, the most common question was:

“Will my data be used to train the model?”

Anthropic’s report shows that this question is too narrow.

In several of its threat investigations, the platform combines account behaviour, infrastructure, VPN use, time zones, language settings and activity patterns to analyse and attribute activity. The report also states that the platform uses metadata and anomalous activity patterns to identify proxy networks, and in some cases tries to attribute activity to specific organisations.

More notably, in the biosecurity section Anthropic states that governance of high-risk use needs to combine:

account and institutional signals

with:

observability provided by data retention

The report goes further: an AI provider may gradually gain a kind of real-world threat visibility that even governments and international organisations do not necessarily have.

This does not mean “the model provider can see everything a user does”. The report itself notes that in influence-operation investigations, its direct visibility ends once the activity leaves the Claude platform, after which it relies on open-source intelligence, industry data and public reporting.

From a corporate governance standpoint, however, this is enough to establish an important point:

For finance systems that hold bank data, tax files, management reports, pricing, treasury plans, customer information and business strategy, the distinction matters a great deal.

When enterprises evaluate AI services in future, they may need to consider data retention, telemetry, account linkage, human investigation access, third-party sharing and legal disclosure together, not the training policy alone.

Second challenge: “approve every write” is not governance

Faced with an AI agent, the most natural control reflex is:

Every write operation requires human approval.

It sounds safe. In practice it can create new risk.

If the agent needs a human to click Approve every time it runs a Python script, writes a temporary table or modifies an intermediate result, users very quickly develop approval fatigue.

The usual end state is:

Every prompt gets approved without thinking.

At that point the human in the loop is no longer reducing risk. It is adding a control that exists only in form.

The more reasonable design principle is therefore not “the more human approval, the safer”, but:

I call this approach:

The object of governance should be the risk boundary, not read versus write

Traditional IT permission management is used to a simple distinction:

Read = relatively safe. Write = relatively dangerous.

In an agent setting, that classification is too coarse.

An agent writing large volumes of intermediate results into an isolated scratch table is technically a write, but the risk may be very low.

Conversely, a read-only query that touches payroll, bank accounts or sensitive customer data may carry higher risk.

Agent risk should therefore be assessed on at least these dimensions:

Impact, reversibility, scope, data sensitivity and external effect.

Together these form a new permission envelope.

A finance analysis agent, for example, might be authorised to:

• read approved data sources;
• run SQL and Python;
• generate analytical results;
• write to an isolated workspace;
• retry and validate automatically.

But not to:

• modify the official ledger;
• change vendor master data;
• release payments;
• alter production permissions;
• send sensitive data outside the enterprise;
• access credentials it has not been granted.

Only when the agent needs to step outside this envelope does the system genuinely require human approval.

What has real value is “semantic approval”, not “technical approval”

Many agent systems today still ask the user to approve:

Allow this Python to run? Allow this SQL to execute? Allow this API call?

For a finance leader, these are poor objects of approval.

What a finance manager can actually judge is:

What business consequence will this adjustment have?

The more sensible model, then, is to approve “business impact” rather than “technical action”.

A manager should not be asked to approve:

They should instead be asked to review:

The system proposes a set of adjustments, several of which exceed the established materiality threshold. Please confirm their effect on profit, the balance sheet and disclosure.

This can be summarised as:

In other words:

Machines control technical actions; humans judge business consequences.

None of this conflicts with existing finance internal control.

Traditional financial control already rests on:

materiality, segregation of duties, exception control and the audit trail.

AI governance should inherit those principles rather than invent an approval system detached from finance logic.

The future is more likely human-on-the-loop than human-in-the-loop

A mature finance agent system should not require a person to take part in every step.

The more realistic state is that the agent completes a large volume of routine work autonomously, while humans supervise risk and exceptions from above.

A month-end close agent, for instance, can read the data, reconcile, apply matching rules, flag anomalies and produce reports on its own, while finance staff review only a small number of exceptions.

That is:

rather than:

This can be called human-on-the-loop.

The human is no longer the button-presser for each step the agent takes. The human is its supervisor and the bearer of final accountability.

This is close to how audit already thinks:

Prompts, memory and agent skills are becoming the new “code”

Anthropic’s report reveals another trend that enterprises should take seriously.

In some influence operations, the operators no longer relied on one-off prompts. They wrote doctrine, approved sources, banned words and evasion rules into long-term memory or shared files, so that the agent could keep executing across sessions.

The implication for enterprise AI governance is direct.

The following can no longer be treated as ordinary “configuration”:

They are, in effect, close to code.

Enterprises may therefore need to manage agent instructions the way they manage program code:

version control, testing, approval, change records and production lock-down.

The principle can be summarised as:

If one rule is wrong, the damage may not be a single output. It may be the next several hundred automated executions.

Finance AI needs a control plane that sits outside the model

This is the most important layer of the whole framework.

An enterprise cannot hand every security and permission decision to the LLM’s own judgment.

An LLM can reason, recommend and plan. It should not itself be the final security boundary.

A more reasonable enterprise AI architecture might look like this:

The core principle:

Put another way:

This may become the foundational architecture of finance AI internal control.

Data sovereignty may raise the share of self-hosted and open-weight AI

The report also offers a case worth reading in reverse.

In the Mali surveillance case, the report states that the platform ultimately deployed ran on fully on-premises local models. Anthropic could ban the relevant accounts, but a system already deployed locally does not stop running because of account enforcement.

From a platform-security standpoint, that is a governance problem.

From the standpoint of a legitimate enterprise, it illustrates the value of self-hosted AI:

Demand for open-weight and self-hosted AI in highly sensitive sectors, finance, banking, law, healthcare and government among them, is therefore likely to keep growing.

The real value is not that “the model is free”. It is:

privacy, sovereignty and control.

Enterprise AI architecture is also unlikely to rest on a single model. A hybrid pattern is more probable:

One can go a step further and separate “computation” from “reasoning”.

Raw transactions, bank statements and sensitive line items are processed locally with SQL, Python and a local model. Only aggregated, de-identified conclusions are then passed to a more capable cloud model for further interpretation.

That is:

This may become an important pattern in enterprise AI architecture.

A possible management prototype: the AI Internal Control Framework

Taken together, these changes suggest that enterprises will gradually form a new body of controls, analogous to ITGC, SOX or the internal control frameworks that already exist:

I expect at least five core pillars:

Together the five resolve one central tension:

A truly mature governance structure is:

High autonomy + strong boundaries + exception review + traceable accountability.

Conclusion: the competition in finance AI may not be about who uses the strongest model

Anthropic’s report is not a finance-governance report.

But it opens an important window onto the present.

It shows AI evolving from a chat tool into an executing actor inside real workflows. At the same time, model providers now have content-level and behaviour-level observability that ordinary software vendors rarely had.

When those two changes compound, the question for enterprises is no longer only “how do we use AI to become more efficient”, but:

Finance internal control used to manage two objects:

people and systems.

A third is arriving:

the AI agent.

The real competitive advantage in finance digitalisation may therefore not be “who uses the strongest model”, but who can build a governance system that allows AI a high degree of autonomy while preserving data sovereignty, controllable permissions, auditable behaviour and traceable accountability.

That is the core of what I understand by the Finance AI Bounded Autonomy Framework:

This may be the earliest management prototype of finance AI governance.