Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

What Stops an AI Agent From Changing Financial Records Without Authorization?

Separation of duties, applied to the agent as it is applied to staff: the agent prepares the entry, a named person with posting authority commits it, and the record attributes every step to whoever took it. Check that no posting path lets the agent both prepare and commit, and that one entry can be reconstructed from the record.

A prepared financial record passes through an authorization gateway before joining the final posting ledger.

Separation of duties, applied to the agent as it is applied to staff: the agent prepares the entry, a named person with posting authority commits it, and the record attributes every step to whoever took it. Check that no posting path lets the agent both prepare and commit, and that one entry can be reconstructed from the record. Financial controls have an old answer to this question, and it is not to trust the actor. It is to split the work so that preparing and committing are done by different parties, and to keep a record that shows who did which. Agents fit into that design without altering it, as long as the organization resists two temptations: letting the agent commit because it is fast, and letting the agent act under a credential that hides which actor did what. FINRA's 2026 oversight report warns that agents may exceed their intended authority and that agent action chains may be hard to reconstruct, and reconstruction is the auditor's whole method. This page explains why separation of duties is the right control for agents, how it maps onto the preparer and approver roles, what it looks like on a single journal entry, how the record must attribute each step, how to test the arrangement, and which claims a buyer should not accept.

Key findings

  • FINRA's 2026 Regulatory Oversight Report, as summarized by Debevoise & Plimpton, warns that agents "may take actions that exceed the user's actual or intended scope or authority" and that agent chains "may be difficult to reconstruct, complicating auditability" (Debevoise & Plimpton, 2025).
  • Separation of duties, least privilege and audit record generation are established controls in the federal catalog, defined for any acting identity and not limited to human users (NIST, 2020).
  • Unintended agent actions are reported by 80% of organizations in a SailPoint survey of 353 IT professionals, with about 40% reporting access to unintended systems (CFO Dive, 2025).
  • The OWASP Top 10 for LLM Applications classifies the underlying risk as Excessive Agency, in which an agent's permissions and autonomy exceed what the task requires (OWASP, 2025).
  • Human approval before consequential action is "a standard way to limit egregious failures," and "at least one human entity is accountable for every uncompensated direct harm" (OpenAI, 2023).
  • Platform vendors now document approval flows that route decisions to "different human stakeholders at various stages of the process," which is the mechanism a preparer and approver split needs (Microsoft Learn, 2026).

Why is separation of duties the right control for an agent?

Separation of duties exists because no single actor should be able to initiate, approve and record a financial change alone. The control does not ask whether the actor is trustworthy; it assumes the actor may be wrong, compromised or dishonest and arranges the work so that a second party must concur. That assumption fits agents better than it fits most people. An agent can be wrong through model error, compromised through content it reads, and it cannot be dishonest in the human sense but can be made to act as if it were. The NIST control catalog defines separation of duties as a control on the organization's assignment of responsibilities, and nothing in that definition depends on the responsible party being a person (NIST, 2020).

The alternative controls are weaker for a reason the record already shows. Instructing the agent not to post without approval is a request to the component most likely to fail. Restricting the agent to read-only access removes its usefulness for the preparation work that is most of the job. Separation of duties keeps the agent useful, preparing entries, matching documents and drafting adjustments, while making the commit a human act.

The regulatory framing confirms the fit. FINRA's concern that agents may exceed their intended scope is a concern about an actor doing more than its role, and the concern that agent chains are hard to reconstruct is a concern about the record (Debevoise & Plimpton, 2025). Separation of duties addresses the first by bounding the agent's role to preparation, and an attributed record addresses the second.

How do the preparer and approver roles map onto an agent workflow?

In a conventional finance team the preparer drafts the entry and the approver, who holds posting authority for that ledger or account range, reviews and posts it. The agent takes the preparer role and only that role. The approver remains a named person who holds the authority today.

Step Human-only process Agent-assisted process Who is attributed in the record
Gather support Accountant pulls invoices, statements, contracts Agent reads the source screens, with identifiers as tokens Agent identity and task
Draft the entry Accountant drafts debit and credit lines Agent drafts the lines and the memo Agent identity
Review Approver checks support against entry Approver sees the same screens the agent saw Approver, named
Post Approver posts Approver approves; the environment commits Approver, with time of commit
Record System log shows the posting user Record joins agent preparation, approval and commit Both, in one entry

Two features of the table matter. First, there is no row in which the agent commits. If an agent is permitted to post entries under a threshold, the organization has created a path on which one actor both prepares and commits, and that path is where the FINRA concern about exceeding authority becomes real. After-the-fact review is acceptable only where actions are "more easily reversible," and a posted entry is reversible only by another entry an auditor will see (OpenAI, 2023). Second, the approver sees what the agent saw. An approval of the agent's summary of the support is not a review of the support. Multistage approval mechanisms, as some platforms document, can carry the routing, provided what is routed is the screen rather than a paraphrase (Microsoft Learn, 2026).

What does the control look like on a single journal entry?

Take a manual journal entry record in a general ledger. The record shows the entry number, the period, the debit and credit lines with account codes and amounts, a memo, the supporting document references and a post button. An agent's task is month-end accrual: find invoices received after the cutoff for services delivered before it, and prepare the accrual entries.

The agent works through the accounts payable screens. Vendor identifiers and bank details appear to it as tokens; it does not need the real values to identify an invoice dated after the cutoff for a service dated before it. It drafts an accrual entry: debit the expense account, credit accrued liabilities, memo referencing the invoice, support attached. It prepares a dozen such entries.

The entries route to the accounting manager who holds posting authority for the period. The manager sees each entry with the supporting screens exactly as the agent saw them, tokens included, and approves or sends back. On approval the environment posts the entry. The record for each entry shows the agent identity that prepared it, the task, the screens it read, the manager's identity and decision, and the time of posting.

Now introduce a fault. A vendor invoice the agent reads contains text, planted or accidental, instructing it to also record a credit to a particular account. The agent may draft that entry. It cannot post it, because the agent has no posting path. The manager sees an accrual with no service to support it and sends it back. The fault produced a declined draft, not a changed ledger, and the record shows the attempt. A posting path the agent does not have is one it cannot take, whatever unintended systems it reaches (CFO Dive, 2025).

How must the record attribute each step so an auditor can reconstruct it?

Reconstruction is the method by which an auditor or a regulator establishes what happened. For a journal entry it means being able to answer, from the record alone: who prepared this, from what support, who approved it, what did they see, and when was it posted. FINRA's observation that agent chains may be hard to reconstruct is a warning that agents, deployed carelessly, break that method (Debevoise & Plimpton, 2025).

Three practices preserve it. The agent acts under an identity that is distinguishable in the record from any human and from any other automation, so that "prepared by" names the agent rather than a shared service account. The approval and the commit are written to the same record as the preparation, joined by the entry identifier, so that the chain is one entry rather than a reconstruction across a ticketing tool, an agent log and a ledger audit table. And the screens the agent read are preserved as it read them, with tokens in place of sensitive identifiers, so that the auditor can see the support without the record becoming another store of account data. The NIST catalog's audit and accountability controls describe the content an audit record needs and the protection it requires, and those controls apply to agent-generated records as they do to any other (NIST, 2020).

The record also has to survive a change of model. An organization that replaces the model behind its agent next year should find that the preparer and approver split, and the record of it, are unchanged, because the controls were never inside the model. Export of the record to the organization's SIEM puts agent-prepared entries beside human ones in the same investigations.

How should an organization test that the ledger cannot be changed alone?

Test for the existence of a solo posting path first. From the ledger's own access configuration, list every identity that can post, and confirm the agent's identity is not among them. Then check for indirect paths: an integration user the agent can invoke, a scheduled job it can trigger, a threshold below which posting is automatic. Any of these is a path on which the agent both prepares and commits. The OWASP description of Excessive Agency is a useful checklist here, because it separates excess function, excess permission and excess autonomy, and a solo posting path can arise from any of the three (OWASP, 2025).

Test the approver's view second. Approve an agent-prepared entry in a pilot and confirm that the approver saw the supporting screens and not a summary written by the agent. Then plant a discrepancy between the support and the entry, an amount that does not match the invoice, and confirm the approver's screen makes it visible.

Test reconstruction third. A week after the pilot, pick one posted entry and ask for the full chain: preparer, support as read, approver, decision, time. Measure how long it took. Insurance regulators have adopted the NAIC's model bulletin on insurers' use of AI systems across many states, and that bulletin expects documented governance of AI systems that an examiner can review; a reconstruction that takes a day is not examinable governance (NAIC, 2025). The Safeguards Rule's requirement for an information security program with accountable ownership points the same way for financial institutions (16 CFR Part 314). These tests are the minimum before an agent touches a ledger.

What does a governed environment change?

A governed environment enforces the preparer and approver split outside the model: the agent prepares an entry on tokens, a named person with posting authority commits it, and the record attributes both steps in one place. Run directly in the ledger application, the agent holds real account identifiers during preparation and can reach the posting path with its identity's rights; in the environment, it holds neither.

This class of control works at the rendered screen. Bank account numbers and vendor identifiers on the entry are replaced with consistent tokens before any model reads the page, and matching and preparation run on tokens. Real values resolve only at the approved destination at the moment the approved posting executes. A named person confirms what is tokenized and approves consequential actions such as payments, submissions and record changes. Every screen as tokens, every action and every approval is recorded and exported to the organization's own logging.

This answers the two points the previous section pressed. First, no posting path exists on which the agent commits alone, whatever the entry's value, because the commit requires an approval the agent cannot supply; this is separation of duties as the federal catalog defines it for any acting identity (NIST, 2020). Second, the exported record is the full chain for one entry, naming the agent as preparer and the person as approver, with the screens the agent read, the reconstruction FINRA's report warns agent chains may complicate (Debevoise & Plimpton, 2025).

The control does not alter the ledger application, the user's posting authority or the model, and it does not replace the ledger's own audit table; it adds the attribution that table lacks.

Where does RedactSure sit?

The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company. The design implements the preparer and approver split as an enforced property of the environment. The agent works in a governed environment in the customer's cloud, under the user's existing permissions, which are left unchanged. Substitution happens at the render layer before any model reads the screen, so account identifiers and vendor details appear to the model as consistent tokens such as ACCT_001 or PATIENT_001 for the whole run, and real values resolve only at approved destinations at the moment of an approved action. A named person confirms the tokenization policy and approves every payment, submission and record change, the arrangement the design calls Supervised Delegation; the agent prepares, the person with posting authority commits. Every screen as tokens, every action and every approval lands in the AI Control Record and exports to the customer's SIEM, so a posted entry's chain is one record. The design is model agnostic and requires no per-application integration.

Deployments are in pilot. A pilot on the reader's own close process would show, for this question, each entry the agent prepared, the screens it read, who approved each one and what they saw, the time of posting, and whether any path existed on which the agent committed alone. Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

This page rests on NIST Special Publication 800-53 Revision 5 (2020) for the definitions of separation of duties, least privilege and audit controls; a law firm summary by Debevoise & Plimpton of FINRA's 2026 Regulatory Oversight Report (December 2025); Microsoft documentation on multistage approvals in Copilot Studio agent flows (updated June 2026); the FTC Safeguards Rule at 16 CFR Part 314; OpenAI's whitepaper on practices for governing agentic AI systems (2023); press coverage of a SailPoint survey of 353 IT professionals (CFO Dive, June 2025); the OWASP Top 10 for LLM Applications entry on Excessive Agency (2025); and the NAIC's adoption map for its model bulletin on insurers' use of AI systems (2025). All sources were read as of October 16, 2026. The mapping of agent and human roles onto the preparer and approver split is this page's synthesis.

No hands-on testing of any product was performed. FINRA's report is described through the law firm summary cited, not from the report itself. Vendor documentation is described from the pages reviewed, and "not described" means not described in those pages; vendor features change, and the page carries its date. Survey figures are self-reported. Statements about RedactSure describe current design, with deployments in pilot. The journal entry record and the accrual task describe a record type and a task shape, not any organization.

Whether a given agent workflow satisfies an organization's internal control framework, its external auditor's expectations or the requirements of FINRA, state insurance regulators or the Safeguards Rule is a determination for its counsel, its auditors and its own finance, security and compliance officers, not for a research page.

What the record shows

Financial control already contains the answer to this question, and the agent literature confirms it from the other side. Separation of duties was designed for actors who might be wrong or compromised, which describes an agent well, and it keeps the agent useful while making the commit a human act. The regulator's two concerns, exceeded authority and unreconstructable chains, map onto the two halves of the control. The survey evidence that most organizations have seen unintended agent actions is the reason not to leave a solo posting path open, however small the threshold. Supervised Delegation, in which the agent prepares and a named person with posting authority commits, is one implementation of the split. The test is to name one agent and one ledger and ask: is there any path on which this agent can post an entry alone, and can you show me the full chain for the last entry it prepared?

Frequently asked questions

Can an agent be allowed to post small entries automatically?

It should not. A threshold bounds the size of each unauthorized change but preserves the path on which one actor both prepares and commits, which is the condition separation of duties exists to prevent. Ledger fraud and error accumulate through many small entries, and an auditor who finds a solo posting path will treat it as a control gap regardless of its ceiling. The agent prepares entries of any size; a named person with posting authority commits them.

Why is separation of duties better than instructing the agent not to post?

Because an instruction is a request to the component most likely to fail. Model error and injected content both produce actions the instruction forbade. Separation of duties does not depend on the agent's compliance: it removes the posting path from the agent's identity and places the commit with a person. The control was designed for actors who might be wrong or compromised, and it works the same way whether the preparer is a junior accountant or an agent.

What does FINRA say about AI agents?

According to Debevoise & Plimpton's summary of FINRA's 2026 Regulatory Oversight Report, FINRA warns that agents may take actions exceeding the user's actual or intended scope or authority, and that chains of agent actions may be difficult to reconstruct, complicating auditability. Those two concerns correspond to the two halves of the control described here: a bounded preparer role, so the agent cannot exceed its authority by posting, and an attributed record, so the chain can be reconstructed.

How should the agent appear in the audit record?

Under its own identity, distinguishable from every human user and from other automation, so that "prepared by" names the agent rather than a shared service account. The preparation, the approval and the commit should be joined in one record by the entry identifier, with the screens the agent read preserved as it read them, identifiers as tokens. An auditor should be able to pull one entry and read the whole chain in one place rather than assembling it from three systems.

Does the approver need to see the real account numbers?

No. The approver confirms that the entry matches its support by comparing the screens the agent read, and consistent tokens are enough to establish that the same vendor or account appears in both. Real values resolve only at the approved destination when an approved action, such as a payment, executes. Keeping real identifiers off the approval screen and out of the record means the control does not create new copies of account data for an attacker to find.

What happens to these controls when the model changes?

Nothing, if they were built outside the model. The preparer and approver split is a property of which identities can post, and the record is a property of the environment that captures preparation, approval and commit. A new model drafts entries differently and may be more or less accurate, but it still has no posting path and its work is still recorded. Controls that were implemented as instructions to the model, by contrast, have to be re-established and re-tested each time the model changes.

Book an AI Agent Security Review →

Bring your hardest questions.

Bring one sensitive workflow and the decisions your team needs to keep in its hands.

Book a demo

About the author

Christopher Sowa
Chris SowaCo-Founder, President and Chief Commercial Officer, RedactSure

Chris Sowa is a founder of RedactSure and a former CEO of an AI company; he started it years before ChatGPT existed. He previously led AI at Accenture, served as Global VP of Strategy & Innovation at Schneider Electric, was CCO of Sovos, and spent more than a decade at Oracle, with earlier roles at SAP and IBM.

Book a demo

Book a demo

Having trouble? Open the booking page or email us.