In our previous article, a supplier reported a delayed shipment. The buyer asked an AI agent to investigate, and a revised delivery date eventually appeared in the ERP. Fortunately, the team now has updated information to work with. But who actually changed the record, and who approved it after evaluating its impact?

To understand whether the change followed the organization’s controls, the team needs to distinguish who requested it, who approved it, and what performed the update. For leaders in manufacturing, life sciences, and supply chain, adopting agents involves deciding how their actions will be authorized, recorded, and managed.

Start With the Business Process

AI agents can support several activities within ERP workflows. For instance, Microsoft describes agents that assist with supplier communications, account reconciliation, and expense reporting. While these examples offer a useful starting point, the team should consider where an agent’s responsibilities should begin and end before introducing it to the organization.

For our manufacturer, the purchasing team needs help investigating supplier delays. However, permission to investigate supplier delays should not automatically include authority to approve purchasing exceptions or change unrelated financial records. Because of this, the organization should first identify the specific problem, the information needed, and the decisions that require additional review.

separate agent permissionsSeparate Reading, Preparing, and Executing

Permission to read information, prepare a change, and execute the update should be considered separately. For instance, your purchasing assistant could do the following:

  • Retrieve supplier confirmations and relevant purchase order information
  • Prepare a proposed delivery date change with supporting details
  • Apply the update after the required approval

Each step involves different responsibilities. An agent may be useful at the first two stages, even when your organization is not ready to authorize the third.

Microsoft’s identity guidance recommends separating tool permissions and enforcing authorization through application controls. In practice, instructions telling an agent to “ask before making changes” should be supported by controls that prevent unauthorized updates.

approval separate agents aiKeep Approval Responsibilities Separate

Let’s return to our delayed shipment. After the buyer requests an investigation, the agent reviews the supplier’s confirmation and prepares a delivery date change. A planner then checks production requirements and approves an exception. Finally, the agent executes the approved update.

This approach distinguishes the requester, approver, and executor. Additionally, the agent preparing the exception should not be able to approve its own proposal. However, giving these responsibilities to two different agents does not necessarily solve the problem. If both use the same broadly authorized account, or either can bypass approval, the separation offers little protection. Your application and ERP controls should prevent the agent from approving its own proposal or executing a change without the required approval.

Finally, human responsibility extends beyond access. A 2026 Aalborg University master’s thesis, examining recruitment screening and ERP integration, recommends an advisory approach with recruiters involved in the workflow. Although it addresses a different business process, it illustrates why technical integration and human review need to be considered together.

As discussed in our previous article, an agent’s identity and the authority it uses are separate considerations. Your organization now needs to verify how those distinctions carry through to its ERP permissions and change records.

follow change erpFollow the Change Into Your ERP

Unfortunately, establishing an identity in a cloud platform does not automatically establish ERP permissions or guarantee complete change records. To verify that permissions and activity remain traceable, your technical team needs to test the full connection.

When the agent performs an update, does the ERP identify it? Or does the record show only an employee or technical account?

If information is missing, we recommend maintaining a linked audit record that preserves the following:

  • Who requested and approved the action
  • Which agent performed it
  • Original and revised values
  • Business justification and authorization
  • Timestamp and execution result

A common request identifier can help connect these records for later review. Before expanding the pilot, ask your team to demonstrate an authorized update, a blocked unauthorized change, and an attempted approval bypass.

Continue Managing the Agent After Launch

Once an agent is working, its identity still needs ongoing attention, particularly for changing permissions, responsibilities, and owners.

To help address this issue, Microsoft Entra includes a sponsor field that records an accountable person or group. Likewise, the OpenID Foundation’s white paper emphasizes bringing agents into enterprise identity management, with formal processes for creating their identities, assigning permissions, and eventually retiring them (pp. 12-13). Much like an employee changing roles, an agent taking on new responsibilities needs its access reviewed and updated accordingly. Additionally, when an agent is retired or suspected of being compromised, your team needs a reliable way to remove its access across connected systems, rather than simply disabling one credential and assuming the work is done.

What Challenges Remain?

Unfortunately, managing agent identity becomes more complicated as agents pass tasks to other agents or work across organizational systems. The OpenID Foundation’s white paper explains that organizations need to trace this chain back to the original requester, while ensuring permissions remain limited at each step (p. 18). For instance, a purchasing agent asking another agent to retrieve a supplier confirmation should grant only the access needed for that task.

Additionally, withdrawing access may not immediately stop every delegated activity, particularly when other agents hold credentials that can be used without checking back with a central authorization service (p. 19). With that said, your team should test how access restrictions travel across connected systems and consider safeguards such as limiting the number of operations an agent can perform. 

artificial intelligence erp business transformationHow Should Your Organization Begin?

With these considerations, you may understandably wonder where to start. Fortunately, your organization can begin with one narrowly defined workflow and expand as its value and controls are demonstrated.

Ask your business, IT, and security teams to walk through a complete transaction, from the employee’s request through approval, execution, and review. Include the operational owner who understands the consequences of an incorrect change. From there, evaluate whether the agent reduces manual work while preserving the information your team needs to explain what happened.

Whenever an ERP record changes, your organization should be able to answer the following:

Who requested this, who authorized it, what performed it, and why was it permitted?

Well, that is all! We hope that this information helped you in your AI exploration journey, and thank you for following us through this series. If you haven’t had the opportunity to review the rest of our work on AI and ERP, feel free to take a look at the following articles:

AI in the Real World – Enterprise Resource Planning

Following a Customer Request through CRM, AI, and ERP 

How Can AI Improve Your Purchasing Process? 

If you would like to review articles on other enterprise AI topics, feel free to check out some of ours below:

Operating the AI Architecture in Controlled Layers 

How to Address Employee Concerns About AI Adoption

Think, Assist, Verify – And How It Can Be Your New AI Framework 

Related Posts: