How do you implement segregation of duties when using an FP&A agent in your finance team?

Segregation of duties (SoD) has been a foundational control in finance for decades: the person who prepares a transaction should not be the same person who approves it, and no single individual should control an end-to-end process. When an AI agent enters the FP&A workflow — drafting forecasts, posting journal entries, adjusting budgets, or generating variance commentary — that principle does not disappear. It gets harder to apply, because the 'person' doing the work is now software with broad system access and autonomous decision-making capability. This guide explains what segregation of duties means in the context of an agentic FP&A platform, why it matters more in 2026 than it did three years ago, and how to design controls that satisfy auditors without strangling the efficiency gains that justified the agent investment in the first place.

What Segregation of Duties Means in an Agentic FP&A Environment

Also worth reading: What is an autonomous finance operations strategy for 2026 and how can FP&A teams implement it? · What are AI finance governance frameworks in 2026 and how should finance leaders implement them? · What are the best AI agent financial governance strategies for enterprise finance teams in 2026?

Traditional SoD rests on three separations: authorization (who approves), custody (who executes), and recording or review (who verifies). In a manual or semi-automated FP&A function, these map cleanly onto roles — an analyst builds the forecast model, a finance manager reviews assumptions, a controller approves budget changes, and internal audit tests the whole chain periodically. The introduction of an AI agent disrupts this mapping because a single agent can, if configured carelessly, perform all three functions simultaneously: generate a forecast, adjust the driver assumptions behind it, post the resulting reforecast into the planning system, and write the variance narrative that management reads.

The core risk is not that the agent is malicious; it is that the agent inherits whatever permissions its integration credentials carry. If your FP&A agent connects to your ERP and planning tools with a service account holding admin rights, then every action the agent takes — correct or incorrect — bypasses human authorization entirely. Auditors increasingly treat agentic systems as non-human users subject to the same access-review requirements as employees under frameworks like SOX Section 404, SOC 2, and ISO 27001. A 2025 survey of public-company audit committees found that roughly 62% had already asked management how AI-generated financial outputs were being controlled, up from under 30% two years earlier. The direction of travel is clear: by 2026, an uncontrolled FP&A agent is an audit finding waiting to happen.

Why Agents Break Traditional Control Models

Conventional ERP role design assumes discrete, logged actions performed by identifiable humans. An agent violates several of those assumptions at once. First, volume: an agent can execute thousands of planning adjustments per hour, making sample-based manual review statistically meaningless. Second, opacity: if the agent's reasoning is not logged in a structured way, reviewers cannot reconstruct why a particular forecast revision was made. Third, scope creep: agents are often granted broad read-write access 'to be useful,' which quietly collapses the separation between data preparation, model execution, and output approval.

There is also a subtler problem: accountability diffusion. When a variance report contains an error, who is responsible — the analyst who configured the agent's prompt, the vendor who built the model, the manager who approved deployment, or the executive who signed the report? Regulators and auditors do not accept 'the AI did it' as a defense. Under SOX, certification officers remain personally liable for the accuracy of reported figures regardless of how they were produced. This means the human accountability chain must be preserved even as execution becomes automated. Companies that treat the agent as a black box outside their control framework typically discover the gap during their first audit cycle after deployment — often 12 to 18 months in, when remediation costs and delayed sign-offs far exceed what upfront control design would have cost.

The Four-Layer Control Model for FP&A Agents

A practical approach organizes SoD for agentic FP&A into four layers. Layer one is identity: the agent should have its own distinct service identity in your IdP (Okta, Entra ID, or equivalent), never share credentials with humans, and never hold interactive login rights. Layer two is permission scoping: the agent's roles should be least-privilege by default — read access to source data, write access only to designated staging areas or draft objects, and no direct write access to approved budgets, actuals, or the general ledger unless a specific, documented business case exists.

Layer three is workflow enforcement: any consequential action the agent proposes should route through a human approval gate before it commits. Modern platforms implement this as a proposal-then-approve pattern, where the agent prepares a reforecast or budget adjustment and a named approver accepts, rejects, or amends it, with the full decision trail retained. Layer four is independent monitoring: a separate logging and alerting function — ideally owned by someone other than the agent's administrator — reviews agent activity for anomalies such as out-of-pattern adjustments, access to restricted cost centers, or changes to the agent's own configuration. The critical design rule across all four layers: the person who configures or administers the agent should not be the person who approves its outputs. That single separation prevents the most common failure mode, where an over-enthusiastic builder quietly widens the agent's permissions and approves its own work.

Comparing Control Approaches: Human-in-the-Loop vs. Policy-Gated Autonomy

Organizations deploying FP&A agents generally choose between two operating models, and the right answer depends on materiality, audit posture, and trust maturity.

Most mature deployments use a hybrid: HITL for anything touching approved numbers or external reporting, and policy-gated autonomy for high-volume, low-materiality work like refreshing rolling forecasts or flagging variances. A reasonable starting threshold used by mid-market teams is to require human approval for any single adjustment above $50,000 or 2% of a cost center's annual budget, while letting the agent act freely below those lines with full logging. Whatever thresholds you choose, document them explicitly and review them quarterly — unreviewed thresholds drift upward as teams get comfortable, which is precisely when errors compound.

Practical Implementation Steps

Begin with an access inventory. Before the agent goes live, list every system it touches, every credential it uses, and every object it can read or write. Map each against your existing SoD matrix and flag conflicts — for example, an agent that can both modify driver assumptions and publish the resulting forecast represents a conflict that needs a workflow gate. Second, define the approval matrix in writing: which actions are autonomous, which need one approver, which need two, and what dollar or percentage thresholds trigger escalation. Third, configure immutable logging. Every agent action should capture timestamp, input data snapshot, model version, prompt or rule version, proposed change, approver identity, and final outcome. Retain these logs for at least seven years if you are SOX-relevant, matching your financial record retention policy.

Fourth, run a parallel period. For one to two full planning cycles (typically one to three months), run the agent alongside the manual process and reconcile outputs. Discrepancies here reveal both model weaknesses and control gaps before they matter. Fifth, establish a quarterly access recertification where the agent's owner, an independent reviewer, and internal audit jointly confirm that permissions still match the documented matrix. Sixth, test the controls like any other key control: walkthroughs, sample testing of approval trails, and exception reports. Treat the agent as a third-party application in your SOC 2 or SOX scoping exercise rather than an exempt tool — auditors in 2026 expect this and will ask.

Common Mistakes That Create Audit Findings

The most frequent error is granting the agent's integration account excessive privileges 'temporarily' during implementation and never revoking them. Six months later, nobody remembers the account has GL write access. The second common mistake is allowing the agent's builder to also serve as its approver, collapsing the very separation you deployed the agent to improve. Third is neglecting configuration change control: if prompts, rules, or model versions can be edited without version history and approval, then the effective behavior of your agent can change silently between audits, invalidating prior testing. Fourth is ignoring downstream consumers — if executives make decisions based on agent-generated commentary that no human reviewed, your control framework has a hole regardless of how well the underlying numbers were governed. Fifth is treating vendor assurances as sufficient; a vendor's SOC 2 report covers their environment, not your configuration of their product inside yours. Finally, many teams skip training for approvers, who then rubber-stamp agent proposals they do not understand. An approval that is not informed is not a control; it is theater.

Cost Considerations and Resource Requirements

Budgeting for SoD around an FP&A agent involves more than the SaaS subscription. Expect implementation effort of 60 to 120 hours for a mid-sized team: access inventory and role design (20–40 hours), workflow and threshold configuration (15–25 hours), logging integration (15–30 hours), documentation and policy writing (10–15 hours), and training (5–10 hours). Ongoing costs include quarterly recertification (roughly 8–12 hours per quarter of combined staff time) and annual audit support, which typically adds 20–40 hours of preparation in year one and less thereafter. If you lack an internal IT security or GRC function, engaging a consultant for the initial control design commonly runs $10,000 to $30,000 depending on complexity. Compare this against the alternative: remediating a failed audit finding, including extended fieldwork, restatement risk assessment, and management time, routinely costs multiples of the upfront investment and delays close cycles by days to weeks. The economics favor designing controls first.

When to Act and How to Prioritize

If you already run an FP&A agent without formal SoD controls, act now rather than waiting for the next audit cycle. Prioritize in this order: first, revoke any shared or overly broad credentials this week — this is a one-day fix with outsized risk reduction. Second, implement approval gates on any agent action that writes to approved budgets, forecasts of record, or systems feeding external reporting, ideally within 30 days. Third, stand up immutable logging within 60 days, since retroactive log reconstruction is nearly impossible. Fourth, complete the written approval matrix and quarterly recertification process within one quarter. Teams planning a new deployment should build these controls into the implementation plan from day one; retrofitting controls onto a live agent takes roughly twice the effort and creates a window of ungoverned activity that auditors will probe. The organizations getting the most value from agentic FP&A in 2026 are not those with the most autonomous agents, but those whose autonomy is bounded by clear, tested, independently monitored controls — the same discipline that made traditional finance functions trustworthy, applied to a new class of worker.