Secure AI Agent Integration: Engineering Hours by ERP
Scope: GL read + write-back + audit log + rollback · mid-market implementation
usedel.ai · Figures in USD thousands
Disclosure and status: del.ai is a pre-revenue company founded in May 2026. We build AI agents for Odoo ERP and have a direct commercial interest in the argument below. This article is a design document, not a product tour. It describes the permission model, audit structure and approval routing we are building and intend to ship with migrations. It has no customer deployments behind it, no audited controls, and no incident history. Where we say "the design", we mean design. Where something is not built, we say so.
Yes, del.ai agents are being built to touch your general ledger. That is not a bug; it is the only reason they would be worth running. And knowing how to control AI agents in ERP finance — specifically which actions should be gated at the architecture level, which should require human sign-off, and which should never auto-execute — is the right question to ask before any agent gets near your books.
This article answers that question directly. Not with reassurances. With the permission model, the audit log structure and the rollback mechanics we are designing: the way you would want them explained to your Controller before a board meeting, or walked through with your SOX auditor.
The short version of the design: agents operate inside a four-class permission taxonomy enforced at the substrate, not by the model. MONEY-MOVE class actions — journal entries, cash movements, payment approvals — cannot execute without a named human in the approval chain. Everything is logged with full pre- and post-action state. Rollback is a designed property of each action rather than a recovery procedure.
That is the architecture we are building toward. The rest of this article is the detail behind each layer, and an honest line under each one about what exists today.
One bad journal entry on a live GL is not an inconvenience. It is a potential SOX violation, a cash impact, and a reputational event for the company and for whoever approved the system that caused it. CFOs and Controllers who have lived through a manual journal entry error know what the downstream looks like: auditors asking for narrative explanations, reconciliation work that surfaces at the worst moment in the quarter, and the uncomfortable conversation about how it happened.
An AI agent with GL write access raises that fear to a different magnitude. The volume of potential actions is higher. The speed is higher. And the governance frameworks most companies have built for human GL access were not designed with autonomous agent actions in mind.
The problem with most AI governance framing is that it operates at the policy layer: the model is instructed not to do harmful things. Instructions can be misread, misrouted, or hallucinated past. Policy-layer governance is not sufficient for GL access.
The fear is especially acute because most AI pilots treat governance as a post-shipment concern. The capability ships first; the guardrails come later, usually after a near-miss or an actual incident. From a CFO's seat, that order is backwards, and the fear is correct. It is also the reason we are publishing the design before the product rather than after: an architecture you can argue with beats a reassurance you cannot check.
The control we are building is a four-class permission taxonomy enforced at the substrate level rather than by model instruction. ERP AI agent permissions are designed to work this way because a model cannot reason or hallucinate its way past a gate that sits below it — if the action class is MONEY-MOVE, the gate does not open until a human unlocks it. The table below sets out what each class is scoped to permit and where human sign-off is required.
| Action Class | What agents are scoped to do | Human approval required |
|---|---|---|
| READ | Access trial balances, AR aging, variance data, with zero mutation risk | No |
| WRITE | Post cost-center tags, update classification codes, scoped to approved field set, reversible | No (reversible) |
| SCHEMA-MOD | Propose new GL account, reorganize chart of accounts | Yes (CFO/CIO) |
| MONEY-MOVE | Post journal entries, move cash, approve payments | Yes (mandatory) |
What matters here is the enforcement layer. Most AI safety framing tells the model what it should not do. An action-class model makes a subset of actions mechanically unavailable. A MONEY-MOVE is not "discouraged" or "flagged for review if the model chooses to surface it": the action does not execute. There is no prompt engineering that changes this, because the gate does not read prompts.
This distinction between policy governance and substrate enforcement is the gap between a system that is "designed to be careful" and one that is architecturally constrained. The difference matters at 2am on the last day of quarter close — which is exactly why we would rather be judged on whether the gate is real than on whether the model sounds cautious.
An action-class permission gate prevents unauthorized general ledger changes by moving enforcement out of the model and into the substrate the model has to write through. Most AI safety approaches operate at the policy layer: the model is told what not to do, and a misread or hallucinated instruction can slip past that instruction. The taxonomy del.ai is designing instead makes a subset of actions mechanically unavailable before the model's output can produce any system effect. READ, WRITE and SCHEMA-MOD scale from read-only access up through CFO-approved structural changes, while MONEY-MOVE, meaning any journal entry, cash movement or payment approval, stays blocked until a named human approves that specific action instance. No prompt or framing unlocks a MONEY-MOVE action without a human approval token attached to it, because the gate never reads the prompt. The architectural point: a policy-governed model can be argued with, and a substrate-gated action cannot execute regardless of what the model outputs. This is a design specification, not an audited control.
Source: del.ai product design scope definition, 2026
An agent audit log built for a finance audience should capture, for every action, the agent identifier, the action class, the operation executed, a timestamp, the general ledger state before and after, and, for money-movement class actions, the full approval chain including the approver's identity and decision timestamp. That is the structure del.ai is designing toward: a compliance artifact rather than a raw developer debug stream. State versioning means a snapshot of the relevant accounts exists on both sides of every action, so a reviewer can reconstruct the history of an account without relying on memory or narrative. If an agent action is later found incorrect, the reversal should be logged with the same structure as the original, so corrections are documented as thoroughly as the entries they correct. None of this has yet been tested against a real audit, and no auditor has attested to it. Treat it as the specification we intend to be held to.
Source: del.ai product design scope definition, 2026
When an auditor asks what happened to a specific GL account on a specific date, the answer should be a structured log entry with full state context, not "we think the Controller ran a journal entry last Tuesday." Because the log is designed to capture pre-action state, an auditor should be able to verify not just what happened but what the account looked like before it happened.
Migration also raises a question we would rather answer plainly than gloss: what happens to the existing NetSuite audit trail. The plan is a parallel-run period that preserves it, so the first audit cycle after go-live is signed off against records that already exist, and the Odoo trail carries the following cycle. We have not yet run this with a customer, and re-attestation scope is a thing to negotiate with your audit firm rather than something a vendor can promise on their behalf.
The trigger should be the action class itself: any operation that posts a journal entry, moves cash or approves a payment is queued and cannot execute until a named human approves it. The agent does not retry, escalate or find an alternate path around the gate; it waits. When the action reaches the approval interface, the Controller or CFO should see the proposed entry, the agent's stated reasoning, the pre-action ledger state, and a single approve-or-reject control. In the design del.ai is building, approval is mandatory for an initial supervised period regardless of how confident the agent is in its own output, and any later auto-approval is unlocked deliberately by the CFO for one specific low-risk action sub-type at a time rather than granted by default. Rejections feed back as labelled signal. The important property is mechanical rather than procedural: theoretical human-in-loop is a policy, and operational human-in-loop is an action that physically cannot execute without a recorded human token.
Source: del.ai product design scope definition, 2026
A supervised period at the start is deliberate. It gives the CFO and Controller a full month-end close cycle to observe agent behaviour on money-movement actions before any auto-approval configuration becomes available at all. Trust thresholds are designed to be off by default and unlocked by the CFO, for specific action sub-types, after observable evidence of correct behaviour on that action type.
Consider what that is meant to look like in practice. A month-end close agent identifies a batch of accrual entries that need posting. Each is queued. The Controller reviews them in a single session — proposed entry, agent reasoning, pre-state — and approves or rejects. Only after a run of identical postings has been approved without modification can the CFO choose to configure auto-approval for that specific pattern, and only that pattern; a journal entry of a different type still queues. Whether that graduation curve is the right one is exactly the kind of thing we expect a first cohort of finance teams to push back on.
This is the section where most vendor content, including some we have published before, gets the facts wrong in our own favour. So here is the correction first.
It can write. Oracle's MCP Standard Tools SuiteApp ships tools named ns_createRecord and ns_updateRecord, documented as creating and updating records in NetSuite through SuiteTalk REST web services, and SuiteTalk REST is itself a full create, read, update and delete interface. Any claim that NetSuite's API is read-only, or that agents on NetSuite can query but never act, is wrong and should be discounted wherever you read it, including in earlier versions of this page. The real constraints are narrower and still material. The agent acts through a curated tool surface Oracle defines and versions, under the role permissions of whoever authorised the connection. It shares your account's integration concurrency limit with every other integration, so it can be throttled mid-task. The SuiteQL tool is documented as supporting read-only queries only. You cannot extend the schema, and you do not hold the codebase. The ceiling is set by the vendor's release, not by your own permission model.
Source: Oracle, "Available Tools in the MCP Standard Tools SuiteApp" and "Overview of SuiteTalk REST Web Services," NetSuite Help Center documentation, 2026.
That correction matters more than the argument it weakens, so state the remaining argument narrowly.
On an owned Odoo instance — open schema, source code you hold — the ceiling on what an agent can reach is the database and the codebase, and the permission model is one your CFO configures rather than one a vendor ships. On NetSuite, the ceiling is the tool surface Oracle exposes in a given release, and the governance you get is the role model NetSuite already has. Both are real governance. They differ in who sets it and how far it can be extended.
That is the whole of the comparison we are willing to defend. "The vendor won't let agents act" was never true and is now demonstrably false. "The vendor decides the action space and you cannot extend it" is true, checkable in Oracle's own documentation, and is the reason schema ownership changes what a governance layer can be built out of in the first place.
Safety is not the absence of capability. Safety is the governance of capability — which is also why an owned platform raises the stakes rather than lowering them. On an ERP where agents have real write access to the source of record, you need real AI agent ERP guardrails, and building them is our obligation, not a bonus.
The permission model and the human-in-loop gate are designed to prevent most problems. Rollback is designed to handle the remainder.
The intent is that every agent action producing a state change also produces a pre-action snapshot retained as part of the log. Reversing a WRITE-class action then means restoring the pre-action state, logging the reversal with the same structure as the original action, and recording who initiated it.
Money-movement reversals are designed to take longer, because the reversal itself routes through the approval gate. The CFO or Controller approves the reversal, and that approval is logged. The result should be a clean trail: original action, pre-state, post-state, reversal action, reversal approval — rather than a narrative explanation of what happened.
Compare that with manual journal entry error recovery in most ERPs, where standard practice is an adjusting entry that adds a second event to the trail rather than cleanly reversing the first. Treating each agent action as a discrete, documented, reversible transaction is the point: AI agents general ledger safety does not come from making agents cautious, it comes from making every action intrinsically reversible. We have not yet exercised this against a production ledger under audit, and until we have, this is a design property rather than a proven one.
Permission gates and audit logs address actions that execute correctly but should not have been queued. There is a second risk: the agent makes wrong inferences because the underlying data is ambiguous, and a correctly-executed wrong action reaches the approval queue with confident but incorrect reasoning.
Most AI-on-ERP failures trace back to data quality and ontology rather than model quality. A ten-year-old chart of accounts typically has an account like "Misc Expense - Ops 2", created by a Controller years ago to route a one-off cost, that has since absorbed everything from software subscriptions to travel reimbursements because nobody documented what it was for. An agent reading that account has no reliable way to infer what a new transaction posted against it represents; a human Controller resolves the ambiguity from memory, which does not transfer to an agent. Cost centres overlap, naming conventions shift across successive Controllers, and the semantic signal ends up too noisy for reliable machine inference.
A migration is one of the few moments when this gets rebuilt rather than patched. The chart of accounts can be restructured for machine consumption, cost centres disambiguated, account names standardised to an unambiguous schema, so that "AP Trade Payable - Manufacturing" maps to exactly one GL account with a defined balance type, currency and reporting group. That is the data-quality work that makes agents tractable on financial data. We have no revision-rate figures of our own to offer here: we have run no customer migrations, so any before-and-after error rate we published would be invented. If you see one from any vendor, ask how many ledgers it was measured on.
This is also why sequencing matters. Running agents on a dirty source system introduces exactly the ontology ambiguity that causes GL hallucinations, and then the human-in-loop gate becomes the only backstop rather than one layer among several.
Most AI failures on general ledger data trace to data quality and chart-of-accounts ontology rather than model capability. When accounts carry inconsistent names, cost centres overlap, and the chart has accumulated a decade of workaround additions from successive Controllers, the semantic signal is too ambiguous for reliable machine inference. The agent produces a wrong answer not because the model is weak but because the data structure makes disambiguation impossible at inference time, and it produces that answer with the same confidence it would bring to an unambiguous one. Gartner's analysis of generative AI project failures names poor data quality as one of the recurring causes, producing unreliable outputs and retrieval implementations that do not work. Rebuilding the chart of accounts for machine consumption during a migration is the structural fix: account names standardised, cost centres disambiguated, balance types and reporting groups defined per account, so an account name resolves to exactly one account rather than to a judgement call.
Source: Gartner, "Why Half of GenAI Projects Fail: Avoid These 5 Common Mistakes," 2025. ↗
In the design del.ai is building, rejecting a money-movement action cancels the proposed entry and logs the rejection with the same structure as an approval: agent identifier, action class, the specific operation proposed, the approver's identity, and the decision timestamp. No entry posts, and no retry happens without a new approval cycle started from scratch. The agent receives the rejection as labelled signal that feeds the pattern model for that action type, so repeated rejections on a given entry pattern should reduce how often that pattern gets queued in the same shape again. The rejection record belongs in the trail alongside approvals, so a reviewer sees not only what was approved but what was proposed and refused, with the reasoning the agent gave at the time. Nothing about a rejected money-movement action should ever reach the general ledger, because the block happens before any system effect rather than after one.
Source: del.ai product design scope definition, 2026
That is the intended default, and it is the configuration we expect most finance teams to start from. Read-class access is designed to be scoped per agent, limiting a specific agent to trial balance reads, AR aging queries and variance data with no write surface exposed at all, not even the reversible write class. The point of starting there is that a team gets to watch how an agent reasons about their own chart of accounts before granting it any ability to change anything. The design intent is that the CFO controls which action classes each agent can reach, and that those settings can be widened after deployment without re-architecture, so an agent can run read-only for a full quarter and then be granted write-class actions once its reasoning has earned that. Read-only agents should still produce the same structured log as agents with write access, so an observation-only period still leaves a record of what the agent would have proposed.
Source: del.ai product design scope definition, 2026
The safety architecture matters because the capability matters. A governance layer on an agent that cannot act is theatre.
If you are running NetSuite and evaluating whether AI can operate on your GL, do not accept the claim — from us or anyone — that it structurally cannot. Oracle's MCP tooling creates and updates records. The narrower and more useful questions are what action surface Oracle exposes in the release you are on, whether your concurrency limit lets an agent finish a batch, and whether you can extend any of it.
If what you want is agents operating on your GL with full auditability, human approval on financial transactions, and rollback on every state change, that needs an ERP where agents have write access to a schema you own, plus a permission model built to govern it. The four-class taxonomy, audit log, approval chain and per-step rollback described above are the design we are building. They are not shipped, audited, customer-tested controls, and we will say so on the call as plainly as we have said it here.
If you have not yet confirmed an agent can technically reach your ERP data at all, start with AI + ERP Integration for Mid-Market: What's Actually Possible, the feasibility layer underneath the governance model described here.
Built for CFOs and Controllers at mid-market companies on NetSuite spending $120k+/yr who want to interrogate an agent governance design before anyone builds it into their close.
30 minutes. We walk the action-class taxonomy against your actual GL structure and you tell us where it breaks. No pitch. Just the architecture.
Sources
1. Oracle, "Available Tools in the MCP Standard Tools SuiteApp," NetSuite Help Center documentation, 2026. ↗
2. Oracle, "Overview of SuiteTalk REST Web Services," NetSuite Applications Suite documentation, 2026. ↗
3. Oracle, "NetSuite AI Connector Service and Concurrency Governance," NetSuite Help Center documentation, 2026. ↗
4. Gartner, "Why Half of GenAI Projects Fail: Avoid These 5 Common Mistakes," 2025. ↗
5. Odoo S.A., "Year-end closing," Odoo 18.0 Accounting documentation, 2026. ↗
See how this works in the product