An AI agent that can work in SAP may look like a productivity opportunity: it reads an invoice, checks a purchase order, resolves an exception and prepares the next action. In finance, procurement and ERP operations, that is also exactly where an apparently useful automation can become an internal-control problem.
Many organisations approach agent access as an identity-and-permissions exercise. They ask whether the agent should have read access, whether it should use a technical user, and whether a manager must approve its deployment. Those questions matter, but they do not answer the most important production question: which incompatible business actions could this agent combine over the course of one workflow?
An agent does not need unrestricted administrator access to create a serious control failure. It may operate through several bounded tools, call approved interfaces and still assemble a risky chain: creating or modifying supplier information, changing payment details, clearing an invoice exception and submitting a payment request. If one automated system can move uninterrupted across those steps, it has effectively collapsed duties that the organisation deliberately separated between people.
That is why an AI agent needs a segregation-of-duties matrix before it touches SAP. The matrix is not documentation produced after deployment. It is the design constraint that determines what the agent is allowed to do, what it may recommend, where a human decision is mandatory and what evidence must survive every exception.
Why conventional access control is not enough
Traditional SAP authorisation design is generally concerned with whether a user can perform a transaction, change a record or access a data object. Segregation of duties asks a different question: what becomes possible when those permissions are combined?
This distinction becomes sharper with agentic AI. A human user usually follows a defined role, works within an expected business context and makes a limited number of decisions during a working day. An agent can move across systems, interpret unstructured documents, retrieve context from a knowledge base and invoke tools in sequence. Its effective capability is therefore not just the list of permissions attached to its identity. It is the combined effect of its tools, instructions, data access, escalation rules and ability to initiate the next step.
Consider a procurement agent that identifies a missing supplier record while processing an invoice. Giving it the ability to create a supplier may appear sensible. Allowing it to extract bank details from an invoice and write them to master data may seem like the natural next step. Letting it match the invoice to a purchase order and route it for payment might then look efficient. Yet the full chain creates a route through supplier creation, bank-data amendment and payment processing that a well-designed finance function would not assign to one person.
The problem is not that the agent is malicious. The problem is that the operating model has removed the independent point of challenge. A poor instruction, a manipulated document, an inaccurate extraction or an incorrectly retrieved record can travel much further when the same system can both create the condition and act on it.
Treat the agent as a role with a workflow, not as a clever interface
The practical starting point is to map each proposed agent to the same control logic used for a business role. Do not begin with a generic question such as, “What SAP access does the agent need?” Begin with the business outcomes it may influence.
Separate observation from action. An agent may be permitted to read a supplier record, identify that a bank account differs from the latest invoice and prepare a proposed change. That does not mean it should be able to commit the change. Read, analyse and recommend are materially different permissions from create, amend, approve and execute. They should be designed and governed accordingly.
This distinction is especially important because natural-language interfaces can obscure the true action being taken. A colleague may ask an agent to “clean up this supplier issue”. Behind that request sit several possible system changes. The agent should not infer that a broad business instruction grants it authority to perform every downstream action required to resolve the case. Its tool layer must enforce the boundary even when the conversational instruction is vague.
Define prohibited combinations, not only allowed actions. A useful agent-specific matrix identifies the combinations that must never be available in a single automated chain. In a finance context, this often includes combinations across master-data maintenance, invoice handling, approval, payment release and reconciliation. In procurement, it can include supplier onboarding, purchase-order changes, goods-receipt confirmation and invoice approval.
The relevant unit of analysis is the workflow path. An agent that has separate tools for each step can still create a conflict if its orchestration layer can call them one after another without independent authorisation. Technical modularity is not segregation of duties.
Assign a human role to the decision, not merely to the button click. A weak design asks a manager to approve an action after the agent has already made all substantive decisions. A stronger design identifies the point at which business judgement is required and ensures that the responsible person receives sufficient context to exercise it.
For example, an agent can compile the documents, identify mismatched fields, classify the exception and draft a recommended route. The approver should see the relevant evidence, the proposed system changes, the reason for the recommendation and any policy conditions that were not met. An approval screen that simply says “AI recommends approval” does not restore control. It merely turns a human into a rubber stamp.
Translate the existing matrix into agent action boundaries
Most established organisations already have some form of segregation-of-duties framework, whether embedded in SAP roles, internal-control documentation, audit workpapers or finance policies. The task is not to replace that work with an AI governance deck. It is to translate it into machine-enforceable behaviour.
Start by identifying the agent’s intended business domain. A narrow accounts-payable agent, a supplier-onboarding agent and a cash-management agent should not be designed as one broad “finance assistant”. Each has different sensitive actions, data dependencies and escalation needs. Combining them under one agent identity may be convenient for a platform team, but it makes a clean control model much harder to maintain.
Next, connect every tool the agent can invoke to a business action category. A tool that updates supplier master data is not just an API call; it is a master-data change capability. A tool that submits a payment batch is not merely a workflow integration; it is a payment initiation capability. This translation prevents engineering language from hiding a material control decision.
Then define three outcomes for each action. The agent may perform the action autonomously when it is low-risk and policy-compliant. It may prepare the action but require approval before it is committed. Or it may be prohibited from performing the action entirely, even if it can identify the issue. The third category is essential. Without it, teams tend to treat escalation as a temporary inconvenience rather than a permanent control boundary.
A supplier bank-detail amendment is a useful example. The agent may detect a request, extract relevant information and check whether required supporting evidence exists. It may not decide that the evidence is sufficient, amend the bank details and then advance a payment workflow. If it is allowed to prepare the record, the proposed change should remain separate from the approved master record until an appropriately independent role authorises it.
Build approvals into the workflow architecture
Approval cannot be a generic catch-all placed at the final stage of an agent workflow. It needs to be triggered by the type of action, the combination of actions attempted and the confidence or completeness of the evidence available.
An agent should encounter a hard boundary when it reaches a prohibited combination. It should not be able to work around that boundary by rephrasing a tool request, calling a neighbouring system or handing work to another agent with the same effective permissions. This is where architecture matters. Distinct service identities, scoped tool permissions, explicit state transitions and centrally enforced policies are more reliable than instructions embedded only in a prompt.
Use policy decisions outside the model. The language model can interpret documents, classify a request and propose a next step. It should not be the final authority on whether a sensitive action is permissible. That decision belongs in deterministic policy logic tied to the organisation’s control model.
For instance, a policy layer can determine that a particular combination of supplier-data change and payment-related action requires a separate human approver. The model may explain why the case has been escalated, but it cannot override the rule because it believes the request is urgent or well supported. This separation protects against model error, prompt injection and inconsistent reasoning.
Preserve the evidence trail. When an agent takes or recommends an action, the organisation needs to reconstruct what happened. The record should show the initiating request, information used by the agent, documents or system records considered, tools called, proposed changes, policy checks performed, approvals obtained and final outcome.
This does not require storing every internal model thought process. It does require an operational record that lets finance, internal audit and IT understand the decision path. If an agent retrieved a supplier policy, compared invoice fields and triggered an exception route, those events should be visible in an evidence trail that is linked to the business transaction.
Exceptions are where the control model is tested
Straight-through processing is usually the easy part. The difficult cases are incomplete documents, conflicting supplier data, urgent payment requests, missing purchase orders and instructions that arrive through email or chat with unclear authority.
An agent should not resolve ambiguity by expanding its own authority. Its exception design should state what information is missing, which control condition failed, who owns the decision and what actions remain unavailable until the case is resolved. This is particularly important in a Mittelstand environment, where experienced finance staff often hold important process knowledge that has never been fully formalised.
The temptation is to give the agent broader rights because exceptional cases create manual work. That saves effort in the short term while making the operating model less defensible. A better approach is to use early deployments to reveal where policies are unclear, where approval ownership is absent and where process exceptions recur. Those findings improve both the workflow and the underlying business process.
Production readiness means proving the boundaries
Before connecting an agent to productive SAP processes, test its ability to refuse. Teams often test whether an agent can complete the happy path. They should also test whether it stops when asked to combine conflicting actions, when a user requests an override, when input evidence is incomplete or when another tool presents an indirect route around a restriction.
The standard should be clear: an agent is production-ready not when it can automate the most steps, but when its action boundaries remain reliable under messy, realistic operating conditions.
For DACH organisations, the value of this discipline is not limited to avoiding a control incident. It creates a credible path from isolated AI experiments to business-critical use cases. Finance leaders can support automation when they can see who retains accountability. IT can operate the system when permissions and policy enforcement are explicit. Internal-control owners can assess it when evidence is available by design rather than assembled after the fact.
An AI agent should accelerate a controlled process, not quietly redesign it.
A Diagnostic maps your proposed AI agent workflows against existing ERP controls, identifies incompatible action chains and defines the approval and evidence model required before production access creates avoidable risk.
Context note: This article is based on practical internal-control and AI system design principles; no external sources were cited.