Segregation of duties for AI agents: who may enter, approve, pay and reconcile
By Maren Calloway · November 2, 2026
Category: accounting-operations
Most guidance on controlling AI agents covers spend limits. It skips the older question: which duties may one identity hold? Here is a duty matrix a controller can hand to internal audit.
Key takeaways
The problem Agent controls focus on spend caps, while the older control question stays open: can one agent identity enter, approve, release and reconcile the same item?
Core insight An agent is a user with a very fast hand. Segregation of duties applies to it the same way it applies to a clerk.
Practical outcome Give each agent one duty and its own identity, forbid it from approving its own output, and put every change to its limits under a second person.
Say a team gives one agent access to code invoices, approve the low-value ones, and release the payment file. Each step passes a test. Together, the agent holds three of the four duties that controls exist to keep apart.
This is the gap we see in public guidance on agents. Ramp's post on spending controls for AI agents sets out eight practices: scoped payment credentials, budget caps, approval thresholds, merchant locks, token quotas and named ownership among them. They are sound. The post does not address who may build, approve, pay and reconcile for an agent, or whether an agent's owner may raise that agent's own limits. That is the segregation of duties question, and it is the first one an auditor will ask.
Where agent permissions stand today
Teams grant agent access the way they grant integration access: broad, once, and to a shared service account. That habit made sense when the integration moved a file. It fails when the integration decides what to post.
We did not find primary guidance from the PCAOB or the SEC that speaks to agents by name. What exists is the general frame. PCAOB AS 2201 governs the audit of internal control over financial reporting, and the COSO publication on internal control over generative AI applies the COSO framework to AI tools. Neither removes the old duty to separate incompatible tasks. See the general concept of separation of duties if you need a shared definition for a steering group.
What an agent is, for control purposes
An agentic system plans several steps, chooses tools, and acts inside limits without a person approving each step. For a control owner, the useful reading is narrow: it is an identity with permissions, and it acts at a speed no clerk matches.
That reading settles three questions. The agent needs its own identity, never a shared login. Its permissions are tested the way a privileged user's are. And its output is a proposal until a different identity accepts it.
The duties an agent must not combine
List the duties in the flow, then assign each to one identity. The matrix below uses accounts payable, but the logic holds for journals and cash application.
| Duty | May an agent hold it? | Condition |
|---|---|---|
| Capture and code the invoice | Yes | Output is a proposal with the source document attached. |
| Approve the invoice | Only for a defined low-risk class | A different agent or person than the one that coded it. A person owns the rule that defines the class. |
| Release the payment | No, by default | A person or a separate payment identity, with a bank-side limit. |
| Reconcile the cash account | Yes | Never the same identity that released the payment. |
| Change vendor bank details | No | A person, with call-back verification. |
| Change the agent's own limits or prompts | No | A named second person approves, and the change is logged. |
The last row matters most. An agent that can edit its own thresholds has no threshold.
Wiring it into the ERP and identity layer
A policy on paper does not stop anything. The control has to live in the systems.
- Create one service identity per agent and per duty, not one per project.
- Map each identity to an ERP role that carries only that duty. Test for conflicts the way you test for conflicts between human roles.
- Keep credentials in a vault, with short lifetimes where the system allows it.
- Write the agent's identity into every record it touches, so the trail shows which identity acted. Our guide on how to audit what an AI agent did in your books lists what to log.
OWASP's guidance on prompt injection says the same in security terms: enforce least privilege and require human approval for high-risk actions, and keep tokens in application code, not in the model's reach. Separation of duties and least privilege are two views of one design.
Risks and governance
Three failures recur in designs like these.
- Self-approval by configuration. The owner of the agent loosens a threshold, then the agent approves what it could not approve before. Fix: separate the person who edits limits from the person who benefits from them.
- Shared credentials. Two agents on one login look like one actor. Fix: one identity per agent.
- Approval fatigue. A person approves every proposal in seconds. The control exists on paper only. Fix: test it, as described in our piece on approval workflows and controls.
None of this is legal or audit advice. Your external auditor decides what evidence satisfies them, so ask before the first agent goes live.
What to bring to your auditor this year
Do not wait for a standard that names agents. Bring a one-page duty matrix, the list of agent identities with their roles, the change log for limits, and the result of one conflict test. If a person on your team can read that page and explain it, the design is sound enough to start.
Then pick one agent, give it one duty, and run it for a close before you widen it.