Join our Newsletter — 33% off our NHI Course

How should organisations govern AI agents and service accounts in ERP systems?

Apply the same access lifecycle discipline to non-human identities that you expect for privileged human users. Scope permissions to a single purpose, review trusted connections regularly and remove access when the workflow or integration is no longer needed. Without that discipline, automation becomes a persistent privilege path inside core business systems.

Why ERP agent governance has to start with access lifecycle, not model novelty

AI agents and service accounts should be governed as privileged execution paths inside the ERP, not as temporary integration conveniences. The central issue is not whether the workflow is automated, but whether the automation can still be explained, limited, reviewed and removed like any other high-trust account path.

That means every agent or service account needs an owner, a defined business purpose and a clear boundary for what it may do in production. If those boundaries are vague, ERP automation tends to accumulate standing access, duplicate roles and hidden dependencies that survive long after the original use case has changed.

Governance also has to account for where the account sits in the ERP control plane. An agent that can post journals, approve payments, change vendor data or trigger workflows is operating in a far more sensitive zone than one that only reads reference data, so the review standard should scale with the business consequence of the permission set.

How to scope, review and retire non-human access in ERP environments

The most reliable pattern is to treat access as purpose-bound and time-bound. Give the account only the ERP functions it needs, map those functions to a named workflow or integration, and require periodic recertification by the business owner who benefits from that automation, not only by the platform team that built it.

Trusted connections should also be reviewed at the relationship level, not just the credential level. In practice, that means checking which upstream system, orchestration layer or agent is allowed to call the ERP, whether that trust is still justified, and whether the connection can be narrowed to a smaller scope or replaced with a separate account for a different task.

When a workflow ends, the access should end with it. The difficult part is often not the initial provisioning, but the retirement discipline: removing dormant service accounts, revoking unused agent permissions, and confirming that backups, scripts, scheduled jobs and exception paths no longer depend on the old identity.

What good governance looks like when agents and service accounts share the ERP

Strong governance separates ownership, approval and technical administration. The person who requests the access should not be the only person who can renew it, and the team that operates the ERP should not be the only team that understands why the access still exists. That separation reduces the chance that embedded automation becomes invisible privilege.

It also helps to standardise the evidence required for every non-human account: business purpose, system owner, allowed ERP modules, approval date, review cadence, expiry or renewal date, and the conditions under which the account must be disabled. Those records make later recertification faster and make exceptions easier to challenge.

For AI agents, add an extra layer of discipline around delegated authority. If an agent can take actions on behalf of a user or another system, the organisation should verify exactly which actions are delegated, whether human approval is required for sensitive steps, and whether the agent’s authority can be narrowed per action rather than granted once and left open-ended.

Risk and Threat Considerations

ERP automation becomes dangerous when standing access outlives the workflow that justified it. The main exposure is privilege accumulation: an account created for convenience can later be reused, over-scoped or forgotten, turning routine integration into a persistent path to sensitive financial and operational functions.

Failure mechanism: Service accounts and AI agents are often provisioned for speed, then left with broad roles, long-lived credentials or weak ownership, so they retain access after the original use case changes. Attackers and insiders can exploit that persistence to move through ERP processes, alter records or abuse trusted automation paths.

Impact: The organisation can lose control over transactions, master data and approval flows, and may not notice until an unusual workflow event, fraud indicator or process failure appears. In an ERP, that can translate into financial loss, reporting error, operational disruption and difficult-to-trace business abuse.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack surface, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.

Framework Control / Reference Relevance
OWASP Non-Human Identity Top 10 NHI-01 — Improper Offboarding ERP service accounts and agents must be removed when their workflow ends.
NHI-05 — Overprivileged NHI ERP agents and service accounts should have only the permissions their workflow needs.
NHI-07 — Long-Lived Secrets ERP automation often persists through credentials that outlive the use case.
Recommendation — Revoke non-human ERP access promptly when the automation or integration is retired. Apply least privilege to ERP non-human accounts and narrow high-risk roles. Set rotation and expiry rules for service account secrets and agent credentials.
OWASP Agentic AI Top 10 ASI03 — Identity & Privilege Abuse AI agents in ERP can abuse delegated authority or excessive access.
Recommendation — Constrain agent authority per action and require approval for sensitive ERP operations.
NIST SP 800-53 Rev 5 IA-5 — Authenticator Management ERP service accounts and agents need controlled credential lifecycle and rotation.
AC-6 — Least Privilege ERP automation should only access the functions required for its purpose.
Recommendation — Manage ERP non-human credentials with rotation, revocation and expiry controls. Limit ERP account permissions to the minimum needed for the approved workflow.
ISO/IEC 27001:2022 A.5.15 — Access control ERP non-human access needs formal rules for approval, review and removal.
A.5.18 — Access rights ERP accounts require periodic review and timely removal of unneeded rights.
Recommendation — Define and enforce access rules for service accounts and AI agents in ERP. Review ERP access rights regularly and revoke those no longer required.
CIS Controls v8 CIS-5 — Account Management CIS account management directly addresses lifecycle, review and removal of ERP non-human accounts.
Recommendation — Inventory, review and remove ERP service accounts and agent access on schedule.

Practitioner Guidance

What to prioritise: Start with the identities that can touch high-impact ERP functions such as approvals, payments, vendor changes and posting activity. Those accounts deserve the shortest review cycle, the narrowest scope and the clearest named owner.

What to verify: Confirm that every agent or service account has a business purpose that still exists, a current owner, an expiry or review date, and a documented set of ERP functions it is allowed to call. If any of those are missing, treat the access as provisional until the gap is closed.

Practitioner takeaway: The goal is not to make ERP automation disappear, it is to make every non-human privilege path easy to justify, easy to revoke and hard to forget.