Security reviews of AI projects tend to focus on the model, which is usually the least interesting part of the risk. The model has no credentials and no network path to anything. The risk lives in the layer between the model and your ledger.

This page is organised by the questions a reviewer asks, so it doubles as a checklist you can take into the architecture session.

Identity
Least Privilege
Network
Data Handling
Approvals
Audit Trail
Incident Response

Identity: Whose Permissions Apply

Everything else rests on this. JD Edwards has a mature role and environment security model, and the single most consequential design decision is whether the agent operates inside it or beside it.

Because AIS sessions carry username, environment and role, an agent can inherit the requesting user's entitlements. The alternative, a single powerful service account used for everyone, is easier to build and destroys the meaning of your audit trail.

Session per user: Where identity design allows, the session belongs to the person asking, so visibility follows existing roles.
Scoped service identity: Where unavoidable, scoped tightly to specific orchestrations and companies, never reused across purposes.
No database accounts: Direct database credentials bypass the security model entirely and should not exist in this design.
Environment separation: Distinct identities for test and production so an experiment cannot reach the live ledger.
ChatFin connects to JD Edwards and your wider ERP stack as the AI layer on top

Governance is what makes finance say yes

Finance leaders hesitate on AI because they carry the consequences if it goes wrong. Clear identity rules answer that worry directly.

Some people, instead of seeing possibility, come from a place of fear. I'm going to be responsible, so I need to control it.

Caitlin Haberberger, on the AgentCFO podcast

When an agent can only see what the requesting user can see, the controller's existing controls still hold. That is usually the point where resistance turns into approval.

Least Privilege as Capability, Not Instruction

A control that depends on the agent choosing not to do something is not a control. The design principle is that most actions are impossible rather than discouraged.

The mechanism is an explicit whitelist of orchestrations the agent may call. Anything absent cannot be invoked regardless of what the model proposes, and the whitelist is short enough for a reviewer to read in one sitting.

Explicit whitelist: Named orchestrations, reviewable on one page, with change control around additions.
Read and write separated: Distinct identities and distinct whitelists, so analytical access has no path to posting.
Value thresholds: Limits on what may be proposed automatically, by amount, account and supplier.
Scope exclusions: Sensitive areas such as payroll placed entirely out of reach.

Network and Secrets

Placement matters more than product choice here, and the constraints are conventional. The AIS Server is an internal service and should remain one under every deployment option.

Never public: The AIS Server should not be reachable from the public internet, in any configuration.
Gateway in front: A single controlled entry point handling authentication, rate limiting, payload inspection and independent logging.
Encryption throughout: Current transport security including between the gateway and the AIS Server, not only at the outer edge.
Secrets managed: Credentials in a secrets manager with rotation, never in configuration files or orchestration definitions.
AI first architecture connecting agents to an ERP

Data Handling and Privacy

This is a policy question before it is a technical one, and it should be settled early because it constrains the architecture.

Decide what may leave your boundary, under what terms, and with what retention. Ledger content is commercially sensitive and frequently contains personal data in supplier and customer records, which brings privacy obligations alongside the commercial ones.

What leaves: Whether ledger content may reach an external model service, and if so which fields.
Retention terms: Whether the provider retains inputs, for how long, and whether they are used for training.
Personal data: Supplier and customer records frequently contain it, which brings privacy obligations into scope.
Minimisation: Send the least necessary. Aggregating at source rather than shipping rows is a privacy control as well as a performance one.

Approvals as the Primary Control

For anything that writes, human approval is the control that makes the rest defensible. It is the point at which accountability attaches to a named person.

The design requirement is that it cannot be bypassed, that the approver sees the full proposal and its evidence rather than a summary, and that thresholds follow your existing authority design rather than a parallel one invented for the agent.

Enforced: No configuration path that allows posting without a named approver.
Full evidence: The approver sees the source rows, not a description of them.
Existing authority: Thresholds mirror your current delegation design rather than creating a new one.
Segregation preserved: The agent operates within one user's role and cannot both raise and approve.

"A control that relies on the agent choosing not to do something is not a control. It is a hope with a policy document attached."

Checklist split between automated steps and human judgement

The Audit Record

The record should be a by product of doing the work rather than an exercise performed afterwards, and it should contain enough that a reviewer two years later can reconstruct what happened without asking anyone.

The request: What was asked, by whom, when.
The evidence: Which rows and documents were read, retained.
The proposal: The exact payload presented for approval, before any edit.
The decision: Approver, timestamp, modifications and the resulting document and batch number.

Incident Response

Reviewers will ask what happens when something goes wrong, and the answer should be specific.

There should be a defined reversal route with its own approval, a way to suspend the agent immediately without touching JD Edwards, and a record complete enough to determine scope quickly.

Immediate suspension: A way to stop the agent acting without changes inside the ERP.
Defined reversal: A documented route to void or reverse anything approved in error, with its own approval.
Scope determination: Logs complete enough to establish what was affected.
Root cause: Whether the failure was data, configuration, model behaviour or an approval gap.
From question to routed, approved transaction

Design for the Review Before You Build

ChatFin operates inside your existing JD Edwards role design, calls only whitelisted orchestrations, keeps read and write access structurally separate, enforces named approval on every posting, and produces the audit record automatically.

Auditors do not ask whether the AI was accurate. They ask who could do what, how it is evidenced, and how you would undo it.

Book a Demo

Frequently Asked Questions

What is the most important security decision for JD Edwards AI agents?

Identity. Everything else rests on whether the agent operates inside your existing role and environment model or beside it. AIS sessions carry username, environment and role, so an agent can inherit the requesting user's entitlements. A single powerful service account used for everyone is easier to build and destroys the meaning of your audit trail, because every action is attributed to the same identity.

How is least privilege enforced in practice?

Through an explicit whitelist of orchestrations the agent may call, short enough for a reviewer to read in one sitting and subject to change control. Anything absent cannot be invoked regardless of what the model proposes. Read and write access should use distinct identities and distinct whitelists, so an analytical path has no route to posting, with value thresholds and scope exclusions on top.

What should the audit record contain?

Four things, captured automatically as a by product of the work rather than assembled afterwards: the original request and who made it, the rows and documents read retained rather than referenced, the exact proposal presented for approval before any edit, and the approval decision including approver, timestamp, modifications and the resulting document and batch number.

Related Articles

Access JD Edwards Without Exposing Credentials
Role Based Access, Approvals, Limits and Audit Logs
Prevent Unauthorised AI Transactions in JD Edwards
Top 10 AI Tools for Internal Audit and Risk