AI identity governance for ERP and finance workflows

At a glance

What this is: This is an analysis of why AI in ERP, finance, and SaaS now needs identity governance as well as data governance, with MCP and agent access as the central control problem.

Why it matters: It matters because practitioners have to govern AI, service accounts, and human access as one control plane when agents can touch regulated data and business transactions.

👉 Read SafePaaS's analysis of AI identity governance for ERP, finance, and SaaS

Context

AI identity governance is no longer a theoretical extension of IAM. When copilots, agents, and embedded assistants can draft journal entries, update customer records, and move data between enterprise systems, the question is not whether the model is smart enough but whether the identity behind it is governed tightly enough.

The gap is structural: traditional IAM and PAM were built for people and known privileged workflows, while AI systems now operate across ERP, finance, SaaS, and integration layers with fragmented visibility. That is why the control problem spans human identity, non-human identity, and workflow governance at the same time.

Key questions

Q: How should security teams govern AI agents that can touch ERP and finance systems?

A: Security teams should govern AI agents as first-class identities, not as application features. That means assigning owners, limiting scopes, tying access to business actions, and putting every agent that can read or write ERP and finance data into lifecycle review and certification. If the agent can move money or records, it needs identity governance equal to the risk.

Q: Why do AI copilots create identity risk in enterprise workflows?

A: AI copilots create identity risk because they can inherit enough access to act inside real business processes without the same controls applied to human users. Once they can invoke APIs, read regulated data, or write back into ERP and SaaS systems, the security question becomes whether their identity, privileges, and approvals are governed with the same discipline as human access.

Q: What breaks when AI access is managed only inside application settings?

A: What breaks is governance visibility. Application settings can permit an action, but they do not give a unified view of which AI identities exist, which data classes they can touch, or whether segregation of duties is being violated across systems. That leaves security teams with fragmented logs and no reliable evidence trail for audit or incident review.

Q: Who is accountable when an AI agent changes financial data incorrectly?

A: Accountability should sit with the business owner and control owner who approved the agent’s access, its data scope, and its workflow boundaries. If no one can name that owner, the programme is already exposed. Frameworks such as NIST Cybersecurity Framework 2.0 and identity governance processes require clear ownership for high-risk access.

Technical breakdown

MCP as an identity boundary for AI workflows

Model Context Protocol creates a common way for AI systems to reach tools and data through MCP servers. That simplifies integration, but it also concentrates authority: one server can expose ERP actions, SaaS writes, and data queries through a single decision point. In practice, the protocol becomes an identity boundary, because the server determines which tools, scopes, and datasets the agent can reach. If that boundary is weak, the agent inherits broad access that downstream systems never intended to grant through a single conversational path.

Practical implication: Treat MCP servers as privileged integration points and inventory their scopes, owners, and downstream access before any production rollout.

Why AI risk is both a data and identity problem

AI risk cannot be reduced to model safety. A copilot that can see regulated data and write back into business systems creates a combined identity and data exposure, because the access decision and the data classification decision are inseparable. Traditional data tools can label sensitive records, but they do not usually decide which AI identity may act on them. Traditional IAM can authenticate an agent or service account, but it rarely understands whether that identity is allowed to process supplier bank details, customer credit limits, or audit evidence in a live workflow.

Practical implication: Map each AI identity to the data classes and business actions it can touch, then enforce those relationships as policy rather than after-the-fact review.

Identity governance as the control plane above IAM and PAM

Identity governance fills the layer above authentication and session control by deciding which identities should exist, which approvals apply, and how access is certified over time. For AI-driven workflows, that matters because the real risk is not just credential abuse, but business action abuse inside finance and ERP processes. SoD, least privilege, lifecycle review, and audit evidence all need to be evaluated against AI identities as first-class subjects. Without that control plane, organisations end up with policy statements but no reliable way to prove who or what changed a transaction, touched a dataset, or bypassed an approval path.

Practical implication: Extend access reviews, SoD rules, and lifecycle controls to AI identities instead of leaving them inside application settings and ad hoc logs.

Threat narrative

Attacker objective: The objective is to use ungoverned AI access to execute business actions and move sensitive data outside the approvals and controls the enterprise expects.

1. Entry occurs when a copilot, agent, or MCP-connected assistant is enabled inside finance, CRM, or ERP without central access governance.
2. Escalation happens when that identity inherits broad scopes, touches regulated data, or performs write actions that were designed for tightly controlled human roles.
3. Impact follows through misposted transactions, unauthorized master-data changes, uncontrolled movement of regulated data, and audit findings discovered after the fact.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Identity governance now has to become the control plane for AI workflows, not just a reporting layer. The article is right to frame ERP, finance, and SaaS AI as an identity problem because the meaningful control decision is who or what may act, not just what the model can generate. When copilots and agents can write back into business systems, IAM alone does not capture SoD, lifecycle approval, or evidence requirements. The practitioner conclusion is straightforward: AI access must be governed as a first-class identity subject.

AI identity and data access cannot be separated once agents operate inside business systems. A model that can see regulated data and also trigger downstream actions creates a combined governance problem that neither data cataloging nor credential control solves on its own. The relevant frame is OWASP-NHI and NIST-CSF, because the issue is not AI novelty but non-human access with business effect. The practitioner conclusion is to bind data classification to identity entitlements at the workflow boundary.

Controlling the MCP boundary is the real blast-radius issue. MCP is not just a connector pattern; it is where multiple permissions collapse into one reachable integration surface. That means a single mis-scoped server can expose ERP, SaaS, and data systems in ways application-level controls will not see clearly enough. The practitioner conclusion is to inventory and govern MCP servers as privileged integrations.

Least privilege for AI is only meaningful when it is expressed through business action, not generic account scope. A service account that can read records but not write them is a clearer control statement than a broad integration identity with undocumented downstream behaviour. This is where identity governance outperforms generic IAM, because it can model role, approval, and certification across finance and SaaS workflows. The practitioner conclusion is to measure AI access in terms of transactions and data classes, not just credential presence.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which means most identity programmes still lack a complete view of non-human access.
• That visibility gap makes the case for Top 10 NHI Issues even stronger when teams are building control coverage across AI, machine, and service identities.

What this signals

AI identity governance will be measured by whether teams can explain business action, not just authentication success. As copilots and agents move into finance and ERP, the practical test becomes simple: can the organisation show who approved the access, what data it could touch, and which transactions it was allowed to complete? That is a lifecycle and governance question before it is a tooling question.

Control-plane thinking will replace app-by-app exception handling. Once AI touches multiple systems, the useful operating model is a single view of entitlement, data sensitivity, and approval history across the workflow. The more fragmented the policy stack, the more likely teams are to miss over-privilege until an audit or incident exposes it.

Ephemeral AI access is not automatically safe. Even if an agent is only active for a short period, its permissions can still create outsized business impact if the workflow can write to financial or regulated records. That is why governance must follow the action path, not the session duration alone.

For practitioners

• Inventory all AI identities in business workflows Build a single register of copilots, agents, service accounts, and integration identities that can reach ERP, finance, CRM, and collaboration tools. Include owner, approval path, downstream system reach, and whether each identity can read or write regulated data.
• Classify AI access by business action and data sensitivity Map each AI identity to the exact transaction types and data classes it can touch, such as journal entries, customer records, supplier details, and audit logs. Use those mappings to drive policy instead of relying on application defaults.
• Extend SoD rules to agent-driven workflows Identify where an AI identity can both prepare and approve, or prepare and post, in the same business flow. Split those duties across separate identities or block the workflow entirely when segregation cannot be proven.
• Govern MCP servers as privileged integration services Approve each MCP server as if it were a high-value integration point. Track its scopes, data sources, and downstream actions, and require explicit review before it can expose finance or regulated datasets.
• Certify AI identities on a recurring lifecycle basis Put agent and service-account access into the same certification rhythm used for high-risk human access. Revalidate ownership, necessity, and scope after every material workflow or data change.

Key takeaways

• AI in ERP and finance is an identity governance problem because agents can now take actions, not just generate output.
• When AI can touch regulated data and business transactions, visibility into identity, approvals, and SoD becomes the real control gap.
• Enterprises need a single control plane for human, machine, and agent access if they want audit-ready evidence and bounded AI risk.

Key terms

• AI identity governance: AI identity governance is the discipline of deciding which AI systems may exist, what they can access, and which business actions they can perform. It combines lifecycle control, approval, segregation of duties, and evidence so AI access can be governed like any other high-risk identity.
• Model Context Protocol: Model Context Protocol is a standard pattern for connecting AI models to tools and data sources through a shared interface. In practice, it becomes a governance boundary because the server controls which systems an agent can reach, what scopes it gets, and how much blast radius a misconfiguration can create.
• Segregation of duties: Segregation of duties is the rule that no single identity should be able to complete a risky business process end to end. For AI workflows, that means preventing one agent from preparing, approving, and posting the same transaction, especially in finance, ERP, and regulated operations.
• Non-human identity: A non-human identity is any machine or software identity that authenticates and acts on systems, including service accounts, API keys, tokens, certificates, bots, workloads, and AI agents. These identities often outnumber humans and require lifecycle, privilege, and approval controls that are separate from user authentication.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or programme maturity, it is worth exploring.

This post draws on content published by SafePaaS: AI identity governance for ERP, finance, and SaaS AI. Read the original.