Academy

ERP Guardrails

ERP workflows touch customers, orders, pricing, inventory, shipments, purchasing, documents, accounting context, and customer commitments. An agent working near that data needs clear boundaries.

ERP workflows touch customers, orders, pricing, inventory, shipments, purchasing, documents, accounting context, and customer commitments. An agent working near that data needs clear boundaries before it becomes useful in daily operations.

Guardrails are not decoration around the workflow. They define which user authorized access, which tools the client can call, which records can be touched, which actions remain blocked, how much can run at once, and what the admin can review afterward.

Business Problem

The risk is not only that an agent might make a mistake. The larger operational risk is unclear authority. If a model can create records, attach files, invoke actions, update CRM data, or draft communications, the team needs to know who approved the path and where the system will say no.

Acumatica MCP Tools is designed for controlled workflow access. The agent can assist with approved Acumatica work, but the workflow should still show a useful allowed path, a human approval point, and a denied path that proves the boundary is active.

Control Stack

Acumatica OAuth connects the workflow to the current user’s Acumatica authorization. The agent does not receive raw Acumatica credentials.

Acumatica permissions remain the final authorization layer. If the user cannot do something in Acumatica, MCP tool exposure should not be treated as permission to bypass that.

MCP scopes decide which tool categories a client token can call. Server-side allowlists decide which write entities, delete entities, attachment entities, actions, Entity OData v4 entities, and Generic Inquiry OData inquiries are available.

Metadata validation and server-side path building keep tool calls away from arbitrary Acumatica URLs. Rate limits and concurrency limits reduce the blast radius of action-enabled workflows. Audit logs record allowed and denied operation context without storing secrets, tokens, authorization headers, cookies, or raw request payload values.

Demo Pattern

Start with a helpful read workflow, such as checking blocked shipments, answering an executive question, reviewing a customer PO, or comparing a document packet. Show that the agent can inspect approved Acumatica context through controlled tools.

Then ask for a risky or unrelated operation. Good denied examples include deleting a customer, changing prices across an item class, invoking an unapproved shipment action, importing every enrichment result, or sending a bulk email sequence automatically.

The denial is not a failure. It shows the workflow is bounded.

Approval Points

The admin approves scopes, allowlists, limits, and audit posture before sensitive tools are exposed. The workflow owner approves the business process and decides which user role should run it. The end user approves the prepared business action before the agent creates, updates, attaches, invokes, sends, or escalates work.

For the first setup, keep the approval point close to the user. Let the agent prepare work and explain it. Only run the state-changing step after the user reviews the details.

What to Review in Audit Logs

Audit review should confirm the operation type, sanitized path, status, duration, user, entity, operation kind, and failure status where available. It should also confirm that sensitive values are not being written into logs.

For OData workflows, query strings can include sensitive business data. Use the redaction settings described in the Configuration Reference when the workflow needs query audit paths without exposing raw filter values.

Guided Deployment

Bring the workflow your team wants to test and the operations you want blocked. We will map the safe path, denied paths, approval point, allowlists, limits, and audit review.

Request Free Guided Deployment