Giving an agent access to the ERP changes the nature of an AI project. A poor summary can waste time. An incorrect transaction can alter the ledger, disrupt a supplier relationship or create a difficult reconciliation problem.
The access decision should therefore be expressed in business terms: which records may be read, which actions may be proposed, which actions may be executed and who remains accountable for approval.
Finance does not need a new vocabulary for every control. It needs the existing principles of authority, evidence and reconciliation applied to a system that can interpret information and select actions.
Automation does not require unrestricted autonomy
The Bank of England and FCA's 2024 survey found that 55% of reported AI use cases involved some automated decision-making, while only 2% were fully autonomous. The findings concern UK financial services respondents and all their reported AI applications, not corporate finance teams or agentic ERP workflows specifically. They show that automation and human oversight can coexist; they do not establish an appropriate autonomy level for your process. Bank of England and FCA, AI in UK financial services
Begin with the smallest useful permission set. Reading a supplier record, preparing a proposed journal and posting that journal are separate permissions. They can be introduced in stages as the evidence justifies them.
The objective is to permit useful work while keeping consequential actions inside an enforceable boundary.
Write an action policy before connecting tools
For each action, record the allowed entity, record types, value limits, required evidence, approval authority and conditions that force escalation. The policy should be specific enough to test.
| Control | Design question | Evidence to request in the proof |
|---|---|---|
| Limited permissions | Can the workflow act only on the agreed records and operations? | Attempts outside scope are rejected by the execution layer |
| Separation of duties | Can the same identity prepare and approve a restricted action? | Conflicting responsibilities remain separated |
| Approval integrity | What exactly does a person authorise? | Approval is bound to a specific action and material transaction details |
| Duplicate prevention | What happens if a request is retried? | The final system state contains only the intended transaction |
| Traceability | Can a reviewer reconstruct the outcome? | Source evidence, policy version, approval and transaction identifiers are retained |
| Reconciliation and recovery | How are incomplete or incorrect actions detected? | Independent checks expose discrepancies and a tested recovery path exists |
These are recommended acceptance criteria. They need to be implemented through the actual systems and agreed for the engagement; they are not a claim that a generic agent automatically supplies all six.
Enforce authority outside the model's prose
A prompt can describe a spending limit, but the tool or transaction system should enforce it. If an action exceeds the permitted amount or entity scope, it should fail even when the model requests it confidently.
Microsoft's finance and operations documentation describes identifying and resolving segregation-of-duties conflicts. Existing ERP security structures provide an important foundation that an agent's service identity should respect. Microsoft Learn, segregation of duties
Avoid using a broad shared administrator account simply because it makes the demonstration easier. Define the service identity and its permissions explicitly, with a named owner for changes and periodic review. Test the combination of permissions, not just each one in isolation.
A workflow that prepares a supplier change should not automatically gain authority to approve that change and release the resulting payment. The same principle applies to people and automation.
Preserve the boundary between data and instructions
An agent may read supplier emails, invoices and attachments. Those inputs can contain misleading assertions or instructions that conflict with the company's policy. External content must remain evidence to evaluate, rather than a source of permission.
NIST's Generative AI Profile identifies confabulation and security risks among the issues organisations should address. In an ERP workflow, that supports testing both incorrect factual claims and attempts to redirect the agent's behaviour through the material it reads. NIST, Generative AI Profile
For example, a document saying “ignore the approval process” must not change the permitted tools or transaction limits. A supplier's claim that new bank details are authorised must still go through the established verification process.
Minimise the data exposed to each task and control retention of logs and attachments. The evidence trail should support review without becoming an uncontrolled copy of the entire finance system.
Check the transaction after execution
A successful tool response is one signal. The business should also be able to establish that the intended record exists, has the correct amount and entity, and has not been duplicated or left in an intermediate state.
This matters when requests time out. A timeout may mean the action failed, or it may mean the action completed but the response was lost. Recovery should inspect the existing state before deciding whether another attempt is safe.
Use test cases that interrupt the process between approval, submission and confirmation. Include simultaneous manual action by a colleague and changes to the underlying record while a decision is pending. These tests expose assumptions that a clean demonstration rarely reaches.
Judge error rates against scale and consequence
At 20,000 actions a month, an error rate of 0.1% corresponds to 20 errors. That is arithmetic, not a prediction of agent performance. Whether it is tolerable depends on what the errors do, whether they are caught before execution and how quickly they can be corrected.
Separate incorrect suggestions from unauthorised postings, missing evidence and duplicate transactions. An overall accuracy number can conceal materially different outcomes.
The proof should deliberately include rare but serious scenarios as well as a representative sample of normal work. A workflow may appropriately refuse to act when evidence is missing. Record that as a safe escalation and include the resulting human effort in the business case.
Define who can stop and restart the workflow
An operating plan should name the people who monitor exceptions, disable actions, investigate incidents and approve a return to operation. It should also explain how finance continues the process manually and how the two paths avoid handling the same case twice.
Curia's service starts with a contained proof and agreed performance and controls before launch. The access boundary, evidence requirements and operating responsibilities should be concrete parts of that agreement. Finance retains judgement and sign-off while Curia operates the workflow within its scope.
That is the basis for expanding access over time: observed performance against explicit controls. For the wider decision, see moving a finance AI pilot into production.
Bring Curia the workflow, required ERP actions and approval policy. We will assess the control design and the evidence needed before granting production access. Discuss ERP workflow controls