BLOG
AI Agent Governance: Why Agentic Orchestration Needs a Controlled Integration Layer
October 21 | Lukas Peter
AI agent governance defines which enterprise systems an AI agent may access, which data it may send, and which actions require approval by a person. In enterprise integration, these rules are easiest to enforce in a central integration layer: the agent plans and proposes actions, while the integration layer validates, executes and logs every step through defined interfaces.
TL;DR
An AI agent should propose, and an integration layer should decide what actually runs. In one SAP S/4HANA migration, 180 interfaces ran through a single integration layer: one place to enforce validation, permissions, and logging instead of 180.
Until recently, AI in most companies meant a chat window. Someone asked, the model answered, and a person decided what to do with the answer. That is changing. Agents are starting to create orders, prepare filings, and update records on their own, and each of those actions lands in a system other processes depend on. The question is no longer what an agent knows. It is what an agent is allowed to do, and who checks.
What is AI agent governance in enterprise integration?
Governance for AI agents is mostly an integration question, not a model question. It sets which business systems an agent may reach, which data it may send, and which steps need a person’s sign-off. Those rules belong in the integration layer, not in the agent’s prompt. A prompt can be ignored. A validation rule cannot.
An agent built on a large language model reads a request, plans, and produces a proposal: an order change, a filing to an authority, a mapping between two data formats. The integration layer talks to the ERP platform, the production control system, or the government interface over REST, SOAP, OData, RFC, IDoc, or file transfer, and carries out the actual exchange.
The agent may propose anything. The integration layer executes only what passes.
Why shouldn’t AI agents connect directly to enterprise systems?
AI agents should not write to enterprise systems directly because a language model can return output that looks right and is still wrong: a missing mandatory field, a unit code that does not exist, an attribute the model made up. Connected directly, the target system receives that output unchecked.
Strict interfaces make the problem visible quickly. A SOAP endpoint with a fixed XML schema rejects the request, and that is the good case. The bad case is an interface that accepts the wrong value and processes it.
A case from our own work shows the pattern without any language model involved. For one customer, we built the ABBYY FineReader Engine into a Scheer PAS service to read scanned change logs. Most pages came through fine. Punched pages did not: the OCR engine read some punch holes as minus signs, and a positive value turned negative. Formally, the result was a valid number. In the content, it was wrong. A regular-expression check in the service flagged values that did not match the expected pattern, and a manual validation step followed before anything reached the target system.
An AI agent fails the same way, only less predictably. Its output looks valid and can still be wrong, so it needs the same two layers: an automatic check first, and a person for the cases the check cannot settle.
Two other problems are harder to spot. An agent sees one request, not the consumers that depend on the same data structure, so a change that looks local can break several systems at once. And a model treats a test call, and a production write the same way unless something around it enforces the difference.
The agent plans. The integration layer executes.
How does a governed agent request flow?
The agent never writes to a target system itself. The integration layer validates each proposal, returns rejected or flagged requests to the agent, asks a person for approval where required, and logs every step. In Scheer PAS, this control comes from where the agent lives. Agents are built with PAS Code, the platform’s development environment, and every agent is a feature of a service. It has no endpoint of its own and can only act through the operations that its service provides. Which operations those are, how their input is validated, and which of them need a person’s approval is defined in the service code, not in the agent’s prompt. That code is written against an approved specification and reviewed before it is merged, so what an agent may execute is decided by the team, in advance, and in one place.
Which guardrails does an agentic integration layer need?
An integration layer that executes actions for AI agents needs six checks: input validation, schema enforcement, permission boundaries, parameter limits, human approval and audit logging. They do not carry equal weight. Schema checks and permissions catch most errors early and cost almost nothing at runtime. Approval steps are expensive and belong only to the few actions where a mistake is expensive too.
Guardrail | What is checked | Example |
|---|---|---|
Input validation | Required fields, data types, value formats | An order without a plant ID is rejected before it reaches the ERP system |
Schema validation | The payload exactly matches the target interface | A submission to a government agency’s SOAP endpoint is validated against its XML schema |
Permission boundaries | The agent may only call approved systems and operations | A support agent can read order status but cannot change prices |
Parameter limits | Values stay within defined ranges and code lists | A lot size above the approved maximum is blocked |
Human approval | A human approves an irreversible step | A production change waits for operator approval |
Audit logging | Every request, decision, and system response is recorded | A log entry shows input source, timestamp, agent, and result |
Nothing in this table is new. Integration teams have used validation, mappings, permissions, and central logging for system-to-system interfaces for years. What changes is the caller.
When does an agent’s action need human approval?
Human approval belongs on agent actions that cannot be undone, that reach customers or authorities directly, or where the agent’s result is uncertain. Everything else can run on its own.
Reading data, querying a status, writing a value that passes validation and stays within its limits is automated. An unmatched value in a mapping table is a different case. The step stops, collects its context and hands it to a person, who can then decide in a minute instead of starting an investigation from scratch.
Approval in the strict sense is for a short list of operations, such as a submission to an authority, a change to a production system, or closing a sensitive customer case. This is what human-in-the-loop (HITL) should mean in practice: people check the few steps where a wrong action is costly, not every step the agent takes.
The rule for each operation sits in the integration layer. Not in the agent.
How do audit logs make agent actions traceable?
An audit log for agent actions records, per request and with a timestamp, who started it, what went in, which rule fired, who approved it and what the target system answered. When all of that sits in one integration layer, a team follows one process across five systems instead of comparing five separate backend logs.
The same data feeds the monitoring: failed steps, unusual patterns, approvals still waiting.
For regulated processes, the log is also the evidence that an automated action followed the defined rules. Without it, “the agent did it” is not an answer anyone can check.
What do real integration projects show about agent governance?
Four Scheer PAS integration projects show the same guardrails at work, each for a different reason. None of these projects used AI agents. What they show is which part of an existing integration layer an agent would depend on, and what breaks without it.
Government interfaces: filings that cannot simply be withdrawn.
An automotive manufacturer exchanges vehicle data with the German Federal Motor Transport Authority (Kraftfahrt-Bundesamt, KBA) through a SOAP interface. On paper that sounds routine. In practice the official specification was incomplete, so the integration had to be tested iteratively against an endpoint whose behaviour was partly undocumented. Credentials expire on a fixed cycle, and a missed rotation locks the account and stops registrations. Then the authority changed the interface with a short delivery window. Every submission is recorded on the authority’s side, and correcting a wrong one is an administrative process. An agent preparing filings here would need schema enforcement and credential handling it cannot touch.
SAP migration: interface contracts across many consumers.
When SAP ECC was replaced by SAP S/4HANA, 30 interfaces had already been built in Scheer PAS, and the systems behind them expected their data structures to stay as they were. For around 80% of them, mappings and additional system connections in the integration layer absorbed the change. An agent working across these systems would face the same constraint without seeing it.
ERP and shop floor: parameters with physical consequences.
Orders arrive as IDocs or as CSV files via SFTP, are validated and enriched, and pass through a sequencing library before they reach a production control system (PCS). During a PCS replacement, the old and new systems ran in parallel so the plant did not have to stop. A wrong parameter or an out-of-order instruction can stop a line.
Retail operations: changes customers see immediately.
Here the risk is a production change or a closed customer case that should not have happened, so an agent needs approval rules before either.
Put side by side, the four projects share one thing. None of them runs an AI agent, and each of them already has the layer an agent would need: defined interfaces, mappings, validation, and logging. What differs is the reason those checks matter. A filing on public record, an interface contract, a production line, and a customer-facing change each fail in their own way, so agent governance cannot be bought as a generic policy. It must fit the process it protects.
For companies that already run such a layer, agentic orchestration is closer than it looks. For those that don’t, that layer is the place to start, not the agent. An agent added later changes who sends the requests. It does not change what must be checked before a request reaches a system.
Where to start
Keep the first step small. List the operations an agent should perform, give it read-only access plus a handful of approved write operations, and define validation, limits and logging for each of them in the integration layer. Most companies already run the interfaces an agent would need. The work is in deciding what the agent may do with them, and writing that down as rules the system enforces.
Why I would not let an agent write unchecked
When we built the FineReader integration, checking the OCR output was never up for debate. Everyone knew a scanner could misread a page, so every value went through a pattern check and the rest went to a person. With language models, that instinct seems to go missing. The output reads well, so it feels correct.
I don’t think agents will fail because the models are bad. They will fail where companies connect them to business systems the way they would never connect a new scanner: directly, with nothing in between. The integration work many of us have been doing for years is exactly what prevents that. It just has a new caller now.
Frequently asked questions
What is agentic orchestration?
Coordinating work across several business systems, with AI agents planning the steps and an orchestration layer carrying them out. The agent interprets the request, for example classifying an incident or preparing a filing. The orchestration and integration layer communicates with the target systems, applies validation and permissions, and records each step.
Do AI agents need a separate integration platform?
Usually not. An existing integration platform already provides interfaces, mappings, permissions, logging and monitoring. Reusable components let each agent call a tested building block instead of building its own backend connection. What has to be added are approval rules and parameter limits per operation, because the caller is now an agent.
Who is accountable when an AI agent makes a wrong change?
The organisation that operates the agent and defines its permissions. The audit log shows which agent made the request, which rules applied and who approved it, so the team can find the rule that let the change through and fix it.
About the author
Lukas Peter
is a developer and technical consultant at Scheer PAS. He builds integration services in Scheer PAS Designer and PAS Code, including xUML and BPMN service models, REST and file-based adapters, and connections to SAP data sources.
