The situation
This is an illustrative scenario. It is a composite built from patterns common in this kind of work and does not describe any real client.
A Series C business software company with about 420 employees and two legal entities runs its finance function on NetSuite. The finance team is fourteen people, including a controller, an accounts payable manager and two AP specialists who process roughly 900 vendor bills a month. The company had just begun SOX readiness work ahead of a possible listing.
Seven months earlier, the AP team had switched on an AI agent from its AP automation vendor to handle invoices arriving by email, about a third of the volume. The agent extracted the vendor, amounts and line detail, matched a purchase order where one existed, coded the account, department and class, and created the vendor bill in NetSuite. Each bill was then meant to enter the existing approval workflow. PO-matched bills under $10,000 went to the AP manager, bills without a purchase order went to the budget owner, and anything above $10,000 also went to the controller.
During implementation, the vendor's onboarding team and an internal systems administrator set up an integration role for the agent's service account. To get the pilot running quickly, they copied the permissions of an AP specialist who also served as a backup approver. Nobody revisited the role after go-live.
The controller noticed the problem while pulling a user-access listing for the auditors' SOX readiness kickoff. The agent's service account held the AP Approver role.
What we did
The company asked for a four-week diagnostic under our AI governance for finance service, with the AP flow as the first case. The engagement lead mapped an invoice's full path: inbox, agent, NetSuite bill, approval workflow, payment run and the bank portal, where release still required two people.
A forensic data analyst pulled twelve months of vendor bills with their system notes, using the five months before go-live as a baseline. The pull also included the login audit trail, a role and permission export for every user and integration, the vendor master change history and the agent's run logs from the vendor's console. The tests asked the same questions of every bill:
- Who created it, and who approved it?
- How long passed between creation and approval, and at what time of day?
- How close was the amount to an approval threshold?
- Was the vendor created or changed recently, and by whom?
The controls specialist walked through ten bills with the AP manager, then reviewed the agent's configuration with the systems administrator and the vendor's implementation lead: its instructions, permitted actions, confidence thresholds and log storage.
A second track inventoried every AI tool used in finance, drawing on a staff survey, expense reports, software subscriptions and browser extension data from IT.
What we found
Since go-live, 1,312 bills under $10,000 had been created and approved by the service account, with a median of four seconds between the two. In the baseline months, human approvals had taken anywhere from twenty minutes to three days. Most of the agent's approvals fell between 02:00 and 04:00, when it ran its overnight batch. Of those bills, 214 had no purchase order, so no budget owner had seen them before payment.
Nobody had designed this. Years earlier, a convenience rule had been added to the approval workflow for the AP manager's own entries: if the creator of a bill under $10,000 held the AP Approver role, the approval step was marked complete. The agent's account held that role.
The findings register ranked the issues by consequence:
- The agent could approve its own work. For bills under $10,000, the approval control was absent for everything the agent created.
- The agent could create and edit vendor records, including bank details. The service account had created 23 vendors from invoices that matched no existing record. For two of them, remittance details came from the invoice itself and had never been confirmed by a call to a known number.
- Logs could not explain decisions. NetSuite recorded the service account as the actor but not which agent run or source document produced a bill. The vendor's console kept extraction and reasoning logs for 30 days. Most coding decisions could no longer be reconstructed.
- No one owned the agent. IT believed finance reviewed its output, and finance believed IT controlled its access. A review of 400 agent-coded bills found 31 whose department coding did not match the requester's department, a budget-reporting problem rather than a loss.
- The AI policy covered chat tools only. The one-page policy addressed confidential data in chatbots and said nothing about systems that take actions. The inventory found eleven AI tools in finance: three with write access to a financial system, and two that analysts used with ledger exports on personal accounts.
The AP manager and the budget owners then reviewed all 214 non-PO bills after the fact. Two were duplicates of bills already paid, submitted with different invoice number formats and totaling $14,600, and both vendors refunded them. Every other payment went to a vendor the company could identify and had a reason to pay.
What changed
Over an eight-week project the company changed the agent's authority, not its job.
- Permissions. A new integration role lets the service account create and code vendor bills and read vendor records. It cannot approve, create or edit vendors, or touch payment runs. The account now sits in the segregation-of-duties matrix like any other user, and the convenience rule was removed from the workflow.
- Approval thresholds. Every bill the agent creates now goes to a person: the AP manager for PO-matched bills, the budget owner for everything else, and the controller as well above $10,000.
- Vendors. The agent may propose a new vendor but cannot create one. An AP specialist sets it up, and bank details are confirmed by a callback to a number from an independent source.
- Logging. Each bill now carries the agent run ID and a link to the source document. Agent logs are exported nightly to the company's own log store and kept as long as the transaction records.
- Policy. A revised AI use policy sets approved uses, permitted data, actions agents may never take (approving, releasing payments, changing master data), change control for agent configuration, review of vendor model changes and incident reporting. It maps to COSO's February 2026 generative-AI guidance and the NIST AI Risk Management Framework.
- Ownership. The AP manager owns the agent's output, the systems administrator owns its access, and the controller reviews both each quarter.
After a six-week setup, continuous controls monitoring began weekly tests for bills approved by their creator, any approval by a service account, bills within five percent below a threshold, vendor bank-detail changes and likely duplicates. Exceptions go to named owners, and the controller receives a monthly exception report. The company shared the findings and the changes with its auditors as part of SOX readiness; classifying the issue was for management and the auditors.
What to take from it
The agent did its job reasonably well. The failure was one of authority: an account set up for speed during a pilot kept rights that nobody would have given a new employee. The general lesson: treat each agent as a user, give it the narrowest permissions that let it work, keep a person on every approval that matters, and keep logs long enough to explain what happened.
If you are putting agents into AP or the close, Before AI agents run your close sets out the controls to put in writing first. The Segregation-of-Duties Conflict Finder can help you see where service accounts sit in your access matrix.