ERP Security Struggles to Keep Pace With AI Agents

BankInfoSecurity has pushed an uncomfortable conflict onto Google News: ERP security controls are struggling to keep pace as AI agents gain operational authority.

The issue is not whether an assistant can summarize an invoice or answer a procurement question. The risk begins when an agent can retrieve records, invoke tools, change transactions, and coordinate actions across several enterprise systems.

SAP, Oracle, Microsoft, and Workday are moving ERP software toward that model. Their agents promise to reduce repetitive work across finance, procurement, human resources, and supply chains. Yet the controls surrounding those agents still inherit assumptions designed for human employees and predictable applications.

That mismatch creates the central security problem. Traditional ERP governance asks which person has a role and which transactions that role permits. Agentic systems introduce delegated objectives, changing context, tool selection, and machine-to-machine handoffs.

An agent can possess valid credentials and still take an unsafe action. It can also combine several individually permitted steps into an outcome that no administrator intended.

ERP vendors are adding identity controls, approval gates, and audit features. Those measures matter, but they do not eliminate the deeper conflict between agent autonomy and deterministic enterprise controls.

The Google News Warning Is About Authority, Not Chatbots

The important change is that ERP AI agents are moving from reading business data to acting upon it.

The ERP security report surfaced through Google News frames the problem as a race between expanding agent capabilities and slower security adaptation.

That framing matters because ERP systems contain a company’s operational truth. They store payment instructions, employee records, supplier terms, inventory positions, customer balances, and financial approvals.

A conventional chatbot may produce an incorrect answer. An ERP agent with execution rights can turn an incorrect answer into a posted journal entry or an approved supplier change.

Agentic AI refers to software that can interpret a goal, create a plan, choose tools, and perform several steps with limited supervision. This differs from fixed automation, which follows a predefined path.

A traditional workflow might reject an invoice whenever a purchase order is missing. An agent may investigate the discrepancy, retrieve correspondence, compare delivery records, and recommend an exception.

That flexibility creates value because real business processes contain ambiguity. It also weakens the predictability upon which many existing security controls depend.

Security teams can examine a fixed workflow before deployment. They know which fields it reads, which system calls it makes, and which conditions trigger an approval.

An agent may choose a different sequence each time. Its behavior can change with the prompt, available tools, retrieved documents, model version, or surrounding conversation.

That means authorization cannot stop at login. Security must evaluate the agent’s identity, delegated purpose, current context, selected tool, requested data, and intended effect.

The problem becomes harder when an agent crosses application boundaries. A finance agent may consult email, procurement records, customer data, and a payment system before completing one task.

Each connection expands the attack surface. It also makes responsibility harder to assign when several components contribute to an unsafe outcome.

Google News readers might initially interpret the story as another warning about generative AI accuracy. The underlying issue is more consequential.

ERP security teams must govern software that behaves less like a passive application and more like a highly connected worker. That worker can operate continuously, at machine speed, and across organizational boundaries.

The change places pressure on chief information security officers, ERP administrators, identity teams, internal auditors, and business process owners. None of those groups can manage the risk alone.

Security teams understand access control but may lack detailed process context. Finance leaders understand material consequences but may not see every technical dependency.

ERP administrators understand roles and transactions. They may not control external models, agent frameworks, or third-party tools attached to the workflow.

The immediate challenge is therefore organizational as well as technical. Companies need one control model that follows an agent from initial instruction through every resulting action.

ERP AI Agents Break the Human Identity Model

A valid identity no longer proves that an action is appropriate when software can reinterpret goals and select its own execution path.

ERP controls have traditionally centered on named users, assigned roles, and segregation of duties. Segregation of duties prevents one person from controlling incompatible stages of a sensitive process.

For example, the employee who creates a supplier should not independently approve payments to that supplier. The rule limits fraud and reduces the impact of compromised credentials.

Agents complicate this model because authority can pass through several layers. A person instructs an agent, the agent calls another agent, and that agent invokes a business application.

The final system may see only an authenticated service identity. It may not receive the original user, purpose, evidence, or limits attached to the request.

This creates a delegation-chain problem. Each system recognizes its immediate caller, while the complete source and intention of the action become harder to reconstruct.

Shared agent credentials make the problem worse. If several workflows use one service account, investigators may struggle to distinguish legitimate automation from misuse.

Persistent credentials also allow authority to outlive its original purpose. An agent created for a temporary reconciliation project might retain access after that work ends.

Human access reviews typically operate around employment events and fixed roles. Agents can appear, change, duplicate, and disappear much faster than employees.

They may also be assembled outside formal development processes. A business team can connect a model to an approved tool without recognizing that the combination creates a new privileged identity.

The agentic security framework from OWASP identifies identity and privilege abuse among its central risks. It also highlights goal hijacking, tool misuse, and agentic supply-chain weaknesses.

Goal hijacking occurs when malicious or untrusted content changes what an agent tries to accomplish. The harmful instruction may sit inside a document, message, web page, or tool response.

This is more dangerous inside ERP than in a standalone assistant. The agent may already possess access to confidential records and transaction functions.

Consider a procurement agent that reads supplier emails. A compromised message could instruct the model to prioritize an attacker-controlled bank account or disclose internal purchasing data.

The request might conflict with the user’s original goal. Yet the agent could treat the embedded text as relevant operational context unless safeguards separate data from instructions.

Least privilege remains necessary, but its implementation must become more precise. An agent should receive only the permissions required for one purpose and one limited period.

Oracle’s secure operations guidance makes this distinction explicit. An analytics agent does not need procurement approval rights simply because both participate in one workflow.

That principle sounds familiar, but agents make enforcement more difficult. Their plans can evolve after a task begins, and they may request additional tools during execution.

Static roles cannot fully express conditions such as purpose, transaction value, data sensitivity, confidence, or whether another agent initiated the request.

Companies therefore need policy checks at the moment of action. Those checks should evaluate both the requested operation and the context surrounding it.

High-impact actions also require stronger proof of human intent. A confirmation button is insufficient if the reviewer sees only a polished summary produced by the same agent.

The reviewer needs the original evidence, proposed changes, policy exceptions, and expected business effect. Otherwise, human oversight becomes ceremonial.

The Real Tradeoff Is Autonomy Versus Control

Every increase in agent autonomy raises the burden on identity, policy enforcement, observability, and recovery.

ERP AI agents become useful when they can handle exceptions. However, exceptions are precisely where deterministic controls provide the least coverage.

A fixed automation follows paths that developers define in advance. An agent interprets incomplete information and decides which path seems appropriate.

This distinction creates a security tradeoff. Restrict an agent too tightly, and it becomes an expensive interface for existing workflows. Grant broader authority, and its mistakes gain operational consequences.

The conflict does not disappear when an agent remains inside a vendor’s cloud. A controlled environment can reduce exposure, but business logic still determines whether an action is acceptable.

An agent may have permission to update supplier records. That permission does not mean every supplier update serves a legitimate purpose.

An agent may also combine low-risk capabilities into a high-risk sequence. Reading invoices, creating suppliers, and preparing payments appear manageable when evaluated separately.

Together, those capabilities can reproduce an entire fraud path. This is sometimes called a compositional risk, where safe-looking components produce an unsafe combined outcome.

Security tools often inspect individual API calls. They may approve every step while missing the broader plan that connects them.

Agent memory creates another difficulty. Memory allows software to retain task context, preferences, or prior observations across interactions.

That continuity can improve performance. It can also preserve malicious instructions, sensitive data, or incorrect assumptions beyond the session where they entered the system.

Retrieval-augmented generation, or RAG, gives a model selected enterprise information when answering or acting. Its security depends on the source, permissions, quality, and freshness of retrieved material.

A poisoned knowledge source can distort later decisions without directly compromising the underlying model. An outdated policy document can create a similar result through ordinary operational failure.

This makes information governance part of AI agent security. Teams must know which sources an agent uses, who can change them, and how retrieved evidence affects decisions.

Employees building internal workflows also need reliable documentation. A searchable knowledge base can help teams preserve design decisions, threat models, and approval requirements around agent deployments.

Documentation cannot replace technical controls. It can reduce the chance that critical assumptions disappear when an agent changes owners or moves from pilot to production.

Tool access creates a parallel risk. Tools translate model output into actions, such as querying a database, sending a message, or modifying a business record.

The model does not need direct database credentials if a connected tool already holds them. The tool therefore becomes part of the agent’s effective permission boundary.

Security reviews must examine tool schemas, input validation, credential storage, output filtering, and failure behavior. Reviewing only the model misses most of the execution path.

Multi-agent systems increase the uncertainty further. One agent may delegate research, another may interpret policy, and a third may execute the transaction.

Each handoff can lose context or introduce untrusted output. It can also obscure which component made the decision that caused harm.

SAP’s published security architecture traces agent requests through identity verification, AI processing, business execution, and forensic logging.

That end-to-end view is the right direction. However, architecture diagrams do not establish that every customer deployment applies the controls consistently.

ERP environments contain custom code, legacy integrations, acquired systems, external partners, and long-lived exceptions. Those differences can weaken a vendor’s default security model.

The most difficult deployments will involve hybrid estates. An agent may begin in a modern cloud service but act through older applications with coarse permissions and limited telemetry.

In those environments, the newest component can inherit the weakest control in the chain. Agent autonomy then magnifies technical debt that organizations already struggled to manage.

Audit Logs Cannot Explain Every Agent Decision

ERP security needs evidence that connects user intent to agent reasoning, tool calls, data changes, and business outcomes.

Traditional audit logs answer familiar questions. They show which account accessed a system, when a transaction occurred, and which field changed.

Agentic workflows demand a longer chain of evidence. Investigators need the initiating user, delegated objective, model version, retrieved context, policy decisions, tool calls, and final result.

They may also need to know what the agent declined to do. Repeated denied requests can reveal probing, misconfiguration, or a compromised source.

Logging every prompt and response is not an easy solution. Prompts can contain payroll records, contracts, personal data, credentials, and other restricted information.

A complete log may therefore create another sensitive repository. Retention, access, encryption, and redaction rules must match the underlying business data.

Model reasoning presents a further complication. A generated explanation can sound coherent without accurately representing how the system reached its output.

Security teams should not treat a narrative explanation as proof. They need verifiable records of inputs, tool requests, policy evaluations, and resulting state changes.

This changes the meaning of observability. Monitoring must capture behavior across the entire workflow, not simply model availability or API errors.

Useful signals include unexpected tool selection, unusual transaction volume, access outside normal business scope, repeated policy denials, and changes to sensitive records.

Baselines also need to reflect an agent’s assigned purpose. A payroll reconciliation agent and a sourcing agent should not share the same normal behavior profile.

Rate limits can reduce the blast radius of mistakes. They cannot determine whether a small number of high-value actions are legitimate.

Transaction thresholds provide another layer. Yet attackers may divide activity into smaller actions or exploit processes where one low-value change enables a later loss.

Companies need controls at several points. The agent runtime should restrict tools, the identity layer should restrict authority, and the ERP should validate business rules.

Independent monitoring should then verify what actually occurred. Relying on the same agent to act, evaluate, and report its own behavior concentrates too much trust.

Human approval remains valuable for irreversible or material actions. However, reviewers need enough time and context to detect manipulation.

Approval fatigue can turn a safeguard into a formality. Agents operating at machine speed can generate more review requests than employees can assess carefully.

Risk-tiered autonomy offers a more workable model. Low-impact, reversible tasks can proceed automatically, while sensitive actions require independent validation.

Examples of lower-risk work include drafting explanations, collecting evidence, and flagging anomalies. Higher-risk work includes changing payment details, releasing funds, or modifying access.

Reversibility should influence the control level. A mistaken report can be corrected, while an external payment or deleted record may create lasting damage.

The NIST risk profile organizes AI risk work around governance, mapping, measurement, and management. That lifecycle approach fits ERP agents better than one-time approval.

An agent’s risk changes when its tools, model, data sources, permissions, or business purpose change. Each modification should trigger reassessment and targeted testing.

Testing must include adversarial inputs and realistic business exceptions. A demonstration built around clean data will not reveal how an agent behaves under conflicting instructions.

Teams should also test partial failures. A downstream system may time out after an agent completes one step but before it records the next.

Without idempotency, which prevents repeated execution from producing duplicate effects, an agent may submit the same transaction again during recovery.

These ordinary reliability problems become security issues when they affect financial records, access rights, or regulated data. Agent safety cannot remain separate from system engineering.

Vendor Guardrails Meet Customized ERP Reality

SAP and Oracle can secure their own agent platforms, but customers still control the integrations, roles, data, and exceptions that determine practical risk.

ERP vendors have a structural advantage. They understand their application models and can embed agents beside existing identity, workflow, and audit services.

Native agents can inherit business metadata that an external model lacks. They can also use approved interfaces instead of imitating user actions through a screen.

Oracle advises customers to separate agent responsibilities and apply least privilege across cooperating agents. SAP describes identity checks, tenant isolation, output validation, and forensic audit trails.

Those controls address real concerns. They also support the vendor argument that embedded agents are safer than loosely connected third-party automation.

The argument has limits. Most large organizations do not operate one clean ERP environment with standard configurations.

They run customized processes across several systems. Some applications remain on-premises, while others sit in public clouds or vendor-managed services.

Partners, contractors, banks, logistics providers, and acquired business units may connect to the same process. Each boundary introduces a different identity and control model.

A native finance agent can still receive untrusted content from email. It can rely on a third-party document parser or send a result into an older payment application.

The overall workflow is only as trustworthy as those dependencies. Vendor security documentation cannot account for every customer extension.

External agents present a different tradeoff. They can coordinate work across competing ERP, CRM, communications, and analytics platforms.

That independence can reduce vendor lock-in and support broader workflows. It also places another identity, orchestration layer, and tool ecosystem between users and business records.

The practical choice is therefore not secure native software versus insecure external software. Both approaches create risks, but they concentrate those risks in different places.

Native agents concentrate trust in the ERP vendor’s platform, cloud, and governance model. External agents distribute trust across connectors, credentials, models, and orchestration tools.

Security teams should evaluate the complete action path rather than accept category labels. A native product can become unsafe through broad configuration.

An external product can reduce risk if it receives narrowly scoped, short-lived authority and cannot directly complete sensitive transactions.

Procurement reviews must reflect these differences. Standard software questionnaires rarely capture delegation depth, memory behavior, prompt handling, or tool-level permissions.

Buyers should ask which identity appears in the ERP log and whether it identifies the original user. They should also ask how policy follows a task across agent handoffs.

Other essential questions concern model updates, retained context, data residency, incident response, and customer access to detailed telemetry.

The vendor should explain how administrators can immediately suspend an agent. That control must revoke active credentials and interrupt pending actions, not merely hide the interface.

Customers also need evidence about change management. An agent’s behavior can shift after a model, system prompt, tool definition, or retrieval source changes.

A traditional application update usually changes deterministic code. A model update can alter decisions even when the surrounding workflow remains unchanged.

Security testing must therefore continue after deployment. Teams should run representative tasks and abuse cases whenever a meaningful component changes.

They should compare results across versions and preserve enough evidence to investigate regressions. A passing test from six months earlier says little about a modified agent.

Competitive pressure can undermine this discipline. ERP vendors want customers to adopt agents, while business leaders want measurable productivity improvements.

Security teams may receive pressure to approve broad pilots before identity and monitoring systems are ready. That sequencing turns governance into a repair project.

A safer rollout starts with bounded tasks and observable outcomes. Authority expands only after the organization can explain, detect, and reverse agent behavior.

Three Signals Will Show Whether ERP Security Catches Up

The next phase will be decided by agent-specific identities, action-level enforcement, and evidence from real production incidents.

The first signal is whether ERP platforms adopt distinct, short-lived identities for each agent and delegated task. Shared service accounts should become an exception.

A mature design will preserve the original user, agent identity, purpose, and authority throughout the workflow. Downstream applications should receive that context before allowing action.

This would strengthen the case that ERP AI agents can operate within established accountability structures. Continued reliance on broad credentials would weaken it.

The second signal is whether vendors and customers enforce policy at the transaction level. Permission to use a tool should not become permission for every possible tool output.

Controls should consider transaction type, value, destination, source evidence, and reversibility. Sensitive operations should require independent checks outside the acting model.

Security teams should watch product releases for concrete enforcement features. Marketing language about responsible AI is less useful than configurable controls and exportable logs.

They should also examine whether those controls work across connected applications. Protection limited to one vendor’s interface will not cover a cross-platform workflow.

The third signal is the quality of public incident reporting. Production failures will reveal where theoretical architectures break under real business conditions.

Useful disclosures will identify the compromised identity, manipulated input, affected tools, unauthorized actions, and containment method. Vague references to an AI error will not help defenders.

Incidents should also clarify whether human approval existed and why it failed. That evidence will show whether oversight reduces risk or merely transfers responsibility.

The central claim behind the Google News warning will grow stronger if agents expand faster than those three controls. It will weaken if identity, enforcement, and evidence mature together.

Organizations should not wait for a major loss before mapping their own exposure. They can begin by listing every agent connected to an ERP process.

That inventory should include owner, purpose, model, tools, data sources, credentials, approval points, and shutdown procedure. Unknown entries deserve immediate investigation.

Next, teams should trace a few high-impact workflows from instruction to final transaction. Payment changes, access grants, journal entries, and employee record updates are good starting points.

The exercise will expose missing context between systems. It will also reveal where one credential or tool holds more authority than the business task requires.

Companies should then classify actions by impact and reversibility. Read-only research does not need the same controls as releasing funds or changing master data.

Finally, security leaders should test how the organization responds when an agent behaves incorrectly. Detection without containment leaves the most important question unanswered.

Can administrators stop the agent, revoke its authority, preserve evidence, reverse the action, and identify affected records before damage spreads?

ERP security does not need to eliminate autonomy. It needs to ensure that autonomy never becomes unbounded authority.

The practical next step is simple: choose one live or planned agent workflow and trace every identity, tool, data source, and approval it touches. If your team cannot explain that chain, the agent is not ready for broader access.

Ask who can stop it, what evidence survives, and which actions can be reversed. Those answers matter more than another polished demonstration.

Google News has surfaced the warning. Enterprise teams now need to decide whether their ERP controls govern agents as carefully as they govern people.