How AI agents write to SAP safely

Many AI projects around SAP start with read access. An agent looks up order status, open items or delivery dates and summarizes them. If something goes wrong, the answer is wrong, but nothing in the system has changed.

Writing is a different matter. A new sales order triggers follow-on processes, from material planning through delivery to billing. A wrong price ends up on the invoice, a duplicate order in the warehouse. Handing a language model an API and hoping for the best won’t do.

Technically, an AI agent calls a tool: a function with parameters. The model decides which function to call and with which values. That’s fine for a web search.

For a posting in SAP, almost everything that makes up an enterprise transaction is missing. Who is acting, and with what permissions? Who checked whether the action is allowed? What happens if the same call arrives twice? How will anyone reconstruct, a year from now, why the order was created exactly this way?

No language model should have to answer these questions. They belong in a layer between the agent and SAP that works by fixed rules. In voluro Nexus, that’s the execution layer: governance is decided by Nexus, not by the language model. The building blocks below show what that layer consists of.

An agent never works in SAP through a shared or admin account. It gets its own technical identity with roles that match its job. An order agent might be allowed to create sales orders and read customer master data, but not to maintain pricing conditions. SAP’s authorization concept stays in force.

Before every action, Nexus also checks whether the agent may use this tool, in this system, for this transaction. That policy check runs outside the language model, so even a cleverly worded prompt won’t change its outcome.

Connections drop, timeouts trigger retries, an agent starts over after an error. Without protection, a second order for the same transaction appears quickly.

That’s why write actions in Nexus carry a unique transaction key. If the same call comes in again, Nexus recognizes it and doesn’t execute it a second time. To the agent it looks like a successful call, and SAP still holds only one document.

An agent tool like erp.salesOrder.create is software and gets treated as software. Tools, policies and agent deployments are versioned in Nexus, and a production deployment can’t be altered after the fact. Changes move through DEV, TEST and PROD, much like SAP teams know from their transports.

This pays off in practice: if a transaction raises questions later, the run can be reproduced with exactly the agent, tool and policy versions that were active at the time.

Every step is logged: which agent in which version, with which inputs, which policy decision, who approved, and what SAP returned. Sensitive content can be redacted in outputs and logs. For auditors and internal controls, a posting made by an agent is as traceable as one made by an employee.

SAP systems are usually not reachable from the internet, and for good reason. So that an agent can still work with them, a small relay service runs inside your network. It only opens outbound connections and needs no inbound port. It forwards calls only to target systems on its local allowlist.

SAP S/4HANA follows the clean core principle: extensions shouldn’t change the standard. Agents fit that well as long as they work through released interfaces.

Nexus reads the metadata of existing OData services (entity sets, actions and function imports) as well as your custom APIs, and turns them into controlled agent tools. Existing customizing and your own services keep working, and nothing in the SAP core needs to be modified.

Before an agent writes to SAP in production, these points should be settled:

• Agent identity: a dedicated technical user per agent, least-privilege roles, no shared account.
• Policy check: permissions and rules are checked outside the language model before every action.
• Autonomy rules: for each write action, it’s defined when it runs automatically, needs approval or is blocked.
• Idempotency: repeated calls don’t create duplicate documents.
• Versioning: tools, policies and deployments are versioned and move through DEV, TEST and PROD.
• Audit trail: agent, version, inputs, decision, approval and system response are logged.
• Network: access via outbound connections and an allowlist of target systems, no open port.
• Clean core: access through OData services and released APIs, no modifications.