The account that could approve itself
It is 02:14 on the third day of close. An AI agent has finished matching the operating account, drafted 46 accrual entries from open purchase orders and posted them, because posting was the fastest way to clear its queue. Two weeks later, the auditors pick entry 10482 for testing and ask who approved it. The answer in the system is the agent's service account. The approval came from the same account that created the entry.
Nobody set out to build that. When the team connected the agent, IT gave its service account a copy of the senior accountant's role so that it would "have what it needs". The senior accountant's role included approval rights for entries under $25,000. The agent inherited them. The example is illustrative, and our scenario the agent that approved itself follows a similar pattern through accounts payable.
The fix is not to stop using agents. It is to write down, before they run the close, the same rules you would apply to a new hire with system access and no judgment.
An agent is a user, not a tool
COSO's February 2026 guidance on generative AI describes agents as systems that coordinate and perform multi-step tasks with minimal human input. Its fraud risk principle warns that agents can introduce authorization risks, excessive agency and insecure interfaces. The OWASP Gen AI Security Project describes excessive agency as having three root causes: excessive functionality, excessive permissions and excessive autonomy.
Each root cause maps to a control finance already understands:
- Excessive functionality is an agent connected to more modules than its task requires. A bank reconciliation agent does not need the vendor master.
- Excessive permissions is an agent with write or approve rights it does not use. OWASP recommends limiting each extension to the minimum privileges its task needs, rather than running it through a broad privileged account.
- Excessive autonomy is an agent that completes high-impact actions without a person seeing them. OWASP recommends human approval for those actions.
The DOJ asks a version of the same question in its September 2024 compliance guidance: "What baseline of human decision-making is used to assess AI?"
Permissions are segregation of duties
One identity per agent
Every agent gets its own service account, named for its function, with a human owner recorded in your AI inventory. Shared credentials and cloned human roles make the access review meaningless, because you cannot tell what the agent did from what the person did.
Run the conflict check on agents
Put each agent's permissions through the same segregation of duties matrix you use for people. Initiating, approving, recording and holding custody are still four different duties. If an agent prepares journal entries, it should not be able to approve them. If it codes invoices, it should not be able to release payments. Our segregation of duties conflict finder lists the common conflicting pairs. Treat the agent as one more user in that exercise.
Separate the configurer from the approver
COSO adds a duty that does not exist for people: configuration. Its guidance calls for separating the ability to configure AI settings from the authority to approve or review the outputs. The person who writes the agent's instructions and sets its thresholds should not be the person who signs off on what it produces.
Approval thresholds that hold
COSO's example of a reconciliation agent is a useful template. The agent posts automatically only when match confidence exceeds a validated threshold and no policy exception is triggered. Everything else goes to a queue with enough context for a person to decide. Any change to the posting threshold requires approval from more than one person, logged evidence and sampling after the change.
Write your thresholds in a register, not in a vendor settings screen. Each threshold has three parts:
- A dollar limit. For example, no automatic posting above $10,000.
- An account rule. Some accounts are never posted by an agent alone: equity, revenue adjustments, intercompany, reserves and anything booked as a top-side entry.
- A timing rule. Entries in the last two days of close, or after the period is locked, go to a person.
COSO lists "threshold creep leading to over-automation" as a key risk for automated posting. The register, with change approvals, is how you notice it.
Logs an auditor can replay
A log that records only "agent posted entry" is not evidence. COSO says that where AI affects areas of significant impact, records should contain enough to support investigations or audits, including logs of prompts, outputs, system messages, model version, parameters and plugins used. For each action that touches the ledger, keep:
- the instruction or prompt in force at the time, with its version
- the inputs the agent read, with their source
- what it proposed and what it did
- any confidence score or exception it raised
- the person who reviewed it, if anyone, and when
Retain these for the same period as your other close evidence. If the vendor holds the logs, confirm in the contract that you can export them.
Change control covers prompts
COSO treats prompts, thresholds and connected data sources as configuration that needs the same rigor as other controlled system settings. It also flags vendor-driven changes: a model update can change behavior without any change on your side.
Your change process for agents should cover four kinds of change: instructions and prompts, thresholds, connected systems and data, and the underlying model version. Each change needs a ticket, an approver who did not make it, a test against a sample of last month's transactions, and a rollback plan. COSO's roadmap asks companies to validate vendor updates before deployment. If your vendor cannot tell you when the model changes, treat that as a finding.
Evidence your auditors will request
The PCAOB staff's July 2024 outreach found preparers already concerned that the "black-box" nature of some generative AI tools, and inconsistent output, raise questions about auditability. Expect auditors to start from a simple question: does management rely on the agent's output as evidence that a control operated?
COSO's working definition of reliance helps here. If an agent matches entries to support and a reviewer approves using only the agent's output, that is reliance. If the reviewer re-performs all or a sample of matches and documents it, that is not. Where reliance exists, COSO expects documented prompt, configuration and model version, a clear sampling rationale with exceptions resolved, and retained evidence.
The control set, in one table
| Control | What to put in writing | Evidence to keep |
|---|---|---|
| Agent inventory | Each agent's task, systems, data read and written, and named owner | Inventory with review dates |
| Own identity | One service account per agent; no cloned human roles | User listing showing agent accounts |
| Least privilege | Only the modules and rights the task needs | Permission export, reviewed quarterly |
| Segregation of duties | Agent permissions tested against the SoD matrix | Conflict report with resolutions |
| Configurer and approver split | Who configures each agent; who approves its output | Role assignments, signed |
| Approval thresholds | Dollar, account and timing rules | Threshold register with change approvals |
| Review queue | Who clears exceptions and how fast | Queue aging report |
| Replayable logs | What is logged and how long it is kept | Log samples tied to ledger entries |
| Change control | Prompts, thresholds, connections and model versions | Tickets, test results, rollback records |
| Monitoring | Expected match rates, override and reversal rates | Monthly metrics against tolerance |
| Exit criteria | The metric levels that take the agent out of the close | Signed criteria and any triggers hit |
Where to start
Pull the user listing from your ERP today and find every non-human account. For each, ask who owns it, what it can do, and whether that includes approving its own work. Then write the threshold register before any agent's limits are raised. If you want the inventory, permissions review and AI policy built together, see AI Governance for Finance, and pair it with an AI governance policy for finance teams.