AI Governance in Finance: The Model Prepares, a Person Commits
AI governance in finance comes down to one question an auditor will ask: who changed this number, and who approved it? If the answer is “the AI”, you have no answer. The controls that fix it are plain: the model only reads by default and you prove it, it writes only into a holding area, a person commits with a deliberate action, every action runs under a named user, and the trail records all of it.
We apply these controls to the AI agent we run on our own Business Central for internal checks such as time sheets. Each one below exists because we needed it.
What will an auditor ask about AI in finance?
The same questions as for any change to financial data, with one more. Who made the change? With which permissions? When? Who approved it? And the new one: what did the model propose, and what did the person accept?
That last question is the one most AI setups cannot answer. If the model writes straight into the ledger, the proposal and the decision are the same event, and nobody can show that a person looked at it. Every control below exists to keep those two events apart.
None of this needs a new framework. It is the separation between preparing and approving that finance already applies to people, applied to a tool that prepares very fast.
Why should an AI agent never have its own account?
Because the audit trail would then say “the account”, and that is not a person.
On Business Central, the native MCP server, the standard connection between AI clients and the ERP, runs every operation under the signed-in user’s identity and permissions. Microsoft’s documentation states that audit trails then show who performed each action. An agent cannot do more than the person it runs as, and everything it does carries that person’s name.
A shared “AI” user throws that away. It also tends to collect permissions over time, because each new use case needs one more right, and nobody owns the account enough to say no. One user per person, the agent inheriting that person’s rights, keeps the question “who” answerable.
What does read-only by default mean in practice?
It means read-only you have proven, not read-only you were told about.
Two facts from our own setup. First, the permission the AI client receives in Entra ID is a read-write one: Microsoft’s setup guide uses the delegated permission Financials.ReadWrite.All, and we found no read-only scope for Business Central. So the guardrail cannot live in the identity layer. It lives in the ERP: in the MCP configuration and in the user’s own permissions.
Second, we do not trust the configuration switch. We search the agent’s available actions for anything that creates, modifies or deletes, and a read-only configuration answers that there are none. That answer is the proof. The detail is in our article on AI agents inside Business Central.
The configuration itself is also traced. Microsoft documents telemetry, from version 28.0, for MCP configurations being created, modified or deleted, including whether edit tools are allowed. Turning on write access for an agent is itself a logged event. That is the record a controller should check first.
How should an AI write into financial data?
Through a door built for it, never straight into the data.
Our pattern: the model fills a holding area, a staging page in our own extension. A separate, explicit action, run on purpose, moves the content into the real records. The model prepares. A person commits.
This is the part that makes the AI safe, and it is not an AI feature. It is ordinary ERP work: a buffer, an action, a permission on that action. It also leaves the ERP’s own approval steps where they are, with people. An AI setup that needs to bypass an approval to work is a setup that should not exist.
Before any write, the agent also checks which company it is connected to, and tests run in a test company, never in production.
What should the audit trail contain?
Enough to rebuild the decision, not just the change.
On Business Central, Microsoft documents telemetry for MCP server tool calls from version 28.0. Each event carries the user’s telemetry ID, the tool called, the MCP configuration used, the client that made the call and whether it succeeded. Combined with the ERP’s own change records, that shows who asked the agent to do what, through which configuration.
We add one thing on our side: the evidence behind what the agent read. A proposal built on a misread is still a misread after a person approves it. So the filter used, the row count and the date range read travel with the proposal, as described in our method for verifying what an AI agent reads on ERP data. An approval is only as good as what the approver was shown.
Which decisions stay with a person?
Every write that changes a financial record, and every correction that would require a guess.
The model is good at preparing: reading a month of entries, grouping them, flagging the lines that do not add up, drafting the corrections. It should not decide whether a line is right when the line itself does not say. In that case it flags the line and names what is missing, and the person who knows the context decides.
The same holds for permissions. Opening a new write path for an agent is a decision with an owner, a date and a reason, not a configuration change someone makes on a Friday afternoon.
The Asio Services way
We start every AI project in finance read-only, and we prove it. Writes open one door at a time: a holding area, a deliberate action, a check on the target company, a named user, and evidence attached to every proposal. That is how we build AI for multi-entity groups: the controls are designed before the first write, not added after the first incident.
If your finance team is blocking AI because nobody can answer “who changed this number”, start with a clarity session.
FAQ
Can an AI agent post entries in the ERP on its own?
It can if you let it, and it should not. Keep the agent read-only by default, let it write only into a holding area, and have a person commit with a deliberate action. The audit trail then shows a person’s decision, not a tool’s side effect.
Does an AI agent need its own user account?
No, and it should not have one. On Business Central the MCP server runs every action under the signed-in user’s identity and permissions, so the trail names a person. A shared “AI” account turns that name into “the account”.
What will auditors want to see about AI use in finance?
Who made each change, under which permissions, and who approved it. Also what the model proposed versus what a person accepted, and the evidence the person saw. Telemetry and the ERP’s change records cover the first part; a holding area and a deliberate commit cover the rest.
Is read-only access to financial data enough to be safe?
It is the right start, not the end. Read-only must be proven, not assumed, and an agent can still misread data and lead a person to a wrong decision. Verification of what was read is part of the governance.