How to Build Secure AI Agents That Touch ERP, CRM, and Financial Systems

Most enterprise AI agent demos stop at read-only. The agent summarizes a Salesforce opportunity, drafts a NetSuite journal entry, suggests an SAP purchase requisition, and a human clicks approve. That is the easy version. The hard version is the one buyers are actually asking for: an agent that writes to the general ledger, updates master data, and closes tickets without a person in the loop for every call.

The security posture for that second version is different in kind, not degree. A read-only mistake is a bad answer. A write mistake is a journal entry, a refund, a canceled subscription, or a payment to the wrong vendor. And the auditor will ask who authorized it.

So how do you build an agent you would actually let near production financial systems?

Start With Identity, Not Prompts

The first design decision is not which model to use. It is which identity the agent runs as. Treating an agent as a non-human identity (NHI) with its own lifecycle is the ground floor, and it is where most teams are already behind. The OWASP NHI Top 10 lists excessive permissions as the single most prevalent vulnerability, and the 2026 Verizon DBIR flagged service and machine accounts as the identities most likely to be leveraged in an agentic future.

A clean pattern looks like this:

• One service account per agent per environment. No shared keys across agents, no reuse of a developer's OAuth session.
• Roles scoped to the smallest set of SAP t-codes, NetSuite permissions, or Salesforce profiles the agent genuinely needs. If the agent books AR cash receipts, it does not also get vendor master write.
• Separate identities for read and write paths, so a prompt injection that redirects the agent to a different tool chain hits a wall at the IAM layer, not inside the ERP.
• Short-lived credentials brokered at call time, not long-lived API keys baked into a container.

Okta, Microsoft, and the OWASP AI Agent Security guidance all converge on the same point: the agent's identity, not its prompt, is the real control surface. If you have shipped zero trust architecture in other parts of your stack, you already have the mental model. Extend it to agents before you extend it to anything else.

Tool Allowlists Are the Real Policy

The model does not have permissions. The tools do. Every write path should be a named tool with a typed schema, an allowlist of accepted arguments, and a server-side authorization check that runs independently of whatever the model decided. OWASP's guidance is explicit on this: the model deciding to call a tool is not the same as the user being authorized to use that tool, and each tool call should be independently authorized rather than chained freely from model output.

Practical shape of a tool definition for a GL posting:

• Name: post_journal_entry, bound to one company code and one ledger.
• Schema: amount (decimal, max $25,000 per call), account (enum from a short allowlist), cost center (regex), memo (string, redacted for PII before logging).
• Authorization: the broker verifies the invoking user still has posting rights in the ERP, not just at agent-launch time.
• Side effects: idempotency key required; a replay produces the same posting, not a duplicate.

Anything the agent wants to do that is not on the allowlist does not fail silently. It raises, logs, and either escalates to a human or returns a structured error the planner can react to. The rise of MCP servers has made this easier to standardize, but it has also made it tempting to point an agent at a vendor's MCP catalog without reading what each tool actually does. Audit every tool before it goes on the allowlist. Treat tool annotations as untrusted metadata.

OAuth Token Brokering, Not Static Keys

The weakest part of most ERP AI integration work is credential handling. A long-lived API key with full write access, stored in a container env var, used by every agent run, is the pattern auditors flag first and attackers find second.

A token broker fixes the shape of this problem. The agent authenticates to the broker with its own NHI. The broker checks policy, mints a short-lived OAuth token scoped to the exact action and resource the agent requested, and hands it back. Tokens expire in minutes, not days. They carry the invoking human's identity as a claim where one exists, so dual attribution survives into the ERP's own log.

Three properties that matter in practice:

• Audience-scoped tokens, so a token minted for NetSuite will not work against Salesforce even if exfiltrated.
• Effective authority is the intersection of agent permissions and the human user's permissions, never the union. If the agent can post to GL but the user cannot, the write fails.
• No passthrough. The agent never sees the user's refresh token or primary credential.

If you are building a bespoke broker, treat it like a payment service: small surface, heavy testing, independent review. The same team that would scrutinize a custom API integration for a bank should scrutinize this.

Dual Control for Financial Writes

Segregation of duties did not go away because an agent showed up. For any write that touches the ledger, moves cash, or changes master data above a materiality threshold, the agent should be the proposer and a different identity should be the approver. That second identity can be a human for high-dollar actions and a separate, narrowly scoped verification agent for routine ones, but it cannot be the same NHI that drafted the posting.

Concrete rules worth encoding:

• Writes below a per-transaction threshold auto-approve, with sampling pulled for review.
• Writes above the threshold queue for human approval with the full tool-call parameters visible, not a model-generated summary.
• Vendor master changes, bank account updates, and payment file releases always require a second human, regardless of amount.
• The approving human cannot be the same person who authored the request that triggered the agent.

This is also where the agent's reasoning trace becomes useful. The approver should see what the agent believed, which retrieved documents it relied on, and which tool calls it is about to make — not just the final payload.

Audit Trails That Survive a SOX Review

An auditor is not interested in your prompt engineering. They want to know, for every financial posting the agent produced, what triggered it, what inputs it saw, which human was accountable, and whether the controls designed to prevent errors actually ran. A SOX audit trail documents controls over financial reporting — who did what, when, under what authority, with what outcome, and when AI influences those controls, the same evidentiary bar applies plus AI-specific fields like model versions, prompts, and reasoning.

What to capture, at minimum, for every agent action with financial impact:

• Agent identity, model and system version, policy version, and the full tool-call parameters.
• The authenticated human whose session or ticket initiated the work. The most frequent 2026 finance-side finding is AI accessing ERP data via a service account with no log of which finance team member initiated the work, which fails SOX's individual attribution standard.
• The prompts and retrieved context used to form the decision, hashed and stored.
• The downstream posting IDs returned by the ERP, linked back to the agent event.
• Approval chain: who approved, when, from which device.

Retention matters too. For SOX-relevant systems, operational AI logs should be retained for at least 366 days and audit work papers for seven years. Store the log in an append-only sink with hash chaining so an insider cannot quietly rewrite history. The same discipline you would apply to a core banking integration applies here.

Where This Lands

An agent that writes to SAP, NetSuite, Salesforce, or a GL is not a chatbot with extra steps. It is a privileged service account with a probabilistic planner attached. The security work is mostly identity, tool design, brokering, and logging — the agentic AI security story is less about guarding the model and more about engineering the blast radius around it.

Prompt injection defenses matter. Cost controls matter. But if the identity is sloppy, the tool allowlist is loose, the tokens are long-lived, and the audit trail cannot answer the auditor's first question, nothing else saves you. Build those four layers first, and the model becomes the easy part.