Why do AI agents increase risk in ERP and finance systems?

Why This Matters for Security Teams

AI agents are riskier in ERP and finance because they are not just automated scripts. They can interpret context, chain actions, and make tool calls that move money, alter supplier records, or trigger approvals. That makes the identity question central: a single agent account can become a high-impact execution path if access is broad, static, or poorly monitored. Guidance from the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework both point to the same practical issue: autonomous systems expand the blast radius because their behaviour is runtime-dependent, not fixed.

In finance workflows, the risk is amplified by sensitive objects such as invoices, payment instructions, vendor master data, and reconciliation logic. If an agent can read and write across those systems without task-specific constraints, compromise becomes operational, not theoretical. NHIMG research on the Top 10 NHI Issues repeatedly shows that over-privileged non-human identities are a recurring root cause of enterprise exposure. In practice, many security teams encounter agent-driven fraud paths only after an approval chain, posting workflow, or supplier record has already been misused.

How It Works in Practice

The safest model for ERP and finance is to treat the agent as a workload identity with tightly scoped, time-bound authority. That means authorisation should happen at request time, based on what the agent is trying to do, the data it is touching, and the business context of the action. Static RBAC is often too blunt for autonomous systems because agents do not follow one predictable job description. Current guidance suggests combining workload identity, policy-as-code, and short-lived credentials so access is issued only for the exact task and revoked immediately after completion.

In practice, teams should separate the identity of the agent from the secrets it uses. A good pattern is:

• Use workload identity as the primary trust anchor, with short-lived OIDC or SPIFFE-based credentials where feasible.
• Issue just-in-time access for discrete finance tasks, such as invoice lookup, journal posting, or vendor validation.
• Evaluate policy at runtime with context-aware rules, rather than granting broad standing access to ERP APIs.
• Log every tool call, approval request, and data mutation so unusual sequences can be detected quickly.

This approach aligns with NHIMG guidance in the Ultimate Guide to NHIs — Why NHI Security Matters Now and with threat modelling approaches in CSA MAESTRO agentic AI threat modeling framework. It also reflects the direction of the MITRE ATLAS adversarial AI threat matrix, which highlights how chained behaviours and tool misuse create compound risk. These controls tend to break down when ERP integrations depend on legacy service accounts that cannot enforce per-action policy or short-lived token issuance.

Common Variations and Edge Cases

Tighter control often increases operational overhead, so organisations have to balance speed against fraud resistance and auditability. That tradeoff is especially visible in finance teams that rely on batch processing, shared service accounts, or vendor-managed integrations. Best practice is evolving, and there is no universal standard for agent identity in ERP yet, but the direction is clear: avoid standing privilege wherever an agent can initiate payments, modify master data, or trigger downstream approvals.

Edge cases matter. Some agents only prepare drafts for human review, which lowers the risk but does not eliminate it if the agent can still access sensitive records or suggest malicious changes. Other agents operate in multi-step pipelines, where one low-risk action can create a later privilege escalation. NHIMG’s reporting on the AI LLM hijack breach and the Moltbook AI agent keys breach shows how exposed secrets and agent credentials can translate into rapid abuse. The practical takeaway is simple: if an agent can reach finance data, its identity, credentials, and runtime policy must be treated as high-value assets, not implementation details.

Related resources from NHI Mgmt Group

• Why do AI agents increase non-human identity risk in existing IAM programmes?
• How should security teams limit the risk from AI agents that have access to production systems?
• Why do AI agents increase non-human identity risk?
• Why do AI agents create new risk in non-human identity management?