The ERP is the last place you want an agent going rogue. Reading from it is one thing; letting software act on the system that runs your business is another. Here is how to do it so an agent is an asset, not an incident waiting to happen.

We have covered the open protocols that connect agents to your systems, and SAP’s own agent platform. Both land on the same question - the one your IT director keeps asking: it looks fine in a demo, but how do we let this anywhere near the ERP?

It is the right instinct. The ERP is your system of record - the money, the master data, the open orders. An agent that can read it carries a manageable risk. An agent that can act on it should be treated with at least the seriousness you would give a new employee with production access. Arguably more, because it acts faster than anyone can watch.

The reassuring part is that safe interfacing is not one clever control. It is a small, well-understood stack, and none of it is exotic.

Two very different risk profiles

Start by separating two things that often get lumped together. Read access is an information risk: the danger is oversharing or leakage - an agent surfacing data to someone who should not see it.

Act access - writing back, posting, releasing, paying - is a transaction risk: a wrong payment, a corrupted master-data record, an order released in error. Most of the value lives in act access, but you earn it in stages rather than granting it on day one.

Give every agent an identity of its own

The most common mistake is the first one teams make: handing an agent a human’s login, or a shared, generic service account, because it is the quickest way to get it working.

It is also the thing that makes everything afterwards impossible. If several agents act behind one shared account, you cannot say which did what, or on whose authority. Traceability and accountability are gone before you start.

Every agent needs its own verifiable identity, tied to a named human owner, so every action it takes is attributable. This is where regulators and standards bodies are converging fastest - Singapore’s agentic-AI framework, for instance, requires each agent to carry a verifiable identity and an audit trail of which agent acted under whose authorisation, and similar identity-standards work is underway elsewhere. Yet surveys through 2026 suggest only around a quarter of organisations have any enterprise-wide strategy for agent identity. That gap is the first thing to close.

Least privilege, scoped to the job

With identity in place, access follows the same rule you already apply to people: least privilege. An agent gets permission to reach exactly the data and actions its task requires, and nothing more - read-only by default, with write access narrow, explicit and justified.

In SAP terms this is not a new model. A well-built agent runs inside the requesting user’s security context and is subject to the same authorisation checks as any other access, rather than operating as an all-powerful service account. The agent inherits the guardrails your permissions model already encodes.

Put a gateway on the ERP boundary

Identity and permissions need a place to be enforced. That place is a policy layer - a gateway, or control plane - that sits between your agents and the system of record. It authenticates each agent, checks every request against policy, blocks what falls outside it, and logs everything that passes.

This is the same control plane we described for the wider agent workforce, focused on the one boundary that matters most. It gives you a single point to set the rules, and a single place to see them being followed.

An agent that can read your ERP is a manageable risk. An agent that can act on it is a new hire with production access - and it moves faster than you can watch.

The new risk: the agent can be talked into it

Here is the part that is new, and worth your security team’s attention. Traditional security assumes an attacker is trying to break in. With agents, an attacker can instead try to get the agent to act for them - by hiding instructions in data the agent reads (an invoice, an email, a document) or in the description of a tool it trusts. The agent, doing as it is told, becomes the route in.

You cannot eliminate this, but you can cap its blast radius. Treat everything an agent ingests as untrusted. Constrain what the agent is able to do at all, regardless of what it is told. Validate actions before they execute. And keep write scopes tight. This is exactly why “read-only by default” and “narrow write access” are not bureaucracy - they are what limits the damage when, not if, an agent is fed something malicious.

Audit everything, and make it explainable

Every action an agent takes on the ERP should be logged, attributable to a specific agent and its owner, and explainable after the fact: what it did, why, on whose authority, and against which data. This is good operational hygiene, it is increasingly a regulatory expectation, and it is the practical thing that lets you extend act access with confidence - because you can always reconstruct what happened and, where possible, reverse it.

Humans at the thresholds - and accountable throughout

For high-impact actions - moving money, changing master data, releasing an order - a human sign-off sits at the threshold. The ERP boundary is precisely where those checkpoints belong.

And be clear about where accountability rests. Under the EU AI Act, the duty of human oversight for high-risk uses falls on the organisation deploying the agent, not the vendor that supplied it. The software does not carry the responsibility. Someone in your organisation always does - which is the whole reason identity and named ownership come first.

Earn autonomy in stages

Put together, the safe path onto the ERP is a progression, not a leap:

• Read-only insight - the agent informs, a person acts.

• Recommend and approve - the agent proposes an action; a person signs it off.

• Act within bounds - the agent executes low-risk, reversible actions inside tight, logged limits.

• Widen carefully - scope grows as the evidence and the trust accrue.

No one should start an ERP-connected agent with broad write access. You build up to it.

The bottom line

Interfacing AI with your ERP safely is not a single gate you either pass or fail. It is a small stack - an identity of its own, least privilege, a gateway, full audit, human thresholds - that together let agents act on your most important system without turning it into a liability. Get that stack right and “agent-ready” stops being a risk conversation and becomes a capability. Designing that stack for your landscape is where we would start. Get in touch with us.